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

[Eric Rescorla <[e-mail]>]

PR here:
https://github.com/tlswg/tls13-spec/pull/977

On Mon, Apr 24, 2017 at 8:12 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett <[e-mail]>
> wrote:
>
>> On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote:
>> > 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?
>>
>> I think "tls13 c e traffic" is the only one that could be tweaked to be a
>> little more obvious. Abbreviating "early data" as "ed", instead of just
>> "early" as "e", would still fit and follow the same pattern as the other
>> traffic labels.
>>
>
> Unfortunately this woud explode tls13 e exp master.
>
> -Ekr
>
> Other than that, this sounds fine.
>>
>>
>> Dave
>>
>
>