On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> Errata 5127: https://www.rfc-editor.org/errata/eid5127
> Proposed State: Verified
> Revision:
> Section 5.2.
> OLD
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> "\0" | 64)
>
> NEW
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> '/0', 64)
Why would this change "\0" to '/0'?
How is that 64 supposed to be encoded if it is the "seed" argument to
PRF(secret, label, seed) define in RFC 5246 Section 5?
> Notes:
> According to
>
> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
>
> 5. HMAC and the Pseudorandom Function
>
> "TLS's PRF is created by applying P_hash to the secret as:
>
> PRF(secret, label, seed) = P_<hash>(secret, label + seed)"
>
> In this case the seed is the 2-byte length of the output as defined by RFC
> 5295. In terms of P_<Hash> the derivation would look like:
>
> IMSK = P_<Hash>(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks
correct, but it looks strange to me if we are trying to include the
first 0x00 at the end of the "label" argument to PRF(secret, label,
seed) especially when the label is define to be "an ASCII string. It
should be included in the exact form it is given without a length byte
or trailing null character". I would have expected
"teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40 would
be the "seed". In other words:
IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
0x00 | 0x00 | 0x40).
Please note that this is followed by this explanation:
where "|" denotes concatenation, EMSK is the EMSK from the inner
method, "teapbind...@ietf.org" consists the ASCII value for the
label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
octet (0x00 in hex), length is the 2-octet unsigned integer in
network byte order, and TLS-PRF is the PRF negotiated as part of
TLS handshake [RFC5246].
Using "64" as the seed would require the reader to interpret 64 to be
the "length" and use the "2-octet unsigned integer in network byte
order" from that to determine the exact encoding of the seed. And the
first 0x00 as part of the label to TLS-PRF would be be confusing as well
with this explanation that is clearly defining the label without
including the explicitly noted "\0" after the label.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
