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

Reply via email to