On 04/24/2017 05:04 PM, Eric Rescorla wrote: > > > On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett <davemgarr...@gmail.com > <mailto: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... >
Double-plus extra surefire way to avoid cross-version badness. > > 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"... > Probably fine. > > 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. > It seems not worth doing, yes. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
