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

[Hao, Feng]

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"
 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#append
>ix-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" 
>>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  on behalf of "Hao, Feng"
>> 
>> Date: Tuesday, 24 September 2019 at 16:09
>> To: Mohit Sethi M ,
>> "Owen Friel (ofriel)" , Jonathan Hoyland
>> 
>> Cc: "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"
>> > 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-869a17b5b21
>>b-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 t

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

[Christopher Wood]

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"  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  on behalf of "Hao, Feng" 
> 
> Date: Tuesday, 24 September 2019 at 16:09
> To: Mohit Sethi M , 
> "Owen Friel (ofriel)" , Jonathan Hoyland 
> 
> Cc: "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" 
>  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 
>

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

[Hao, Feng]

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"  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  on behalf of "Hao, Feng" 

Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M , "Owen 
Friel (ofriel)" , Jonathan Hoyland 

    Cc: "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" 
 
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

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

[Viktor Dukhovni]

> On Sep 23, 2019, at 1:49 PM, Mohit Sethi M 
>  wrote:
> 
> Hi all,
> 
> On the topic of external PSKs in TLS 1.3, I found a publication on the 
> Selfie attack: https://eprint.iacr.org/2019/347

If I not missing something, eeels like simple misconfiguration.
How is this different from, say, using the same wildcard certificate
on both nodes?

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

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  on behalf of "Hao, Feng" 

Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M , "Owen Friel 
(ofriel)" , Jonathan Hoyland 
Cc: "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" 
 
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

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

[Hao, Feng]

On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"  wrote:

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on the 
Selfie attack: https://eprint.iacr.org/2019/347

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://eprint.iacr.org/2014/585.pdf
[2] https://arxiv.org/abs/1802.04900
[3] https://eprint.iacr.org/2010/136.pdf 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on the 
Selfie attack: https://eprint.iacr.org/2019/347

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.

--Mohit

On 9/19/19 5:04 PM, Owen Friel (ofriel) wrote:
>
>> -Original Message-
>> From: Jonathan Hoyland 
>> Sent: 19 September 2019 14:32
>> To: Owen Friel (ofriel) 
>> Cc: Martin Thomson ; tls@ietf.org
>> Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>
>> Hi Owen,
>>
>> If I understand your question correctly the distinguishing is done implicitly
>> (not explicitly) through the key schedule.
>> If the client and server do not agree on whether the PSK is a resumption or
>> an OOB PSK then the `binder_key` will not match, and the handshake will fail.
>>
>> See pp. 93-94 of the spec.
> And we only even get that far on the off chance that an ext 
> PskIdentity.identity is exactly the same as a res PskIdentity.identity. e.g. 
> a client presents an ext PskIdentity.identity, the server somehow thinks it’s 
> a res PskIdentity.identity, and then handshaking will fail, not only because 
> the actual raw PSK is likely different but the binders will not match due to 
> different labels.
>
> But my question was before we even get that far - its an internal server 
> implementation decision how it determines whether the presented 
> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB 
> table vs. a res cache first to find a PskIdentity.identity match. And say it 
> fails to find an ext match then it tries to find a res match, and if it finds 
> a match, then it knows what binder label to use.
>
>
>> Does that answer your question?
>>
>> Regards,
>>
>> Jonathan
>>
>> On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) 
>> wrote:
>>
>>> -Original Message-
>>> From: TLS  On Behalf Of Martin Thomson
>>> Sent: 04 September 2019 02:46
>>> To: mailto:tls@ietf.org
>>> Subject: Re: [TLS] Binder key labels for imported PSKs
>>>
>>>
>>> When we built the ext/res distinction, there was a clear problem
>> expressed.
>>> We had the potential for both to be used by the same servers at the same
>>> time (though not for the same connection) and distinguishing between
>> them
>>> was important
>> Martin, maybe I am missing something in the threads on this. Is there
>> anything explicit planned in ClientHello PreSharedKeyExtension or
>> PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
>> it up to server implementation and how the server handles the opaque
>> PskIdentity.identity? e.g. ImportedIdentity.external_identity fields could be
>> stored in one DB table, and (ignoring https://tools.ietf.org/html/draft-ietf-
>> tls-external-psk-importer-00#section-9 for now) the server on receipt of a
>> ClientHello searches for PskIdentity.identity in its
>> ImportedIdentity.external_identity  table and if that lookup fails, then try 
>> to
>> parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order of
>> those two operations is of course implementation specific too.
>>
>>
>> ___
>> TLS mailing list
>> mailto: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