Subject: Re: [TLS] Pre_shared_key Extension Question

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 9 Sep 2016 16:45:01 +0200

Hi Ekr,

thanks for the response.

The psk_identity_hint in RFC 4279 was sent from the server to the client 
and was a mechanism that was believed to be needed by the 3GPP in their 
bootstrapping architecture, which in the end was never widely used (as 
far as I know). So, not necessarily a super important features, as it 
seems.

As mentioned in my other mail regarding sending the ticket together with 
the long-term PSK identity could be addressed better by clarifying the 
server is intending to keep the ticket cached for the time indicated in 
ticket_lifetime (rather than saying the opposite which may lead 
implementers to care less).

Hence, I would mind if you delete the following two sentences in Section 
4.5.1 "New Session Ticket Message":

"
It MAY delete the ticket earlier based on local policy. A server MAY 
treat a ticket as valid for a shorter period of time than what is stated 
in the ticket_lifetime.
"

Ciao
Hannes

On 08/18/2016 12:17 AM, Eric Rescorla wrote:
> 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] <mailto:[email-masked]>> wrote:
>
>     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
>
>
>     _______________________________________________
>     TLS mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 9 Sep 2016 16:47:31 +0200

Hi Benjamin,

regarding the use case you describe below: at least for us at ARM this 
is not the way how we plan to use PSK. We use a key distribution 
protocol (namely OMA LWM2M) to provision the PSK identity and the PSK 
secret used with TLS.

So, from that point of view there is no need for a PSK rollover as you 
describe below.

Ciao
Hannes

On 08/18/2016 05:47 PM, Benjamin Kaduk wrote:
> 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:
>>
>>     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?
>>
>>
>> I'm not sure I follow. Can you say more?
>>
>
> 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: "Salz, Rich" <[email-masked]>
Date: Fri, 9 Sep 2016 16:03:10 +0000

We don't do cert rollover, we shouldn't do PSK rollver.