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

> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> > > More compact and makes the option where server sends some bad option
> > > more clear.
> Note that if we really want to be more compact, we might also observe
> that there is a redundant length field in the extension as sent by the
> client:
>            case client_hello:
>                PskIdentity identities<6..2^16-1>;
> Each extension has at least four bytes on the wire — the extension_type
> itself, and the length field of the extension_data in a uint16.
> If I am interpreting the spec correctly, then the data for the
> PreSharedKeyIdentity extension in the ClientHello then follows that
> with another uint16, which is *always* a value two lower than the one
> which immediately precedes it.
> e.g.
>   0x00 0x29      // ExtensionType extension_type == 41
>   0x00 0x14      // opaque extension_data<0..2^16-1>
>     // This length field is entirely redundant:
>     0x00 0x12      // PskIdentity identities<6..2^16-1>
>                      // First identity:
>       0x00 0x00      // PskKeyExchangeMode, PskAuthenticationMode
>       0x00 0x04      // opaque identity<0..2^16-1>
>         0x44 0x61 0x76 0x65 // "Dave"
>                      // Second identity:
>       0x00 0x00      // PskKeyExchangeMode, PskAuthenticationMode
>       0x00 0x06      // opaque identity<0..2^16-1)>
>         0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë"
> 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.

> 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
the key needs to be in the CH.

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

TLS mailing list

Reply via email to