Re: [TLS] Issue #964: Shortened HKDF labels

[Eric Rescorla <[e-mail]>]

On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett <[e-mail]>
wrote:

> On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote:
> > 9 bytes seems a bit cramped. What I suggest here is that we remove the
> "TLS
> > 1.3, ", as it was just there by analogy to the handshake context and then
> > we are back to having 18 bytes.
> >
> > If people feel like we should have some "TLS" prefix, I think "TLS "
> would
> > be enough, giving us 1 bytes.
>
> (assuming you mean 14 bytes here)
>
> If I remember correctly, in some discussion quite a while back, we decided
> we wanted to bake the version number into the labels.


I don't remember there really being a reason for that...


This could be done more compactly by adding a ProtocolVersion value (2
> bytes) to the HkdfLabel struct. "TLS" could be stuck in there as a static 3
> byte opaque string, with no length or space. (yeah, the combined plaintext
> will go "TLSclient hs traffic", but nobody needs to care)
>

How is this better than "TLS13client hs traffic" in the label?

Note that we could do "T13"...


With ProtocolVersion + "TLS" + dropped length byte, that results in a label
> space of 14 bytes, whilst still keeping the version number baked into the
> label directly.
>
> An extra couple of bytes could even be salvaged out of the HkdfLabel
> struct by ditching the lengths of the 'label' and 'hash_value' fields,
> though going this far may be overkill.


That seems very dangerous.

-Ekr


>
>
> Dave
>