[TLS] Update draft on Curve25519/Curve448 in (D)TLS

[Simon Josefsson <[e-mail]>]

Hi all,

Version -01 of draft-ietf-tls-curve25519 has been posted, please see:

https://tools.ietf.org/html/draft-ietf-tls-curve25519-01

Changes include:

- Added Curve448/Ed448-Goldilocks.

- Dropped the new ECPointFormat value and use "uncompressed" instead.

- Clarified the logic for ECDSA compatibility.

The open issues that I am aware of, and would appreciate
feedback/suggestions on, are:

- Compatibility with signing algorithm selection.  The text now says:

    Since Curve25519 and Curve448 are Diffie-Hellman functions, and not
    applicable as signatures algorithms, clients who offer ECDHE_ECDSA
    ciphersuites and advertise support for Curve25519/Curve448 in the
    elliptic_curves ClientHello extension SHOULD also advertise support
    for at least one curve suitable for ECDSA signatures.  Servers MUST
    NOT select an ECDSA certificate if there are no common curves
    suitable for ECDSA signing.

  This wording should permit use of Ed25519 for signing (assuming it is
  treated as a ECDSA signature) once that is available, and NIST P-256
  for ECDSA certs now.

  The wording is a bit complicated, and might say more than what we
  actually need to enforce at this point.  For example, the last
  sentence ought to be covered by other specification text already, and
  doesn't appear to me to be a new requirement introduced by this
  document.  Maybe we can find the reference and add it instead.  The
  SHOULD is a bit wishy-washy, why isn't it a MUST?

  I am also not confident that this text is aligned with TLS 1.3.

- Naming of Curve448 / Ed448-Goldilocks.

  Is Ed448-Goldilocks the name of the curve, and Curve448 the name of
  the Diffie-Hellman function based on the curve?

  Naming is not terribly clear from the CFRG draft nor the upstream
  Ed448-Goldilocks paper.  The latter does not mention the word Curve448
  at all but does talk about ECHDE.

  Alas, the situation with naming of Curve25519 is not a lot better.

  Perhaps the only thing we can aspire to is to avoid confusion as to
  which curve/function is referred to.  I believe everyone understand
  what is meant by the terms Curve25519, Curve448 and Ed448-Goldilocks
  anyway.  Perhaps getting everyone to agree on terminology naming is
  simply infeasible.

- Is anything more required for TLS 1.3 compatibility/alignment?

- Amount of crypto details (Appendix A).  Ideally I would prefer if the
  CFRG draft contained all the crypto details, but not all of it has
  been carried over to that document.  I don't know what the status is
  on the CFRG document, so I left the majority of the Curve25519 details
  in this document pending clarity.

- Section 2.3 on public key validation.  I would prefer if this went
  into the CFRG document too.

The source code for this draft is maintained in this repository, and
pull requests are welcome: https://gitlab.com/jas/ietf-tls-newcurves

/Simon