Subject: [TLS] New curves work and TLS

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 15 Oct 2015 16:09:39 +0300

As you might know, CFRG has been working on new curves (the document
has been sent to IRSG) and is working on signatures (main issues seem
to be selecting prehash for prehashed version of 448-bit signatures
and KDF for 448-bit signatures).

I have been thinking how to integrate this work into TLS.

Diffie-Hellman:
---------------
There is already a WG draft about this. The one remaining technical
issue seems to be wheither to share the curves with signatures or
dedicate those for DH.

I propose dedicating the codepoints (like draft currently does). The
complexity of implementing signatures is significantly above
complexity of implementing ECDH. This is magnified by the
differences between the signature primitive (one is based on SHA-512,
the other on some still-TBD KDF).

It is not like there is imminent shortage of curve codepoint space,
as we have >64,000 codepoints free.

There's also editorial issue of tracking the renaming of the DHFs
in CFRG-CURVES (Curve25519->X25519 and similarly for Curve448).

Signatures:
-----------
The base algorithm for signatures work is EdDSA. It looks like
Ed25519 is standardized as-is (at least compatible enough for
existing verifiers to be used). Then there is version that first
does SHA-512. For 448-bit versions, the KDF and prehash to be
done first (for version that does prehashing) is TBD.

So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
Ed448ph. And keys MUST NOT be mixed between those.

I propose the following:
- EdDSA uses one SignatureAlgorithm value (5?[1]).
- There will be new curves for EdDSA, one for Ed25519/Ed25519ph and
  another for Ed448/Ed448ph
- If there is ever EdDSA instantiation with Edwards448 curve (the same
  one Ed448 uses) with another KDF, it gets a new curve distinct from
  Ed448/Ed448ph.
- The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or
  value matching the prehash (but the prehash is always done once[2]).
  [TBD: resolve this]
- To be useful, one needs PKIX SPKI representation for the keys. There
  is a draft about that, to be progressed via other channels (Security
  area presumably, as PKIX WG is no more). 

[1] TLS 1.3 introduces one new value for RSA-PSS (which is
IIRC marked as 4 in the spec).

[2] Technically Ed25519 and Ed448 do have prehash function PH, it
just is the identity function.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Thu, 15 Oct 2015 15:17:51 -0400

>   value matching the prehash (but the prehash is always done once[2]).

I've been thinking about the issue of how to handle SignatureAndHashAlgorithm values better. I think this time, I'd like to propose going the opposite way we'd normally want to move: let's consider enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of having independent values. We're moving to signature algorithms that don't have arbitrary hashes, so the current system isn't really ideal anymore.

Current draft:
https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1  (text)
https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88  (full registry)
----------------------------------------
enum {
    none(0),
    md5_RESERVED(1),
    sha1(2),
    sha224_RESERVED(3),
    sha256(4), sha384(5), sha512(6),
    (255)
} HashAlgorithm;

enum {
    anonymous_RESERVED(0),
    rsa(1),
    dsa(2),
    ecdsa(3),
    rsapss(4),
    (255)
} SignatureAlgorithm;

struct {
    HashAlgorithm hash;
    SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
----------------------------------------

Proposed replacement backwards-compatible registry:
----------------------------------------
struct {
    anonymous_RESERVED(0x0000),
    rsa_nohash(0x0001),
    dsa_nohash(0x0002),
    ecdsa_nohash(0x0003),
    rsapss_nohash(0x0004),
    md5_RESERVED (0x0100..0x01FF),
    rsa_sha1(0x0201),
    dsa_sha1(0x0202),
    ecdsa_sha1(0x0203),
    rsapss_sha1(0x0204),
    sha224_RESERVED (0x0300..0x03FF),
    rsa_sha256(0x0401),
    dsa_sha256(0x0402),
    ecdsa_sha256(0x0403),
    rsapss_sha256(0x0404),
    rsa_sha384(0x0501),
    dsa_sha384(0x0502),
    ecdsa_sha384(0x0503),
    rsapss_sha384(0x0504),
    rsa_sha512(0x0601),
    dsa_sha512(0x0602),
    ecdsa_sha512(0x0603),
    rsapss_sha512(0x0604),
    (0xFFFF)
} SignatureAndHashAlgorithm;
----------------------------------------

New values could be assigned specific combinations as needed. This would also let hashes & signatures be deprecated independently easily, e.g. allow rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from the start).

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Oct 2015 12:24:58 -0700

On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett <[email-masked]>
wrote:

> I've been thinking about the issue of how to handle
> SignatureAndHashAlgorithm values better. I think this time, I'd like to
> propose going the opposite way we'd normally want to move: let's consider
> enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of
> having independent values. We're moving to signature algorithms that don't
> have arbitrary hashes, so the current system isn't really ideal anymore.
>
> Current draft:
> New values could be assigned specific combinations as needed. This would
> also let hashes & signatures be deprecated independently easily, e.g. allow
> rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from
> the start).

I am not in favor of this change. Because we can already indicate
combinations, this
doesn't seem to add significant new value. If we need to indicate
"signature algorithm
without a hash" then a "none" hash is the simplest solution.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 17 Oct 2015 15:30:53 +0300

> Diffie-Hellman:

Okay, did a review of draft-ietf-tls-curve25519 (since it still
doesn't seem to have been WGLC'd):

Major issues:
-------------

None

Minor issues:
-------------

- The functions got renamed in cfrg spec (which seems to just
  be concluding IESG review[1]).
- Some references look pretty obsolete (e.g. cfrg-curves from
  January?).
- Maybe add an example key exchanges (just copy test vectors
  out of cfrg-curves and rename things a bit to fit the way
  values are used in TLS)?

[1] In chacha20-poly1305 document processing, IESG review
was followed by sending the spec to the RFC editor.

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Sat, 17 Oct 2015 19:25:46 -0400

> doesn't seem to have been WGLC'd):

Note that draft-ietf-tls-curve25519 is getting merged into draft-ietf-tls-rfc4492bis.

Note that the cfrg-curves draft’s RFC5742-review (aka the end-run review) ended up in “approved no problem” on Thursday:
https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-curves/history/
Basically, now the cfrg draft will just need to work its way through the RFC editor’s publication queue.

spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 18 Oct 2015 15:25:52 +0300

> draft-ietf-tls-rfc4492bis.

Do we also intend to put CFRG signatures work into that?

Might be a good idea to merge the CFRG work already. The DHFs are
stable. The characteristics of the signature scheme are known well-
enough to already put the needed stuff in (if this is to be done),
even if CFRG draft is still under work.

My thoughts on how CFRG sigs are to be put in:
- Reuse the ECDSA ciphersuites.
- New signature algorithm EdDSA.
- The hash algorithm is always 0 (None), even for Ed25519ph/
  Ed448ph.
- Two new curves, Ed25519 and Ed448, distinct from X25519 and
  X448.
- If new hashes for existing curves are ever defined, those
  will get their own NamedCurve value.
- Reference document specifying new algorithm for putting EdDSA
  public keys into PKIX SPKI.
- All keys and signatures are octet strings with no internal
  structure when handled outside the signing and verification
  functions.
- Don't use Ed25519 keys as Ed25519ph keys (and similarly for
  Ed448/Ed448ph). The CFRG spec specifically warns about this.

And how the existing Curve25519 ECDH draft did things:
- Reuse the ECDHE ciphersuites.
- The X25519/X448 native point format is interpretted as
  "uncompressed".
- Two new curves, X25519 and X448 (different names in that
  draft tho).
- All keys are handled as octet strings with no internal structure
  outside the DHF.
- There are no prefix bytes, so all fields containg public keys
  (ECPoint.point) and the ECDH result Z are both always 32 or 56
  octets.

Also, on reading the document, in numerious place it places the
restriction that RSA end-entity certificate MUST be signed with
RSA and ECDSA end-entity certificate MUST be signed with ECDSA.

Why is this? To me, that kind of thing sounds like a leftover
from TLS 1.1 days, when signature negotiation was a lot less
flexible. It also seems like a special case where uniform
handling would work just fine.

Also, I think it explicitly contradicts TLS 1.2 RFC, which
states that TLS 1.1 did have that restriction and then
notes it is lifted (it also updates RFC4492). 

-Ilari