On Fri, Jul 27, 2018 at 04:20:43PM -0700, Eric Rescorla wrote: > 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. > > 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?
There are basically three types of asymmetric key exchange TLS 1.3 can currently use: - Multiplicative Diffie-Hellman. - Elliptic-Curve Diffie-Hellman with (x,y) point coordinates. - "ECDH functions". And then the term "ECDH function" is seemingly not defined anywhere. But that definition is certainly intended to encompass X25519 and X448, being any function f from pair of octet strings to a octet string plus octet string G, such that: - f is easy to compute. - f(a,f(b,G)) = f(b,f(a,G)) - It is hard to compute any f(a,f(b_i,G)) from f(a,G) and all f(b_i,G), for some index i, except with very small probability. These condtions imply that one can construct Diffie-Hellman type key exchange safe for multiple uses. For both X25519 and X448, one can find such f and G. There are also other such function + base pairs (not necressarily derived from elliptic curves). And then there are key exchanges that are thought to be secure, but can not be expressed in such framework, even with extra transforms. E.g. key exchanges based on Key Encapsulation Mechanisms (which are important for post-quantum, thus PQ would need a fourth type). Looks like the text after it was considerably expanded from when that text was originally introduced. It initially said "For X25519 and X448, see [RFC7748]." (and in -11, it was a reference to the draft that became RFC7748). Now it has considerably expanded text: For X25519 and X448, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementors use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748]. Might make sense to split the section and define the dangling term somewhere? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
