Re: [TLS] Selfie attack

[Mohit Sethi M <[e-mail]>]

Hi John,

On 10/8/19 1:14 PM, John Mattsson wrote:
Hi Mohit, that are good points.

> The reality however is that in most group PSK scenarios, the nodes don't have any strong identities that can be verified.
I assume blocking all identities that are not the nodes own identity would mitigate the attacks, but lead to availability problems as two nodes with the same chosen identity cannot talk to each other.
Well this is getting off-topic, but if identities are generated randomly and are long enough, collisions shouldn't be a problem. Some MAC address randomization implementations simply generate a new address if they detect a collision. But we will soon start discussing the problem of address squatting and want Cryptographically Generated Address (CGAs). So perhaps we can leave the identity collision and squatting problem to the actual deployment.

>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.

I think checking ClientHello.random is enough. Below is what we wrote in

On this, Drucker and Gueron's paper mentions that a possible solution is: "Every party (client or server) caches all the nonces that it generated, and rejects a connection from other parties if they use a cached nonce." and that it "involves the overhead of maintaining a cache and the overhead of sharing the cache between several processes on the same node.". The paper also describes a group scenario where nodes can inadvertently leak cache and memory information if something like this is implemented. So I think that ensuring non-equal client and server identities is easier and safer since this check can be performed before the TLS handshake begins (i.e. when the external PSK is transformed to ipskx).

--Mohit
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14

  “If two nodes unintentionally initiate two simultaneous EDHOC message
   exchanges with each other even if they only want to complete a single
   EDHOC message exchange, they MAY terminate the exchange with the
   lexicographically smallest G_X.  If the two G_X values are equal, the
   received message_1 MUST be discarded to mitigate reflection attacks.
   Note that in the case of two simultaneous EDHOC exchanges where the
   nodes only complete one and where the nodes have different preferred
   cipher suites, an attacker can affect which of the two nodes'
   preferred cipher suites will be used by blocking the other exchange.”

John

From: TLS <[e-mail]><mailto:[e-mail]> on behalf of Mohit Sethi M <mohit.m.sethi=[e-mail]><mailto:mohit.m.sethi=[e-mail]>
Date: Tuesday, 8 October 2019 at 11:57
To: Christopher Wood <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: Re: [TLS] Selfie attack


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. 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]><mailto:[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]><mailto:[e-mail]> on behalf of "Hao, Feng"

<[e-mail]><mailto:[e-mail]>

    Date: Tuesday, 24 September 2019 at 16:09

    To: Mohit Sethi M <mohit.m.sethi=[e-mail]><mailto:mohit.m.sethi=[e-mail]>,

"Owen Friel (ofriel)" <[e-mail]><mailto:[e-mail]>, Jonathan Hoyland

<[e-mail]><mailto:[e-mail]>

    Cc: "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[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 <mailto:[e-mail]=[e-mail]>

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]<mailto:[e-mail]>

        https://www.ietf.org/mailman/listinfo/tls









_______________________________________________

TLS mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/tls