On Mon, Sep 19, 2016 at 5:26 AM, David Woodhouse <dw...@infradead.org>

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


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

TLS mailing list

Reply via email to