On Sat, Jul 28, 2018 at 12:48 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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? > Thanks. This helps. The text here isn't totally generic, as it refers to scalar multiplication and u-coordinate point input. So, if we had some other ECDH-type thing that didn't have these concepts, then we would have yet new text. In the interest of the minimal change, I suggest: "For X25519 and X448, the calculations are as follows" .... "For these curves, implementations SHOULD use..." How does that sound? -Ekr > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
