Re: [TLS] A small detail in HMAC key generation for Finished message

[Eric Rescorla <[e-mail]>]

On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario <[e-mail]> wrote:

> On Monday 04 January 2016 09:44:57 Eric Rescorla wrote:
> > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario <[e-mail]>
> 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
>