Subject: [TLS] Harmonizing 4492bis with TLS 1.3

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Dec 2016 13:47:28 +0200

Hi

One issue that came up during WGLC for 4492bis is the way EdDSA signatures are mentioned in SignatureAndHashAlgorithm and in

In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with one byte for hash algorithm and another for signature algorithm.. The HashAlgorithm can be None(0), sha1(2), and a few more going up to sha512(6).  The SignatureAlgorithm can be anon(0), rsa(1), dsa(2), and ecdsa(3). 4492bis adds a new value to SignatureAlgorithm for EdDSA (TBD5).

Additionally, 4492bis requests two new NamedCurve values for ed25519 and ed448.

4492bis requires to use the None(0) HashAlgorithm with EdDSA.  So to declare support for both curves of EdDSA, you’re expected to have (0x00,TBD5) in signature_algorithms and both new curves in elliptic_curves.

TLS 1.3 replaces the signature_algorithms internal structure with a simple list of 16-bit values, but the old values are kept. So RSA with SHA1 is now 0x0201 instead of (0x02,0x01).  However, for EdDSA the draft assigns two values: 0x0807 for Ed25519 and 0x0808 for Ed448. Bringing that back to the TLS 1.2 structure, it would mean that 0x08 is a new hash algorithm (that doesn’t really do anything) and 0x07 and 0x08 are two distinct signature algorithms (rather than the same algorithm, but with different curves).  So four options here:

1. Leave it as its current inconsistent state
2. Change 4492bis: 
     a. no new curves for ed25519 and ed448.
     b. Two new signature algorithms, and request values 7 and 8 for them.
     c. new hash algorithm 0x08 and call it something like “intrinsic” 
3. Change TLS 1.3, by using 0x0007 for both EdDSA signature_algorithms and add two values to supported_groups.
4. A hybrid of 2 & 3: 
     a. No new curves for 4492bis
     b. Two new signature algorithms with values 0x07 and 0x08
     c. TLS 1.3 will modify the values to 0x0007 and 0x0008

There may be more options possible

What do people think?

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Dec 2016 14:14:53 +0200

> There may be more options possible

I would prefer backporting TLS 1.3 methods, i.e. option 2. In fact, that
is what TLS library (btls) I have written does (it recognizes 0807 and
0808 even in TLS 1.2 and attempts to verify the signature).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Dec 2016 12:33:45 +1100

>      c. new hash algorithm 0x08 and call it something like “intrinsic”

This, but with a small tweak: don't treat these values as requiring
special reservation (as we have done for existing hash/signature
values).

Rather than blocking out all 0x08 hashes, which might be the
consequence of this change, we can say that a hash of 0x08 AND either
0x07 or 0x08 identify these signature schemes.  We need to be able to
allocate 0x0809 at some point later.

Maybe also include a reference to TLS 1.3 (informative only) and
mention that this is compatible with the change from SignatureAndHash
to SignatureScheme in TLS 1.3.

Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it
works fine.  It actually fixed some old bugs (such being unable to
sign with P-521 and SHA-256, but trying anyway).

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Dec 2016 07:42:55 +0200

> On 14 Dec 2016, at 3:33, Martin Thomson <[email-masked]> wrote:
> 

Aren’t we going to have separate registries for 1.2 and 1.3?  We don’t want to force anyone to make the changes you had made (as part of 1.3) just to get EdDSA..And I need to request things from IANA based on 1.2 registries.

> to SignatureScheme in TLS 1.3.

Already got a reference to 1.3. Might as well add this.

> sign with P-521 and SHA-256, but trying anyway).

The hashed input to P-521 is treated as a number. Why doesn’t it work if the number is smaller? Note that even SHA-512 is 9 bits “too small”.  It’s the other way around that is challenging. But even that is well-defined.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Dec 2016 16:56:11 +1100

> Aren’t we going to have separate registries for 1.2 and 1.3?  We don’t want to force anyone to make the changes you had made (as part of 1.3) just to get EdDSA..And I need to request things from IA…

Yes, but I was thinking that there might be an expectation about 1.2
values and the way they propagate into the 1.3 registry.  We don't
want that here.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Dec 2016 13:38:45 -0600

> values and the way they propagate into the 1.3 registry.  We don't

The current text in the 1.3 spec "obsoletes" the old HashAlgorithm and
SignatureAlgorithm registries in favor of a new SignatureScheme
registry.  (I don't actually know if "obsoletes" is a magic word for
IANA, though.)

I agree with Ilari and Martin that essentially backporting the 1.3
semantics for use in 1.2 is the best way forward.

-Ben