On Mon, 9 Jan 2023, at 14:11, Heikki Vatiainen wrote: >> On a related note, whilst we are here, it does raise the question on how we >> got: >> >> "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" >> >> The '0x00 || 0x40' (64 network order 16bit length concatenation) looks >> superfluous and I cannot see what they add here (as the label is not >> recycled elsewhere) and makes me wonder if it was unintended? > > See https://www.rfc-editor.org/rfc/rfc5295#section-3.1 > Because IMSK is derived from EMSK I think it has to be defined as currently > shown in draft 7170bis-02. One of RFC 5295 requirements is that the derived > key, in this case IMSK, has to be at least 64 octets. > > Maybe this clarifies section 5.2 in the draft (be specific that 64 octets are > needed by using [0..63] notation): > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 || > 0x00 || 0x40) [0..63]
This makes perfect sense, thanks for pulling up the 'why' for me. > This means that two iterations of TLSv1.2 P_hash(secret, seed) are needed > with. > o secret=EMSK; and > o seed = "teapbind...@ietf.org", 0x00 || 0x00 || 0x40 > > One iteration would give enough data, but RFC 5295 requires to pull 64 > octets. I haven't implemented TEAP yet, but the above is how I'd do to get > IMSK. For fools like me who don't think to follow "as defined in RFC5295" (thinking he has to read the whole darn thing, pffft), lets update the reference to include the section reference too: "...`then the IMSK SHOULD be derived from the EMSK as defined in RFC5295, section 3.1."` `Cheers`
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
