Hi John,
Reflection attacks are indeed older, but the selfie attack is a bit different.
It's actually a variant of the unknown key share attack. A typical example of
the UKS attack is the one reported on MQV by Kaliski in 2001 (see "An unknown
key-share attack on the MQV key agreement protocol" in ACM TISSEC 2001). In
that example, the adversary plays message between two users to cause confusion
in the identity, but in Selfie, the adversary plays message with only one user
and uses another instance of the user to cause confusion in the identity. When
we reported this variant of UKS in [3], we were not aware of anything like that
in the literature.
Cheers,
Feng
On 24/09/2019, 16:17, "John Mattsson" <john.matts...@ericsson.com> wrote:
Hi,
I think these reflection attacks are much older than this. I quick search
for reflection attack security protocol gives a lot of old results, The
description of reflection attack in the following lecture material from 2009
looks just like the "selfie attack" on TLS 1.3
http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf
With multiple sections there are other things that change as well. If two
nodes unintentionally initiate simultaneous ClientHello to each other, even if
they only want a single secure connection (I have seen live systems where this
happens in practice), an attacker can select which ClientHello to block (e.g.
the one with the strongest cryptographic parameters). The following security
property would then no longer hold :
"Downgrade protection: The cryptographic parameters should be the
same on both sides and should be the same as if the peers had been
communicating in the absence of an attack"
(I have not looked at what the definitions in [BBFGKZ16] say).
Cheers,
John
-----Original Message-----
From: TLS <tls-boun...@ietf.org> on behalf of "Hao, Feng"
<feng....@warwick.ac.uk>
Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org>, "Owen
Friel (ofriel)" <ofr...@cisco.com>, Jonathan Hoyland
<jonathan.hoyl...@gmail.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Selfie attack was Re: Distinguishing between
external/resumption PSKs
On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"
<tls-boun...@ietf.org on behalf of mohit.m.sethi=40ericsson....@dmarc.ietf.org>
wrote:
Hi all,
On the topic of external PSKs in TLS 1.3, I found a publication on
the
Selfie attack:
https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21b-dc6c6f0a5dd21faf&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347
Perhaps this was already discussed on the list. I thought that
sharing
it again wouldn't hurt while we discuss how servers distinguish
between
external and resumption PSKs.
I just read the paper with interest. It occurs to me that the selfie
attack is consistent with the "impersonation attack" that we reported on SPEKE
in 2014; see Sec 4.1 [1] and the updated version with details on how SPEKE is
revised in ISO/IEC 11770-4 [2]. The same attack can be traced back to 2010 in
[3] where a "worm-hole attack" (Fig. 5, [3]) is reported on the
self-communication mode of HMQV. The essence of these attacks is the same: Bob
tricks Alice into thinking that she is talking to authenticated Bob, but she is
actually talking to herself. In [3], we explained that the attack was missed
from the "security proofs" as the proofs didn't consider multiple sessions.
The countermeasure we proposed in [1-3] was to ensure the user identity
is unique in key exchange processes: in case of multiple sessions that may
cause confusion in the user identity, an extension should be added to the user
identity to distinguish the instances. The underlying intuition is that one
should know "unambiguously" whom they are communicating with, and perform
authentication based on that. The discovery of this type of attacks and the
proposed solution are inspired by the "explicitness principle" (Ross Anderson
and Roger Needham, Crypto'95), which states the importance of being explicit on
user identities and other attributes in a public key protocol; also see [3]. I
hope it might be useful to people who work on TLS PSK.
[1]
https://protect2.fireeye.com/url?k=5a822513-0608efad-5a826588-869a17b5b21b-eb260151f78b0718&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2014%2F585.pdf
[2] https://arxiv.org/abs/1802.04900
[3]
https://protect2.fireeye.com/url?k=d5bf88ff-89354241-d5bfc864-869a17b5b21b-0e9b3bf58e104f32&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F136.pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
