Re: [TLS] TLS1.3 + PSK with multiple identities

[Eric Rescorla <[e-mail]>]

On Mon, Sep 19, 2016 at 5:26 AM, David Woodhouse <[e-mail]>
wrote:

> On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > > Do we care that the '0x00 0x12' bytes on my third line above are
> > > entirely redundant on the wire? Or have I interpreted it wrong?
> >
> > Not enough to fix it, this is just the way TLS rolls.
>
> An interesting contrast to Nikos's observation that using the index in
> the response is "used nowhere else in TLS" — which he could have
> phrased using similar words. But I suppose in that case you're saving a
> *lot* more than two bytes in the ServerHello, so it makes sense to
> deviate from "the way TLS rolls" :)
>

Yes.


> > Is there no way the PSK identities for session resumption could be made
> > > smaller? Of the data which RFC5077 suggests that we put into a session
> > > ticket (and thus the PSK identity), is there *none* of it which could
> > > be sent later in a ClientKeyExchange packet?
> >
> > No. Also, there isn't a CKE record in TLS 1.3. All information needed to
> derive
> > the key needs to be in the CH.
>
> Well, that was kind of my point. Information needed to derive the *key*
> needs to be in the ClientHello.
>
> But if it's auxiliary information which isn't actually *needed* to
> derive the key or to select which {identity to use,session to resume},
> then perhaps the client could be required to supply it afterwards.
>

You need the complete ticket to make sensible decisions.


And then the client only needs to supply one copy of it for the
> identity which the server actually selected, not one for *each*
> identity which was being offered by the client.
>

We're most likely going to allow only on PSK anyway.


I share Nikos's concern about using the PSK identity for two completely
> different types of identifiers — especially given that one type has
> historically been defined as UTF-8 text, while the other is binary.
>
> The reason I care about this right now is that we're looking at using
> PSK to bootstrap a DTLS connection in the context of an SSL VPN,
> currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension.


I recommend against this: I very much doubt that we are going to adopt this
draft in TLS.


So it would be useful to have some clarity on the UTF-8 requirement
> from RFC4279, and whether it's being completely abandoned with TLS 1.3.
>

It's being abandoned. PR welcome.

-Ekr