Hi Feng, For what it's worth, the latest version of the PSK importers draft includes a "context" field into which identity information can be fed:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#appendix-B Best, Chris On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
