On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario <hka...@redhat.com> wrote:
> On Monday 04 January 2016 09:44:57 Eric Rescorla wrote: > > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario <hka...@redhat.com> > wrote: > > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null > > > > >> byte > > > > >> for the "label"?> > > > > > > > > > > No. I wonder if we should instead add the '\0' explicitly in the > > > > > 4.8.1 for maximal clarity. > > > > > > > > Either that, or just remove the trailing 00 from the binary > > > > description. > > > > > > the 0-byte is a C-ism that looks like a wart to me > > > > > > neither of the previous TLS versions used null-terminated C-style > > > strings so why TLS1.3 should? Especially in just one place > > > > The idea is to make this prefix-free. I added it as an explicit byte > > but would > > be ok with a different separator as long as we banned it from the > > context strings. > > Calling it explicitly a separator would be less confusing. > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing "Following that padding is a context string used to disambiguate signatures for different purposes. The context string will be specified whenever a digitally-signed element is used. A single 0 byte is appended to the context to act as a separator." Advising implementers to check other values passed in for it and > aborting if detected would be even better > This seems like it's probably not necessary because these strings are standardized and internal to the implementation. -Ekr > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
