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

On Wed, Jul 5, 2017 at 1:40 AM, Matt Caswell <frodo@baggins.org> wrote:

> On 4 July 2017 at 11:50, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
> >> On 4 July 2017 at 01:01, Eric Rescorla <ekr@rtfm.com> 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.
>

Yes, that might not be a terrible idea. I'd also be open to replacing
the hashes of 0 with an n-byte length 0 string. It's a tiny paper
cut (and a wire format change), but would make things slightly simpler .

-Ekr

> Matt
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>