On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote: > I have been reviewing this erratum, and I think it is correct, but I have a > question: > > > Section 5.2. says: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "[email protected]" | > > "\0" | 64) > > It should say: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "[email protected]" | > > "\0", 64) > > Is that last parameter “seed” or “seed size”? Confusedly yours.
It's neither.. The main problem here is in RFC 7170 not defining TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as part of TLS handshake" while RFC 5246 does not define PRF as a function with arguments that would be compatible with even a single instance of TLS-PRF() use in RFC 7170.. And the RFC 7170 uses are inconsistent with themselves like this erratum show, but this instance is not the only issue: TLS-PRF() is used with two, three, and even four arguments. This leaves the implementer guessing what exactly these maps 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)" So this PRF(secret, label, seed) is what is available and RFC 5246 does not define that 64 part in the example above as an argument. That 64 is the number of octets of output that is fetched from the PRF. In other words, RFC 7170 should have defined TLS-PRF(secret, label, seed, output-len-in-octets) as taking output-len-in-octets of octets from the output of RFC 5246 PRF(secret, label, seed). With this, following fixes would be needed for the users for TLS-PRF() in RFC 7170: IMSK: This could be one of following (last two having identical outcome): TLS-PRF(EMSK, "[email protected]", "", 64) TLS-PRF(EMSK, "[email protected]", "\0", 64) TLS-PRF(EMSK, "[email protected]", "\0" | 0x00 | 0x40, 64) TLS-PRF(EMSK, "[email protected]", 0x00 | 0x00 | 0x40, 64) However, this TLS-PRF() instance is more strange.. The "Optional data parameter is not used in the derivation" part does not make any sense since I think "optional data parameter" is a reference to the seed value going into PRF. The following description is then clearly indicating that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer in network byte order". That seems to be talking about some binary data and the seed is the only place where such byte order and field size discussion would apply. I'm actually implementing that last one because of that discussion in the RFC. It should also be noted that the "First 32 octets of TLS-PRF(..., 64)" does not make much sense since "TLS-PRF(..., 32)" would cover same. This would seem to imply that "First 32 octets of TLS-PRF" could actually be trying to address that PRF argument mismatch. Anyway, maybe this should simply say: IMSK = TLS-PRF(EMSK, "[email protected]", 0x00 | 0x00 | 0x40, 32) (or with empty seed "" instead of that 3 octet seed) The "and the length is 64 octets" part just above this is a bit confusing with this, though. IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) (this is actually unchanged) MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64) (i.e., add the missing empty seed) EMSK = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", "", 64) (i.e., add the missing empty seed) -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
