Re: [TLS] Selfie attack

["Christopher Wood" <[e-mail]>]

On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>  
> Hi Chris,
> 
> For the benefit of the list, let me summarize that the selfie attack is 
> only relevant where multiple parties share the same PSK and use the 
> same PSK for outgoing and incoming connections. These situations are 
> rather rare, but I accept that TLS is widely used (and sometimes 
> misused) in many places.
> 
> The Selfie attack only happens when an entity with the PSK acts 
> maliciously. So I think the fact that you write in the draft: "each 
> node must be trusted not to impersonate another node's role" does not 
> take into account that there must be a malicious node for the selfie 
> attack to happen in the first place. 
> 
> Drucker and Gueron's paper recommends that "every participating party 
> gets (during the setup of the network) a unique identity" and "the 
> client and the server must verify the validity of the claimed 
> identities.". The reality however is that in most group PSK scenarios, 
> the nodes don't have any strong identities that can be verified. 
> 
> What you should instead (or additionally) say in the text is that a 
> node should check that the client_mac and server_mac (or any other 
> identities used) *are never the same*. 

This seems implicit in the text as written. Could I ask you to submit a PR against [1] to clarify?

Thanks,
Chris

[1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer

> Without this check, the selfie 
> attack would still be possible. And at least this does not require 
> strong identity verification for preventing selfie attacks. 
> 
> --Mohit
> 
> On 10/5/19 2:41 PM, Christopher Wood wrote:
> > 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" <[e-mail]> 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 <[e-mail]> on behalf of "Hao, Feng" 
> >> <[e-mail]>
>     Date: Tuesday, 24 September 2019 at 16:09
>     To: Mohit Sethi M <mohit.m.sethi=[e-mail]>, 
> "Owen Friel (ofriel)" <[e-mail]>, Jonathan Hoyland 
> >> <[e-mail]>
>     Cc: "[e-mail]" <[e-mail]>
>     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" 
> >> <[e-mail] on behalf of 
> mohit.m.sethi=[e-mail]> 
> <mailto:[e-mail]=[e-mail]> 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
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/tls
>         
>     
>     
> 
> _______________________________________________
> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> 
> > _______________________________________________
> TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls