Re: [TLS] DTLS Key Separation PR

tl;dr keep the space.

I had a little trouble reproducing the 12 from RFC 8446, so I double-checked.

...

Working from the base for SHA-256:

The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to allow for padding.  Therefore we have 55 bytes to use without having to run two blocks through SHA-256.

HMAC-Hash = H(K XOR opad || H(K XOR ipad || text))

Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down to 23 bytes for text before it adds a block.

HKDF-Expand =  HMAC-Hash(PRK, info | 0x01)

This takes one more.  Down to 22.

HKDF-Expand-Label passes info in the form of:

       struct {
           uint16 length = Length;
           opaque label<7..255> = "tls13 " + Label;
           opaque context<0..255> = Context;
       } HkdfLabel;

which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 = 10.  So we get 12.

"c ap traffic" is 12 bytes long, so yeah it *looks* like we're stuck if we care about not adding too many extra hash iterations.

...

But if you look at the key schedule, we always provide a context for those cases we use "c ap traffic".  Those will always spill over into the next iteration as Context is 32 bytes.  So for those cases, we have a whole 32 bytes extra to play with.  The only cases with an empty Context are "derived" and "res binder"|"ext binder".  Those max out at 10, so we seem to have two whole bytes of wiggle room.

You can safely add the space.

On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote:
> Hi folks,
> 
> As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key separation.
> 
> See: 
> https://github.com/tlswg/dtls13-spec/pull/99
> 
> Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13"
> 
> -Ekr
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>