Subject: [TLS] Distinguishing between external/resumption PSKs

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 19 Sep 2019 10:52:09 +0000

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Martin Thomson
> Sent: 04 September 2019 02:46
> To: [email-masked]
> 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.

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 19 Sep 2019 14:31:36 +0100

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.

Does that answer your question?

Regards,

Jonathan

On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 19 Sep 2019 14:04:50 +0000

> From: Jonathan Hoyland <[email-masked]>
> Sent: 19 September 2019 14:32
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: Martin Thomson <[email-masked]>; [email-masked]
> 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.
> an OOB PSK then the `binder_key` will not match, and the handshake will fail.
> 

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.

> On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <mailto:[email-masked]>
> wrote:
> 
> > From: TLS <mailto:[email-masked]> On Behalf Of Martin Thomson
> > To: mailto:[email-masked]
> 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.
> 
> 
> mailto:[email-masked]

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 19 Sep 2019 15:25:24 +0100

That's how I would interpret the spec yes.
You could argue that there's a distinguishing attack where the attacker
measures the response time on PSKs to determine if it was an OOB PSK or a
resumption, but I think you could do equally well just by looking at the
PSK lengths, because resumption PSKs have a defined structure.

Regards,

Jonathan

On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) <[email-masked]> wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Sep 2019 11:26:42 -0400

> PSK lengths, because resumption PSKs have a defined structure.

I don't think that's quite right.  The PSKs resulting from NewSessionTicket
have a defined structure, but the PSK *IDs* do not; they're specified by
the server.  AFAICT, existing server stacks generate their own PSK IDs for
resumption PSKs, so from the application's perspective, the structure of
the resumption PSKs is unknown (or at best, specific to the TLS library in
use).

If I understand correctly, the worst case here would be:

1. The server application wants to have some behavior change based on the
use of an external PSK (not resumption)
2. The server TLS stack is configured with external and resumption PSKs
with the same PSK ID
3. The client sends a ClientHello using the resumption PSK
4. The server TLS stack attempts to verify the binder with the resumption
PSK and succeeds
5. The server application gets a session that is authenticated with the PSK
ID and notes that the PSK ID matches one of its external PSKs
6. The server application improperly does the external PSK behavior when in
fact resumption has happened

I might be missing something, but I don't see anything in the spec that
would prevent this situation from arising.  So it's up to the application
to choose its PSK IDs in such a way that they don't collide with resumption
PSK IDs.  But the fact that resumption PSK IDs are implementation-specific
mean that this is tough to do with any generality, unless you're willing to
rely on long pseudorandom strings not colliding with each other.

Maybe the answer is just that TLS stacks that handle their own resumption
caches need to signal to applications when that cache has been used vs. an
external PSK.

--Richard

>> > stored in one DB table, and (ignoring
>> https://tools.ietf..org/html/draft-ietf-
>> <https://tools.ietf.org/html/draft-ietf->

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 19 Sep 2019 16:43:31 +0100

Ah yes, Richard is right, the PSK IDs do not have a defined structure.

Having two different PSKs attached to a single PSK_ID should be banned if
it isn't already.

Regards,

Jonathan

On Thu, 19 Sep 2019 at 16:26, Richard Barnes <[email-masked]> wrote:

> I don't think that's quite right.  The PSKs resulting from
> NewSessionTicket have a defined structure, but the PSK *IDs* do not;
> they're specified by the server.  AFAICT, existing server stacks generate
> their own PSK IDs for resumption PSKs, so from the application's
> perspective, the structure of the resumption PSKs is unknown (or at best,
> specific to the TLS library in use).
>
> 5. The server application gets a session that is authenticated with the
> PSK ID and notes that the PSK ID matches one of its external PSKs
> 6. The server application improperly does the external PSK behavior when
> in fact resumption has happened
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Sep 2019 11:57:38 -0400

As nice as that requirement would be, I'm not sure it's really compatible
with the way people want to build software.  For example, OpenSSL right now
gets external PSKs by calling out to an external callback.  Given that
degree of separation, proactively assuring no collisions would be hard.

On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland <
[email-masked]> wrote:

>>>> But my question was before we even get that far - its an internal
>>>> server implementation decision how it determines whether the presented

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Sep 2019 08:06:26 -1000

There is also a privacy angle. From a privacy point of view, it is very nice that PSK cannot be distinguished from session resumption.

-- Christian Huitema 

> On Sep 19, 2019, at 5:57 AM, Richard Barnes <[email-masked]> wrote:
> 
> As nice as that requirement would be, I'm not sure it's really compatible with the way people want to build software.  For example, OpenSSL right now gets external PSKs by calling out to an external callback.  Given that degree of separation, proactively assuring no collisions would be hard.
> 
>> On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland <[email-masked]> wrote:
>> Having two different PSKs attached to a single PSK_ID should be banned if it isn't already. 
>> 
>> Regards,
>> 
>> Jonathan
>> 
>>>> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <[email-masked]> wrote:
>>> 
>>>> You could argue that there's a distinguishing attack where the attacker measures the response time on PSKs to determine if it was an OOB PSK or a resumption, but I think you could do equally well just by looking at the PSK lengths, because resumption PSKs have a defined structure. 
>>> 
>>> I don't think that's quite right.  The PSKs resulting from NewSessionTicket have a defined structure, but the PSK *IDs* do not; they're specified by the server.  AFAICT, existing server stacks generate their own PSK IDs for resumption PSKs, so from the application's perspective, the structure of the resumption PSKs is unknown (or at best, specific to the TLS library in use).
>>> 
>>> 1. The server application wants to have some behavior change based on the use of an external PSK (not resumption)
>>> 2. The server TLS stack is configured with external and resumption PSKs with the same PSK ID
>>> 4. The server TLS stack attempts to verify the binder with the resumption PSK and succeeds
>>> 5. The server application gets a session that is authenticated with the PSK ID and notes that the PSK ID matches one of its external PSKs
>>> 6. The server application improperly does the external PSK behavior when in fact resumption has happened
>>> 
>>> I might be missing something, but I don't see anything in the spec that would prevent this situation from arising.  So it's up to the application to choose its PSK IDs in such a way that they don't collide with resumption PSK IDs.  But the fact that resumption PSK IDs are implementation-specific mean that this is tough to do with any generality, unless you're willing to rely on long pseudorandom strings not colliding with each other.
>>> 
>>> Maybe the answer is just that TLS stacks that handle their own resumption caches need to signal to applications when that cache has been used vs. an external PSK.
>>> 
>>> --Richard
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Jonathan
>>>> 
>>>>> > stored in one DB table, and (ignoring https://tools.ietf...org/html/draft-ietf-

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Sep 2019 13:35:40 -0500

On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
> There is also a privacy angle. From a privacy point of view, it is
> very nice that PSK cannot be distinguished from session resumption.

This.

PSK is the right way to, for example, integrate Kerberos into TLS 1.3
now.  But it's no eavesdropper's business whether a session used
Kerberos for setup or resumption tickets.

Nico
--

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Sep 2019 16:57:17 -0400

I don't think anyone's asking for these cases to be differentiable on the
wire.  The question is whether the *server* can differentiate, in
particular, the application running on the server.

--Richard

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 19 Sep 2019 22:16:13 +0100

> particular, the application running on the server.
Exactly. I hope it's not controversial that the TLS server knows what's
going on / what it's agreeing to. The specific restriction I was suggesting
is that a server shouldn't accept multiple PSKs with the same PSK_ID.
That would require the server to do things like trial decryption, and has
so many ways it could go wrong. The PSK Importer draft is designed to make
it easy to take a single PSK and PSK_ID and diversify them safely.
Using one PSK_ID for multiple PSKs has no benefits and lots of risks.

Regards,

Jonathan

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Sep 2019 16:48:52 -0500

> particular, the application running on the server.

And the answer to that one is "yes", because the server has control over
the PSK IDs.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Sep 2019 18:03:44 -0400

> And the answer to that one is "yes", because the server has control over

That glosses over an important distinction made up-thread: When we say "the
server", there is typically a distinction between the TLS stack and the
server application logic.  Resumption PSKs are typically controlled by the
TLS stack, while external PSKs are provided by the application logic.  The
question is how the application logic, when presented with a session
authenticated under a given PSK ID, can distinguish whether the PSK used
was one provided by the TLS stack for resumption, or provided by the
application logic.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Sep 2019 17:11:00 -0500

> was one provided by the TLS stack for resumption, or provided by the

Depends on which gets a first crack at it.

You could have a plugin system as well where the plugins are invoked by
the TLS stack.  And again, order may matter if there's no reliable way
to "taste" the PSK IDs.

So the answer is that order of evaluation matters, and that's OK.

Nico
--

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 20 Sep 2019 08:07:30 +0000

Hi all,

Thanks Owen for starting this discussion. For some context, the EMU working group is currently working on a document titled "Using EAP-TLS with TLS 1.3": https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06

There has been recent discussion in the working group on whether EAP-TLS should support PSKs for the initial authentication. The current text says "Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption.".

As Richard points out, there is a distinction between "the server". Almost all EAP-TLS implementations use existing cryptographic libraries which handle the resumption PSK and PskIdentity. However, it is not clear (to me) who would set the PSKIdentity for the initial authentication. Should it be left to the application logic (in this case the EAP server)?

Do we care about PSKIdentity collisions? As Jonathan points out, having several PSKs with the same identity may require trial decryption and that can go wrong in several ways.

Chrisitian Huitema rightly points out that having free from PSKIdentity is good from a privacy perspective as an attacker cannot distinguish between initial authentication and resumption. However, if the server first has to lookup the resumption PSKs table before checking for any matching external PSKs, the timing information would leak that nonetheless.

Should a server issue NewSessionTickets when the original authentication itself was based on PSK? It would be nice to prevent tracking based on PSKIdentity.

We (or at least I) could certainly benefit with some more guidance from the TLS working group on this topic.

--Mohit

On 9/20/19 1:03 AM, Richard Barnes wrote:
On Thu, Sep 19, 2019 at 5:49 PM Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

That glosses over an important distinction made up-thread: When we say "the server", there is typically a distinction between the TLS stack and the server application logic.  Resumption PSKs are typically controlled by the TLS stack, while external PSKs are provided by the application logic.  The question is how the application logic, when presented with a session authenticated under a given PSK ID, can distinguish whether the PSK used was one provided by the TLS stack for resumption, or provided by the application logic.

--Richard

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 20 Sep 2019 13:32:03 +0200

> And the answer to that one is "yes", because the server has control over

You are making a lot of implicit assumptions for that. Consider a
"server" consisting of multiple front end implementations all
connected to a DB back-end. Does that "server" has control over PSK
IDs? A server can also be replaced on an upgrade with a different
implementation, or a different version of the implementation, does
that also guarantee that the server still has control over the PSK
IDs? It looks to me like a hard problem to tackle except for few
straightforward cases.

regards,
Nikos

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Sep 2019 12:08:40 -0700

On Fri, Sep 20, 2019 at 4:32 AM Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> IDs?

While Nico's assertion isn't always practical, I think it fits a pretty
common pattern: a TLS-terminator / edge server validates that the server
issued the credential, without hitting the backing credentials database.
These servers often perform similar checks on HTTP Cookie headers. Then, as
the traffic is passed to the application, the credential is actually
checked against the database.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Sep 2019 16:37:42 -0700

On Fri, Sep 20, 2019 at 1:07 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> Chrisitian Huitema rightly points out that having free from PSKIdentity is
> good from a privacy perspective as an attacker cannot distinguish between
> initial authentication and resumption. However, if the server first has to
> lookup the resumption PSKs table before checking for any matching external
> PSKs, the timing information would leak that nonetheless.
>

This timing issue is a good concern to raise.

However, it made me wonder why the various ESNI drafts don't allow any
ClientHello field or extension to be encrypted.

thanks,
Rob

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 23 Sep 2019 17:49:02 +0000

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

---

From: "Hao, Feng" <[email-masked]>
Date: Tue, 24 Sep 2019 14:07:42 +0000

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,

    
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

---

From: John Mattsson <[email-masked]>
Date: Tue, 24 Sep 2019 15:17:09 +0000

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

        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

    
    
    [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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Sep 2019 11:59:01 -0400

> On Sep 23, 2019, at 1:49 PM, Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
> 
> Hi all,
> 

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

-- 
	Viktor.

---

From: "Hao, Feng" <[email-masked]>
Date: Tue, 24 Sep 2019 16:19:07 +0000

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,

    

    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

            Hi all,