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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
