On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote: > 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"
It does, but how would one know that this particular 64 is "length"? This "64" argument is the "seed" argument to PRF and that could be any arbitrary data.. The length of TLS-PRF output is meta data that is not passed to the PSK() defined in RFC 5246 directly as an argument, i.e., inclusion of the output length in the seed is something that RFC 7170 is doing here for some reason and it could have included any other arbitrary seed value here for that matter.. IMHO, this is too vague and it would be better to spell out the exact contents of the seed value (0x00 | 0x40 im this particular case shown here or 0x00 | 0x00 | 0x40 if following the proposal below). > > 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) It looks quite strange to me to define a binary seed data as a concatenation of a string and an integer. I have the exact same question about the encoding of 64 here since this does not describe explicitly this instance of 64 to be the "length" which has the particular encoding described in RFC 7170. For me, using 0x00 | 0x00 | 0x40 and deleting that note about length encoding would be significantly clearer. If that is not acceptable, I would still replace "\0" with 0x00 in this context since this is not an ASCII string or label anymore, but binary data. And in addition to that, the "64" part would need to be replaced with something like "TLS-PRF output length" and then the "TLS-PRF output length" could be mentioned to be 64 in this instance and the encoding for that would be 2-octet unsigned integer in network byte order. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
