Re: [TLS] draft-ietf-tls-tls13-21 posted

[Matt Caswell <[e-mail]>]

On 4 July 2017 at 11:50, Ilari Liusvaara <[e-mail]> wrote:
> On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
>> On 4 July 2017 at 01:01, Eric Rescorla <[e-mail]> wrote:
>> > - Modifying the key derivation for PSKs so that each session ticket
>> >   is associated with a distinct PSK.
>>
>> Draft-21 says this about the ticket nonce:
>>
>>           opaque ticket_nonce<1..255>;
>> ...
>>    ticket_nonce  A unique per-ticket value.
>>
>>
>> Within what context is "uniqueness" required? I am assuming that
>> uniqueness within the context of a single TLS connection is all that
>> is needed?
>
> Yes, It has to be unique within a connection.
>
>> The nonce can be anything between 1 and 255 bytes long. There is no
>> guidance on a suitable length, so I am assuming I can choose anything
>> I like as long as the uniqueness constraint is met. OpenSSL
>> (currently) only ever issues a single ticket per TLS connection so is
>> a single 0 byte sufficient?
>
> Yes, if you only have one ticket per connection, then any legal fixed
> value is acceptable.

Thanks. Another slightly confusing thing about the way this is
currently specified:

The spec says:

   The PSK associated with the ticket is computed as:

       HKDF-Expand-Label(resumption_master_secret,
                        "resumption", ticket_nonce, Hash.length)

Where HKDF-Expand-Label is defined as:

       HKDF-Expand-Label(Secret, Label, HashValue, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)
...
        Note that in some cases a zero- length HashValue (indicated by
"") is passed to HKDF-Expand-Label.

Note that the third parameter here is explicitly expected to be either
a hash or "" (i.e. zero length). But in the ticket_nonce case this is
NOT a hash value. AFAICT this is the only time in the spec that
something other than a hash or "" is used for this parameter. I'm
assuming this is intentional and we are supposed to pass the nonce
through "as is" (i.e. there is no implicit requirement to hash it
first). Probably the definition of HKDF-Expand-Label needs to be
updated to allow for this usage.

Matt