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.
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.
But OK, if none of the information included by RFC5077 is in that
category then we really do need to cope with PSK identity fields which
can theoretically *each* be larger than the amount you can fit into a
single TLS extension...
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. And
the binary nature of 'session resumption' PSK identities will have an
effect on the crypto library APIs used to manage that — which as I
said, currently assume that they can use NUL-terminated strings.
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.
> > Is it permitted, and what is the meaning, to request a cipher suite of
> > (e.g.) TLS_PSK_WITH_AES_256_CBC_SHA and set PskKeyExchangeMode in the
> > identity to 'psk_dhe_ke'? Or conversely, to use the cipher suite
> > TLS_DHE_PSK_WITH_AES_256_CBC_SHA with PskKeyExchangeMode set to
> > 'psk_ke'?
> >
> > This seems redundant to me at first glance (unless some combinations
> > really do mean that you end up doing DHE *twice*) and could probably do
> > with some clarification.
>
> TLS 1.3 cipher suites do not convey key exchange mode, just AED and KDF. See
> https://tlswg.github.io/tls13-spec/#cryptographic-negotiation for an overview
> of
> negotiation.
Ah, thanks. That makes more sense now.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
