On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett <davemgarr...@gmail.com> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
