Re: [Emu] Processing of TEWAP erratum 5127

[Joseph Salowey <[e-mail]>]

>
>> Could it be that this text refers to RFC 5295:
>>
>>  If an inner method supports export of an Extended Master Session Key
>>  (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>>  [*RFC5295*].  The usage label used is "[e-mail]", and the
>>  length is 64 octets.  *Optional data parameter is not used in the*
>> * derivation.*
>>
>>
>> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>>
>> Which perhaps is meant to translate to:
>>
>> IMSK = KDF(EMSK, “[e-mail]”, 64)
>>
>> But again, only when the inner method supports export of the EMSK.  Note
>> the text below, by the way:
>>
>> USRKs MUST be at least 64 octets in length.
>>
>>
>>
>> However we interpret the text, it seems that either the argument count is
>> wrong or the function is wrong.
>>
>> 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, "[e-mail]", 0x00 | 0x00 | 0x40, 32)
>> (or with empty seed "" instead of that 3 octet seed)
>>
>>
>>
> I’m really not sure what adding a known seed gets us at this point.
>>
>>
[Joe] The intent is that the IMSK derivation uses the USRK derivation of
RFC 5295.  The label, null and 2-byte length are defined in that
specification.  (P_<hash> is defined in RFC 5246)

IMSK = P_<hash> (EMSK, "[e-mail]" | 0x00 | 0x00 | 0x40)

P_<hash> is iterated to generate 64 bytes, the output is truncated to 32.
If we add a parameter to the P_<hash>  to define the length, this would be

IMSK = Truncate(P_<hash>(EMSK, "[e-mail]" | 0x00 | 0x00 | 0x40,
64), 32)


>
>> The "and the length is 64 octets" part just above this is a bit
>> confusing with this, though.
>>
>> [Joe]  In particular its not clear If the same construction should be
used for the other derivations. For example, whether to include the output
length into the data fed into the PRF or not or if there is a null between
the label and the seed.  I believe the intent was the following:
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
>>
>>   (this is actually unchanged)
>>
>> IMCK[j] =  P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys", | 0x00 |
IMSK[j] | 0x00 | 0x3C, 60)

> MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64)
>>   (i.e., add the missing empty seed)
>>
>>
MSK = P_<hash>(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 |
0x40, 64)

>
>> EMSK = TLS-PRF(S-IMCK[j],
>>           "Extended Session Key Generating Function", "", 64)
>>   (i.e., add the missing empty seed)
>>
>>
EMSK = P_<hash>(S-IMCK[j], ""Extended Session Key Generating Function" |
0x00 | 0x00 | 0x40, 64)

>
>>
>>
>> On the last two, entropy is thus borrowed from S-IMCK[j].  Correct?  I
>> don’t have the full flow in my head, but are these indepedently generated
>> on both sides, right?  If so, I don’t see any other alternative to what you
>> are suggesting.
>>
>>
>
[Joe]  THis is not the only the derivation could be interpreted.  The null
after the label and the inclusion of the length are part of RFC 8295 and
not the TLS PRF.   To fix this errata I think we should define the TLS-PRF
to be P_<hash> with a length parameter for TLS 1.2  and then use the
definitions above that explicitly define the 3 inputs.   TLS 1.3 defines
the PRF in terms of HKDF extract and expand functions from RFC 5869 so
there would need to be some mapping to 1.3 as well.