On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen <j...@w1.fi> wrote: > 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'? > > [Joe] that was my mistake should be "/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? > > [Joe] 7170 says "length is the 2-octet unsigned integer in network byte order" > > 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). > > [Joe] Yes I agree that is better how about this as the text change IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" | 64) > > 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
