Dear TLS WG members. I am doing my final copy-edits for the TLS 1.3 RFC and I noted one technical point and two points I would like to edit for clarity but I wanted more eyes on.
1. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2 If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite indicating a Hash associated with the PSK. This seems like it would be better as a MUST. It's not a disaster if we don't change it, but can anyone think of a reason it should be a SHOULD? 2. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2 The following block comes *after* the description of how to compute ECDH for the NIST curves but before stuff about the CFRG curves. ECDH functions are used as follows: - The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH scalar multiplication function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). - The ECDH shared secret is the result of applying the ECDH scalar multiplication function to the secret key (into scalar input) and the peer's public key (into u-coordinate point input). The output is used raw, with no processing. So it's not clear from the text which it applies to. I'm not the expert here, but it seems like this is at least confusing in the context of NIST curves, so perhaps we need to rescope it in to the CFRG curves. This seems to be Ilari's text. Ilari? 3. The following text: Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document), in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Consecutive applications of HKDF-Expand are allowed as long as these are differentiated via the key and/or the labels. to another application of HKDF-Extract without an HKDF-Expand in In context, this suggests that we're talking about: HKDF-Expand-Label(HKDF-Expand-Label()) but that's confusing because obviously those differ by key. I think we are not trying to talk about this but rather about two HKDF-Expand-Labels on related inputs. to that end, I changed it to: Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels. We could also say that you can HKDF-Expand-Label() repeatedly as above, but we don't actually do this, I believe, so no point in saying it. Objections? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
