Subject: [TLS] Pre_shared_key Extension Question

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Aug 2016 10:39:15 +0200

Hi all,

the currently defined “pre_shared_key” extension allows clients to send
a list of the identities. I was wondering in what use cases this is
useful and what policy guides the server to pick the most appropriate
psk identity. I couldn't find any discussion in the document about this
aspect.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 15:17:14 -0700

The intention here was to compensate for not having psk_identity_hint.
However, it also allows you to do resumption of PSK-established sessions.

It would be a fairly significant simplification to say you could only have
one PSK, because then we could easily require the client to prove knowledge
of the key, for instance by stuffing a MAC at the end of the ClientHello as
we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any
in the Web context. If not, we should remove this feature.

-Ekr

On Thu, Aug 11, 2016 at 1:39 AM, Hannes Tschofenig <
[email-masked]> wrote:

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Aug 2016 10:18:36 -0500

On 08/17/2016 05:17 PM, Eric Rescorla wrote:
> It would be a fairly significant simplification to say you could only
> have one PSK, because then we could easily require the client to prove
> knowledge of the key, for instance by stuffing a MAC at the end of the
> ClientHello as we discussed in Berlin.
>
> So:
> Is there any demand for multiple identities? I do not believe there is
> any in the Web context. If not, we should remove this feature.
>

Then at PSK rollover time, clients are expected to fall back to a new
TLS connection using the other PSK?

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Aug 2016 08:29:31 -0700

On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <[email-masked]> wrote:

> Then at PSK rollover time, clients are expected to fall back to a new TLS
> connection using the other PSK?
>

I'm not sure I follow. Can you say more?

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Aug 2016 10:47:08 -0500

On 08/18/2016 10:29 AM, Eric Rescorla wrote:
>
>
> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     It would be a fairly significant simplification to say you could
>>     only have one PSK, because then we could easily require the
>>     client to prove knowledge of the key, for instance by stuffing a
>>     MAC at the end of the ClientHello as we discussed in Berlin.
>>
>>     So:
>>     Is there any demand for multiple identities? I do not believe
>>     there is any in the Web context. If not, we should remove this
>>     feature.
>>
>
>     Then at PSK rollover time, clients are expected to fall back to a
>     new TLS connection using the other PSK?
>
>

With caveat that I don't deploy PSK-based systems and this is before my
morning coffee ... suppose I have a related group of IoT devices that
use TLS+PSK to communicate.  But, I don't want the long-term
cryptographic secret (the PSK) to be permanent and unchanging, since
that's not best practices and leaves me in a tough spot if it ever
leaks.  So, I generate a new PSK every three months, provide a device on
the network that lets the devices retrieve the new one, and everyone is
supposed to expire the old one a month after the new one is available. 
My PSK identities could then be something like "2016Q2" (or something
more complicated; it doesn't really matter), but since the devices are
autonomous and not synchronized, I can't have a "flag day" transition
from using the 2016Q1 to 2016Q2 key.  At some point, a device will try
to use the 2016Q2 key as a client against a server device that only has
the 2016Q1 key, and the handshake fails.  In the rollover scenario I
describe, the client can then try a new handshake with the 2016Q1 key
instead of the 2016Q2 key, which should succeed.

Given the benefits of only allowing one PSK identity from the client, I
am fine with requiring the second hanshake in this (contrived?)
scenario; I just wanted to mention it so that we know what we're getting
into.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Aug 2016 08:54:08 -0700

On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk <[email-masked]> wrote:

> morning coffee ... suppose I have a related group of IoT devices that use
> TLS+PSK to communicate.  But, I don't want the long-term cryptographic
> secret (the PSK) to be permanent and unchanging, since that's not best
> practices and leaves me in a tough spot if it ever leaks.  So, I generate a
> new PSK every three months, provide a device on the network that lets the
> devices retrieve the new one, and everyone is supposed to expire the old
> one a month after the new one is available.  My PSK identities could then
> be something like "2016Q2" (or something more complicated; it doesn't
> really matter), but since the devices are autonomous and not synchronized,
> I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key.
> At some point, a device will try to use the 2016Q2 key as a client against
> a server device that only has the 2016Q1 key, and the handshake fails.  In
> the rollover scenario I describe, the client can then try a new handshake
> with the 2016Q1 key instead of the 2016Q2 key, which should succeed.
>

That would be the implication at this point, I think, though one could
imagine having some HRR version that was like "I have no idea about this
PSK". This would be easy with davidben's proposed new HRR Structure.

-Ekr

> Given the benefits of only allowing one PSK identity from the client, I am
> fine with requiring the second hanshake in this (contrived?) scenario; I
> just wanted to mention it so that we know what we're getting into.
>
> -Ben
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 18 Aug 2016 16:05:40 +0000

> PSK". This would be easy with davidben's proposed new HRR Structure.

Note this would require that the client and server a priori agree they're
doing PSK-based identities and not certificate-based identities. Otherwise
the server doesn't know whether to do PSK + please use this identity
instead or full handshake + certs. Though that seems an okay requirement
since what kind of identities you use (PSK, X.509 web PKI, Kerberos,
whatever else) is more part of the application profile and not really
negotiated at TLS.

Another option for your scenario is you ensure that the 2016Q2 key is
installed on the servers before it is installed on any client. The server
is still allowed to accept multiple PSK identities whether there's one or
multiple client advertisements. The multiple client advertisement just
means you can install 2016Q2 in any order.

(I am not actually involved in PSK-based systems either. I too would love
to have only one PSK offer since, for resumption purposes, there's no need
for multiple. But I can't speak to actual PSK-based systems.)

David

>> am fine with requiring the second hanshake in this (contrived?) scenario; I