Hi Mohit, The quoting in your note is not coming across usefully in my MUA, so I'm trimming to (what I think are) just your remarks without other history.
On Fri, Jan 29, 2021 at 07:34:42PM +0000, Mohit Sethi M wrote: > Hi Ben, > > RFC 5705 says: > > If no context is provided, it then computes: > > PRF(SecurityParameters.master_secret, label, > SecurityParameters.client_random + > SecurityParameters.server_random > )[length] > > If context is provided, it computes: > > PRF(SecurityParameters.master_secret, label, > SecurityParameters.client_random + > SecurityParameters.server_random + > context_value_length + context_value > )[length] > > > We use only two arguments and say "No context data is used in the TLS > exporter interface.". We could show the context argument as empty in the > calls to make things clearer. By the way, this is what is done by TEAP also. > RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined > in [RFC5705] to derive the session_key_seed. The label used in the > derivation is "EXPORTER: teap session key seed". The length of the session > key seed material is 40 octets. No context data is used in the export > process." We're using the TLS 1.3 exporter, though, so the RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument form seems most relevant. Note that there is no difference in TLS 1.3 between an absent context and a zero-length context. > The change of moving the type-code from the context to the label was made > based on your review (comments from Martin) and the fact that some libraries > such as wolfssl don't support passing a context (so far). See: > https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996 I'm not going to get super hung-up on label vs context (but it's clearly a bug if WolfSSL doesn't support contexts). I guess Martin even wanted the type code to be in the label part in the first place, so having it in the label is "better"; we just need to actually show that there's an empty context argument. > I think there was a misunderstanding that an authenticated signal of > authentication completed was needed. Only a signal of no more post handshake > messages was needed. I think Alan's summary might also explain the situation > better. I note that Alan seems to also be a bit unclear about exactly what purpose the commitment message serves; I look forward to seeing how the questions he has listed get answered. Thanks, Ben _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
