Subject: Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

From: "Christopher Wood" <[email-masked]>
Date: Sat, 05 Oct 2019 04:41:22 -0700

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" <[email-masked]> 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 <[email-masked]> on behalf of "Hao, Feng" 
> <[email-masked]>
>     Date: Tuesday, 24 September 2019 at 16:09
>     To: Mohit Sethi M <mohit.m.sethi=[email-masked]>, 
> "Owen Friel (ofriel)" <[email-masked]>, Jonathan Hoyland 
> <[email-masked]>
>     Cc: "[email-masked]" <[email-masked]>
>     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" 
> <[email-masked] on behalf of 
> mohit.m.sethi=[email-masked]> 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
>         [email-masked]
>         https://www.ietf.org/mailman/listinfo/tls
>         
>     
>     
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 8 Oct 2019 09:55:37 +0000

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,

Best,
Chris

Hi John,

Cheers,
Feng

On 24/09/2019, 16:17, "John Mattsson" <[email-masked]><mailto:[email-masked]> wrote:

    Hi,

    Cheers,
    John

    -----Original Message-----
    From: TLS <[email-masked]><mailto:[email-masked]> on behalf of "Hao, Feng"
<[email-masked]><mailto:[email-masked]>
    Date: Tuesday, 24 September 2019 at 16:09
    To: Mohit Sethi M <mohit.m.sethi=[email-masked]><mailto:mohit.m.sethi=[email-masked]>,
"Owen Friel (ofriel)" <[email-masked]><mailto:[email-masked]>, Jonathan Hoyland
<[email-masked]><mailto:[email-masked]>
    Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
    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"
<[email-masked] on behalf of
mohit.m.sethi=[email-masked]><mailto:[email-masked]=[email-masked]> wrote:

            Hi all,

        [1]

        _______________________________________________
        TLS mailing list
        [email-masked]<mailto:[email-masked]>
        https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: John Mattsson <[email-masked]>
Date: Tue, 8 Oct 2019 10:14:26 +0000

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.

>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
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 <[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]>
Date: Tuesday, 8 October 2019 at 11:57
To: Christopher Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Selfie attack

Hi Chris,

--Mohit

Hi Feng,

Best,

Chris

Hi John,

that in the literature.

Cheers,

Feng

    Hi,

no longer hold :

    Cheers,

    John

    -----Original Message-----

external/resumption PSKs

<[email-masked] on behalf of <mailto:[email-masked]=[email-masked]>

            Hi all,

publication on the

            Selfie attack:

that sharing

distinguish between

        [1]

        [3]

        TLS mailing list

TLS mailing list

TLS mailing list

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 8 Oct 2019 12:09:18 +0000

Hi John,

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

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.

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

John

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

Hi Chris,

--Mohit

Hi Feng,

Best,

Chris

Hi John,

that in the literature.

Cheers,

Feng

    Hi,

no longer hold :

    Cheers,

    John

    -----Original Message-----

external/resumption PSKs

            Hi all,

publication on the

            Selfie attack:

that sharing

distinguish between

        [1]

        [3]

        TLS mailing list

TLS mailing list

TLS mailing list

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 08 Oct 2019 09:46:26 -0700

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
> 
> For what it's worth, the latest version of the PSK importers draft 
> includes a "context" field into which identity information can be fed:
> 
>    
> mohit.m.sethi=[email-masked]> 
> <mailto:[email-masked]=[email-masked]> wrote:
>         
>             Hi all,
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Oct 2019 11:51:00 -0700

>> rather rare, but I accept that TLS is widely used (and sometimes 

I may be getting old but the way Mohit writes it, it seems that the
attack happens when the security of a group relies on a secret shared by
all members of the group, and can then be compromised when one of the
group members misbehaves. How is that a new threat? If groups are
defined by a shared secret, then corruption of a group member reveals
that shared secret to the attacker and open the path for all kinds of
exploitation. In what sense is the "selfie" attack different from that
generic threat?

-- Christian Huitema

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 8 Oct 2019 19:07:55 +0000

Hi Christian,

It was my poor attempt at explaining the attack. The attack can happen as long as a node sends outbound connections (as a TLS client) and accepts inbound connections (as a TLS server) with the same external PSK and identity. This is likely to happen in some form of group communication but not necessarily.

In such a scenario, a malicious node Eve can fool Alice to open a connection to herself (hence the name Selfie).

Admittedly, UKS/misbinding/selfie are somewhat hard to comprehend sometimes (at least for me).

--Mohit

On 10/8/19 9:51 PM, Christian Huitema wrote:

Hi Chris,

I may be getting old but the way Mohit writes it, it seems that the attack happens when the security of a group relies on a secret shared by all members of the group, and can then be compromised when one of the group members misbehaves. How is that a new threat? If groups are defined by a shared secret, then corruption of a group member reveals that shared secret to the attacker and open the path for all kinds of exploitation. In what sense is the "selfie" attack different from that generic threat?

-- Christian Huitema

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 08 Oct 2019 16:48:08 -0700

On Tue, Oct 8, 2019, at 11:51 AM, Christian Huitema wrote:
> attack happens when the security of a group relies on a secret shared 
> by all members of the group, and can then be compromised when one of 
> the group members misbehaves. How is that a new threat? If groups are 

In my opinion, it's not. 

Best,
Chris

---

From: "Hao, Feng" <[email-masked]>
Date: Wed, 9 Oct 2019 08:34:48 +0000

Hi Chris,

Thanks for the link. The use of a ³context² field is reasonable. As long
as the client and server check the two MAC identities and ensure they are
different, this specific selfie attack should be presented. I¹m not sure
how TLS PSK deals with the case of having parallel key exchange sessions
between two nodes. If that¹s allowed, and the same ³context field² is used
in the parallel sessions, there might still be a possible UKS attack.
Either the parallel sessions are disabled, or if they are allowed,
additional context should be added to ensure the identities of the two
nodes remain unique even within parallel sessions.

Cheers,
Feng

On 05/10/2019, 12:41, "TLS on behalf of Christopher Wood"
<[email-masked] on behalf of [email-masked]> wrote:

>>https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21
>>b-dc6c6f0a5dd21faf&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347
>>             
>>https://protect2.fireeye.com/url?k=5a822513-0608efad-5a826588-869a17b5b21
>>b-eb260151f78b0718&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2014%2F585.pdf
>>https://protect2.fireeye.com/url?k=d5bf88ff-89354241-d5bfc864-869a17b5b21
>>b-0e9b3bf58e104f32&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F136.pdf
>>         
>>

---

From: John Mattsson <[email-masked]>
Date: Fri, 11 Oct 2019 07:38:49 +0000

Thanks Mohit,

Re-reading the Selfie paper I see that the authors define Client Alice and Server Alice as different members of the group. That makes things clearer. I think there are three cases:

  1.  Use cases where only Client Alice and Server Bob shares the PSK are not vulnerable to the Selfie attack.

  1.  Cases where Alice, Bob, and Caesar share an external PSK seem like misconfiguration, I assume TLS 1.3 just forgot to explicitly forbid them.

  1.  The interesting use case if where Client Alice, Server Alice, Client Bob, and Server Bob shares a PSK. That is a very valid use case and one that is currently deployed in several systems.

To do as the Selfie authors suggest “A PSK MUST NOT be shared between more than one client and one server” seems way too drastic as is forbids 3 above. For 3 I think the Selfie attack can be very easily mitigated by forcing clients to check incoming ServerHello.random.

I think something like the following updates for RFC 8446 would be enough:

“A PSK MUST NOT be shared between more than two endpoints”

“An endpoint receiving a ClientHello with PSK authentication MUST check that the ClientHello.random is not equal to a ClientHello.random that the endpoint previously sent and has not received a ServerHello.”

Cheers,

John

From: TLS <[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]>
Date: Tuesday, 8 October 2019 at 21:08
To: Christian Huitema <[email-masked]>, Christopher Wood <[email-masked]>, Mohit Sethi M <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Selfie attack

Hi Christian,

--Mohit

Hi Chris,

misused) in many places.

-- Christian Huitema

TLS mailing list

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 11 Oct 2019 12:32:11 +0000

Hi,

I created a pull request for the draft to improve the section on 
addressing selfie attacks. For the benefit of the list, here is the 
proposed text:

> The TLS external PSK authentication makes the implicit assumption that 
> each PSK is known only to one client and one server, which do not 
> switch roles with the same PSK.
>
> If multiple clients or multiple servers share a PSK, TLS only 
> authenticates the entire group. Not only can a compromised group 
> member impersonate another group member, but a malicious non-member 
> can reroute handshakes between honest group members to connect them in 
> unintended ways. This rerouting is a type of identity misbinding 
> attack [Krawczyk][Sethi].
>
> Selfie attack [Selfie] is a special case of the rerouting attack 
> against a group member that can act both as TLS server and client. In 
> the selfie attack, a malicious non-member reroutes a connection from 
> the client to the server on the same endpoint.
>
> Rerouting and selfie attacks can be detected by binding the TLS 
> handshake to globally unique node identifiers using the following 
> context string:
>
> struct {
>        opaque client_id<0..2^16-1>;
>        opaque server_id<0..2^16-1>;
>      } Context;
>
> When the PSK is shared by only two endpoints, it is not necessary to 
> know the identifier(s) of the other endpoint. Instead, it is 
> sufficient to check that the identifier of the other endpoint in 
> context is not equal to any of one’s own identifiers. To simplify 
> implementation of this check, it is RECOMMENDED that each endpoint 
> selects one globally unique identifier and uses it in all PSK 
> handshakes. The unique identifier can, for example, be one of its MAC 
> addresses or a 32-byte random number.
>
> When the PSK is a group key, the comparison with one’s own identifiers 
> will only prevent selfie attacks but not malicious rerouting of the 
> connection to another group member. To prevent malicious rerouting in 
> groups, each endpoint needs to know the identifier of the other 
> endpoint with which they want to connect and compare it with the other 
> endpoint’s identifier in context. Of course, this only prevents 
> attacks by non-members; the endpoints that share the group key can 
> always impersonate each other.

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 11 Oct 2019 12:33:43 +0000

Hi Chris and Christian,

I would disagree. The important thing to note is that the selfie attack 
is not a traditional insider attack where someone with the PSK 
misbehaves. If you look at the paper (https://eprint.iacr.org/2019/347), 
you will notice that Eve can fool Alice into opening a connection with 
herself without knowing the PSK that Alice shares with Bob. If Eve knew 
the PSK, then certainly it could pretend to be any one of the parties in 
the group that shares the PSK.

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 11 Oct 2019 12:36:47 +0000

Hi John,

I hope you also check the text for addressing Selfie attacks in the pull request I created Chris. Some more comments below.

--Mohit

On 10/11/19 10:38 AM, John Mattsson wrote:

Thanks Mohit,

What is a bug for you maybe is a feature for someone else. I wish we could put the requirement you suggest but there are several people who use PSKs that are shared by more than two nodes.

This is one possible solution. In effect you are using the CleintHello.random and ServerHello.random as endpoint identifiers. However, it seems cleaner to not re-use random nonces from the cryptographic protocols as identifiers.

Cheers,

John

From: TLS <[email-masked]><mailto:[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]><mailto:mohit.m.sethi=[email-masked]>
Date: Tuesday, 8 October 2019 at 21:08
To: Christian Huitema <[email-masked]><mailto:[email-masked]>, Christopher Wood <[email-masked]><mailto:[email-masked]>, Mohit Sethi M <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [TLS] Selfie attack

Hi Christian,

--Mohit

Hi Chris,

misused) in many places.

-- Christian Huitema

TLS mailing list

---

From: John Mattsson <[email-masked]>
Date: Fri, 11 Oct 2019 12:48:34 +0000

I think things mitigating the Selfie attack should be done in an errata to RFC 8446 or in a draft updating RFC 8446. If draft-ietf-tls-external-psk-importer is the mitigation against selfie attacks I think it needs to update RFC 8446.

John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]>
Date: Friday, 11 October 2019 at 14:32
To: Christopher Wood <[email-masked]>, Mohit Sethi M <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Selfie attack

    Hi,

    
    --Mohit
    
    On 10/8/19 7:46 PM, Christopher Wood wrote:
    > [1] https://protect2.fireeye.com/url?k=bb68fbe7-e7e2d928-bb68bb7c-0cc47ad93ea4-ddab33427b4471c9&q=1&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external-psk-importer
    >