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

[Eric Rescorla <[e-mail]>]

Based on Ilari's comments, it seems like we just lost 9 bytes, and the TLS
1.3, label was 9 bytes, so these cancel each other out and we have a total
of 18 bytes to work with, including the label.

Hence, the following proposal for the complete label, where the longest
string is 18 bytes.

16 tls13 ext binder    #  was external psk binder key
16 tls13 res binder    #  was resumption psk binder key
17 tls13 c e traffic    #  was client early traffic secret
18 tls13 e exp master    #  was early exporter master secret
18 tls13 c hs traffic    #  was client handshake traffic secret
18 tls13 s hs traffic    #  was server handshake traffic secret
18 tls13 c ap traffic    #  was client application traffic secret
18 tls13 s ap traffic    #  was server application traffic secret
16 tls13 exp master    #  was exporter master secret
16 tls13 res master    #  was resumption master secret
9 tls13 key    #  was key
8 tls13 iv    #  was iv
14 tls13 finished    #  was finished
17 tls13 traffic upd    #  was application traffic secret
14 tls13 exporter    #  was exporter
13 tls13 derived    #  was derived

Further bikeshedding?

-Ekr


On Mon, Apr 24, 2017 at 9:39 AM, Eric Rescorla <[e-mail]> wrote:

> Nice catch.
>
> 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.
>
> -Ekr
>
>
>
> On Mon, Apr 24, 2017 at 9:16 AM, Ilari Liusvaara <[e-mail]
> > wrote:
>
>> On Mon, Apr 24, 2017 at 08:28:33AM -0700, Eric Rescorla wrote:
>> > On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara <
>> [e-mail]>
>> > wrote:
>> >
>> > > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote:
>> > > > https://github.com/tlswg/tls13-spec/issues/964
>> > > >
>> > > > Here is a proposed set of new labels, which, while slightly less
>> clear,
>> > > all
>> > > > fit
>> > > > into the 18 byte limit which Ilari (and I agree) says is what we
>> have.
>>
>> Aargh, turns out that Merke-Damgård strengthening probably affects
>> things...
>>
>> For SHA-256, MD strengthening consists of padding bit and 64-bit
>> message bit count, for total of 65-512 bits of padding.
>>
>> Trying to construct the raw SHA-256 message words for inner hash with
>> 9 byte label (K is key, L is label, H is hash).
>>
>> KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
>> 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
>> 00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH
>> HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8
>>
>> Adding 10th byte to label seems to blow the block (0x3C0=1*512+448):
>>
>> KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
>> 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
>> 00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH
>> HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000
>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0
>>
>>
>> For comparision, with SHA-384, the blocks for 9-byte label seem to be:
>>
>> KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK
>> KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636
>> 3636363636363636 3636363636363636 3636363636363636 3636363636363636
>> 3636363636363636 3636363636363636 3636363636363636 3636363636363636
>> 003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH
>> HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH
>> HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 0000000000000638
>>
>> (Which has 327 hash block padding bits).
>>
>>
>> -Ilari
>>
>
>