Subject: [TLS] Simplifying signature algorithm negotiation

From: David Benjamin <[email-masked]>
Date: Fri, 15 Jan 2016 20:45:34 +0000

Hi folks,

This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
1.2, signature algorithms are spread across the handshake. We have
SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
independent registries. NamedGroup is sent in one list, also used for
(EC)DH, while the other two are sent as a pair of (HashAlgorithm,
SignatureAlgorithm) tuples but live in separate registries.

This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to be
messy to implement. Client certificate keys may be in smartcards via
OS-specific APIs, so a lot of time is spent transiting new preference
shapes across API boundaries in order to discover smartcard bugs. Sometimes
I think people deploy client certs because they hate me and want to cause
me pain… :-)

Anyway, the new CFRG curves also bind signature curve and hash together.
The current draft represents this as eddsa_ed25519 and eddsa_ed448
NamedGroups and eddsa SignatureAlgorithm. But this doesn’t capture that
EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.)

I propose we fold the negotiable parameters under one name. Think of how
we’ve all settled on AEADs being a good named primitive with a common type
signature[1]. Specifically:

1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now on,
NamedGroup is only used for (EC)DH.

2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as
they are. Introduce a new SignatureAlgorithm u16 type and negotiate that
instead. (Or maybe a different name to not collide.) u8 is a little tight
to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty.

3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by
(ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401
becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with
HashAlgorithm from TLS 1.2. Note this does not introduce new
premultiplications on the wire. Just in the spec and registry.

4. Deprecate ecdsa_sha256, etc., in favor of new
ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
introduces new premultiplications, it’s only 9 values with the pruned TLS
1.3 lists. I think this is worth 9 values to keep NamedGroups separate.

5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and
curve pre-specified. (See [2] at the bottom for full list of allocations.)

Thoughts?

David

[1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
hashAlgorithm SHA-256, maskGenAlgorithm
MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14.
And RSA key generation still has size parameter. Hopefully future things
can look more like Ed25519.

[2]
0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note this
is wire-compatible with TLS 1.2.
- 0x0101 - rsa_pkcs1_md5
- 0x0201 - rsa_pkcs1_sha1
- 0x0301 - rsa_pkcs1_sha224
- 0x0401 - rsa_pkcs1_sha256
- 0x0501 - rsa_pkcs1_sha334
- 0x0601 - rsa_pkcs1_sha512
- 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
- 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but
ignored in TLS 1.3.

0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to
avoid colliding with existing signature algorithms, but I don’t think
that’s necessary[3].
- rsapss_sha256
- rsapss_sha384
- rsapss_sha512
- ecdsa_p256_sha256
- ecdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p384_sha256
- ecdsa_p384_sha384
- ecdsa_p384_sha512
- ecdsa_p521_sha256
- ecdsa_p521_sha384
- ecdsa_p521_sha512
- eddsa_ed25519
- eddsa_ed448

0xfe00-0xffff - reserved for private use, compatible with existing
HashAlgorithm reservation.

[3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
RSA}, they should ignore it since hash 7 doesn't exist.

---

From: Brian Smith <[email-masked]>
Date: Fri, 15 Jan 2016 14:08:33 -1000

> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.

Have you considered the possibility of using this mapping?:

TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.

Then:
1. You don't have to define any new values.
2. The extension size would be smaller.
3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
(I don't have any particular affinity for that profile other than it seems
to have made choices that have historically been shown to be above average,
and it might be a good idea to avoid interop failure with other
implementations that might have a special affinity for it.)

> rsapss_{sha256,sha384,sha512}.
>

This seems like a good idea to me.

> a subset of X.509's RSA-PSS.
>

I believe this is already largely taken care of in TLS 1.3 by fixing all
the parameters to be a function of the digest algorithm used for the
message.

- ecdsa_p256_sha384
> - ecdsa_p521_sha384

The subset of your proposed values I listed above do not seem helpful. For
example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
truncated to 256 bits.

> RSA}, they should ignore it since hash 7 doesn't exist.

I think we should expect more pure ECC (no RSA) deployments soon. In that
case, it would be better if new ECC-based values used the value "ECDSA" (3)
instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
as support for RSA.

[1] https://tools.ietf.org/html/rfc6460

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Dave Garrett <[email-masked]>
Date: Fri, 15 Jan 2016 20:07:12 -0500

On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web/tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg18036.html

Dave

---

From: David Benjamin <[email-masked]>
Date: Sat, 16 Jan 2016 01:10:06 +0000

> 2. The extension size would be smaller.

Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
lose them. I just wrote out all 9 without thinking about it much. Apart
from "please don't cause me interop pain", I don't have strong opinions
about how aggressively we prune the list.

My main worry is, for better or worse (I realize this is a point of
contention), some servers apply sigalgs to both CertificateVerify and
certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a
nuisance.

Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
it would prevent them from adopting TLS 1.3 without switching certificates.
Alternatively, if people decide that sigalgs and certificates officially
have nothing to do with each other in TLS 1.3, then things are fine but we
wouldn't have a way to negotiate such algorithms. I was hoping to avoid
that issue for this proposal, but there is some interaction.

(Whether such certificates exist on the web is probably answerable via CT
logs, but I haven't checked.)

If changing the existing meaning is a nuisance, another option is to
continue to allocate new values but only define ecdsa_p256_sha256,
ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
is) for TLS 1.3 and later.

> implementations that might have a special affinity for it.)

What interop faliures are you worried about here?

> example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get

Good point. That makes some of the combinations unlikely.

> instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them

Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with
'ECDSA'. The same footnote applies. :-)

I don't think it makes sense to strategically assign the second byte for
new numbers. Either we believe TLS 1.2 implementations are unlikely to
react to 0x0703 and not worry about it, or we believe they will and we
reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
u16 hack is too silly and don't do it at all.)

David

---

From: David Benjamin <[email-masked]>
Date: Sat, 16 Jan 2016 01:19:40 +0000

> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html

Ah, thanks! I must have missed this discussion. Or perhaps I saw it and
forgot.

ekr, are you still against this sort of thing? I think the new CFRG
signature algorithms tying decisions together is a good argument for why
we'd want this. If we believe this trend is to continue (and I hope it
does. Ed25519 is a nice and simple interface), trying to decompose it all
seems poor.

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Jan 2016 17:23:07 -0800

> does. Ed25519 is a nice and simple interface), trying to decompose it all

I'm not sure. I agree that the CFRG thing seems to be a new development.
I'll
try to confirm my previous opinion or develop a new one over the weekend :)

Ekr

> David
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: David Benjamin <[email-masked]>
Date: Sat, 16 Jan 2016 01:26:04 +0000

> is) for TLS 1.3 and later.

(Hrm. Nevermind, actually. If we go with only those three, I don't think
this option does anything useful. If we go with a superset, we might want
it separate? Would have to think about that to convince myself. Anyway,
whether/how to subset is the more important question. Overlap's mostly an
optimization.)

David

---

From: Brian Smith <[email-masked]>
Date: Fri, 15 Jan 2016 17:13:29 -1000

> logs, but I haven't checked.)

Me neither, and I think that's the key thing that would need to be checked
to see if my suggestion is viable.

> What interop faliures are you worried about here?

The way I proposed things to work for TLS 1.3 is what the Suite B profile
does for TLS 1.2. A Suite B client cannot describe the Suite B profile
policy with the signature_algorithms extension as-is, so in theory if a
Suite B profile client even exists, it would work better if servers assumed
that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't
know if any such "Suite B client" actually exists, though.

> u16 hack is too silly and don't do it at all.)

I would bet there will be some logic like "Is sha-256 mentioned at all in
the signature_algorithms extension" and/or "is ecdsa mentioned at all in
the signature_algorithms" extension that is used by some servers to decide
whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think
it would be worth the effort at least when the effort is minimal.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 16 Jan 2016 09:47:49 +0200

> about how aggressively we prune the list.

Also, only the matching-size 3 of those 9 combinations tend to be
properly (as in, computing correct results most of the time)
implemented. Other 6 can easily be busted, especially the 3 where
hash is larger than curve, as that hits the hash truncation
special case.
 
> definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a

I would think that any case where meanings are different (except for
case where use in TLS 1.3 is restricted) is a nuisance.

Avoiding these differences with restriction of server signatures to
RSA-PSS would imply that if client signals TLS 1.3 with only the only
RSA algorithms being the v1.5 ones, then server can't sign using RSA
if selecting TLS 1.3.

And it would also imply that if TLS 1.2 server gets TLS 1.3 client
hello with the new RSA-PSS algorithms, it can sign using RSA-PSS,
even after having downnegotiated TLS 1.2.

> that issue for this proposal, but there is some interaction.

The ECDSA nasty case can only occur for certificate-to-certificate
linkages, since EE SPKI does not contain hash algorithm, and server is
always able to choose matching one.

Then TLS 1.3 AFAIK does not deprecate Brainpool, so Brainpool ECDSA can
also be seen...

Then RSA might be nastier: do normal RSA certificates work with RSA-
PSS? If not, then the TLS 1.3 servers can't use them.

> is) for TLS 1.3 and later.

If one does not want to change too much, then one would have to sup-
port those for TLS 1.2 as well (not breaking signature verification
if such algorithm is first advertised and then selected with connection
downnegotiated to TLS 1.2).
 
> What interop faliures are you worried about here?

Things like: Trying to use ECDSA-P256-SHA384 and then one end not imp-
lementing it correctly (e.g. missing truncation).

Apparently ECDSA-P256-SHA384 failure rate is much higher than
ECDSA-P256-SHA256 and ECDSA-P384-SHA384.

> u16 hack is too silly and don't do it at all.)

I think it is fairly unlikely that TLS 1.2 endpoints react to things
like 0x0703 or 0x0404. Since even known signature algorithms are un-
usable with unknown hashes, ServerKeyExchange is temporally localized
and CertificateRequest comes too late to be useful for filtering.

-Ilari

---

From: Hanno Böck <[email-masked]>
Date: Sat, 16 Jan 2016 11:01:12 +0100

Hi,

I generally like the idea of simplifying the different algorithm
negotiation things, but:

On Fri, 15 Jan 2016 20:45:34 +0000
David Benjamin <[email-masked]> wrote:

> [2]
> 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
> this is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility
> but ignored in TLS 1.3.

I think a couple of them (esp. everything with dsa and _md5) should get
a diediedie rfc and never be seen again.

> - eddsa_ed448

Do we really need that many?
I think the "complexity zoo" of TLS is one of its current downsides and
I really think we should go with fewer options in the future. Can we
strip that down to - below 5 or something? (personal opinion: Strip
down to 2, but this may be too radical for now.)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 16 Jan 2016 23:02:16 +0200

> down to 2, but this may be too radical for now.)

Well, there already are 3 main signature schemes...

Six of those on the list could be cut down (cutting the list to 8)
for purposes of server signature.

Unfortunately there might be more in certificate-to-certificate
signatures.

Also, I don't think having N signature algorithms is that bad (unless
your TLS stack architecture is garbage, but then you have other problems
anyway). But if that gets coupled to other things, you are in world of
hurt.

Such annoyances include the TLS_ECDHE_RSA_*/TLS_ECDHE_ECDSA_* cipher-
suites, since RSA_PSS presumably uses _RSA_ and others use _ECDSA_.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 16 Jan 2016 17:39:14 -0500 (EST)

----- Original Message -----
> down to 2, but this may be too radical for now.)

In addition options like ecdsa_p384_sha256 ignore the NIST DSS recommendations 
of using equivalent security strength for hash and signature (SP-800-57). Having
fewer options is indeed better.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Mon, 18 Jan 2016 12:42:12 +0100

On Friday 15 January 2016 17:13:29 Brian Smith wrote:
> > (Whether such certificates exist on the web is probably answerable
> > via CT logs, but I haven't checked.)
> 
> Me neither, and I think that's the key thing that would need to be
> checked to see if my suggestion is viable.
> 
> >> (I don't have any particular affinity for that profile other than
> >> it seems to have made choices that have historically been shown to
> >> be above average, and it might be a good idea to avoid interop
> >> failure with other implementations that might have a special
> >> affinity for it.)
> > 
> The way I proposed things to work for TLS 1.3 is what the Suite B
> profile does for TLS 1.2. A Suite B client cannot describe the Suite
> B profile policy with the signature_algorithms extension as-is, so in
> theory if a Suite B profile client even exists, it would work better
> if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384
> implies P-384. I don't know if any such "Suite B client" actually
> exists, though.

OpenSSL since version 1.0.2 has a setting to enforce strict Suite B 
compliance

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Mon, 18 Jan 2016 12:48:23 +0100

On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> Hi folks,
> 
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
> TLS 1.2, signature algorithms are spread across the handshake. We
> have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and
> HashAlgorithm, all in independent registries. NamedGroup is sent in
> one list, also used for (EC)DH, while the other two are sent as a
> pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in
> separate registries.
> 
> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends
> to be messy to implement. Client certificate keys may be in
> smartcards via OS-specific APIs, so a lot of time is spent transiting
> new preference shapes across API boundaries in order to discover
> smartcard bugs. Sometimes I think people deploy client certs because
> they hate me and want to cause me pain… :-)
> 
> Anyway, the new CFRG curves also bind signature curve and hash
> together. The current draft represents this as eddsa_ed25519 and
> eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this
> doesn’t capture that EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA
> + FF3072.)
> 
> I propose we fold the negotiable parameters under one name. Think of
> how we’ve all settled on AEADs being a good named primitive with a
> common type signature[1]. Specifically:
> 
> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From
> now on, NamedGroup is only used for (EC)DH.
> 
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm
> as they are. Introduce a new SignatureAlgorithm u16 type and
> negotiate that instead. (Or maybe a different name to not collide.)
> u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448
> separately, but u16 is plenty.
> 
> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2
> by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples.
> 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently
> with HashAlgorithm from TLS 1.2. Note this does not introduce new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old
> ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3.
> Although this introduces new premultiplications, it’s only 9 values
> with the pruned TLS 1.3 lists. I think this is worth 9 values to keep
> NamedGroups separate.
> 
> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm
> and curve pre-specified. (See [2] at the bottom for full list of
> allocations.)
> 
> Thoughts?
> 
> David
> 
> [1] We’re stuck with RSA-PSS's generality, so that'll need some
> mapping to a subset of X.509's RSA-PSS. We'll just not bother with
> RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm
> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField
> 14. And RSA key generation still has size parameter. Hopefully future
> things can look more like Ed25519.
> 
> [2]
> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3]
> to avoid colliding with existing signature algorithms, but I don’t
> think that’s necessary[3].
> - rsapss_sha256
> - rsapss_sha384
> - rsapss_sha512
> - ecdsa_p256_sha256
> - ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha384
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448

Then what ECDHE share gets signed?
if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no
 - rsapss_dh2048_sha256
 - rsapss_dh3072_sha256
 - rsapss_dh4096_sha384
 - (etc.)
 - rsapss_p256_sha256
 - rsapss_p384_sha384
 - (etc.)

If it does not specify the DH share signed, it doesn't really change 
anything...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Tue, 19 Jan 2016 16:50:18 +0000

> If it does not specify the DH share signed, it doesn't really change

Why would it need to specify what [DH group's] DH share gets signed?
NamedGroup still exists for the key exchange (see step 1). I'm only
proposing pulling signature curves out of NamedGroup.

(Is the DH share even signed directly? It looks like TLS 1.3 signs via
CertificateVerify's handshake context in both directions. Either way, it's
just a byte-string message. We could also backport this sort of thing to
TLS 1.2 and the signature algorithm still doesn't care about the DH share.
That gets encoded into a byte string somehow.)

I'm trying to make the decompositions and premultiplications align with how
the protocol is structured. TLS 1.2 decomposed algorithm, signing curve,
and hash which isn't universal (Ed25519, Ed448, even RSA-PSS's params in
full generality aren't the same shape, the definition of "digitally-signed"
takes only a byte-string message as input), so they should be
premultiplied. Whereas signature algorithm and DH group are cleanly
separated in the protocol and needn't be premultiplied.

David

---

From: Hubert Kario <[email-masked]>
Date: Tue, 19 Jan 2016 19:25:13 +0100

On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> > > 2. Remove HashAlgorithm, SignatureAlgorithm,
> > > SignatureAndHashAlgorithm as they are. Introduce a new
> > > SignatureAlgorithm u16 type and negotiate that instead. (Or maybe
> > > a different name to not collide.) u8 is a little tight to
> > > allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is
> > > plenty.
> > > 
> > > 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS
> > > 1.2 by (ab)using the old (HashAlgorithm, SignatureAlgorithm)
> > > tuples. 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges
> > > consistently with HashAlgorithm from TLS 1.2. Note this does not
> > > introduce new premultiplications on the wire. Just in the spec
> > > and registry.
> > > 
> > > rsapss_{sha256,sha384,sha512}. These come with the signature
> > > algorithm and curve pre-specified. (See [2] at the bottom for
> > > full list of allocations.)
> > > 
> > > Thoughts?
> > > 
> > > David
> > > 
> > > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87,
> > > trailerField 14. And RSA key generation still has size parameter.
> > > Hopefully future things can look more like Ed25519.
> > > 
> > > [2]
> > if the same as the curve, what about FFDHE, what about ECDHE-RSA?
> > why no> 
> >  - rsapss_dh2048_sha256
> >  - rsapss_dh3072_sha256
> >  - rsapss_dh4096_sha384
> >  - (etc.)
> >  - rsapss_p256_sha256
> >  - rsapss_p384_sha384
> >  - (etc.)
> > 
> CertificateVerify's handshake context in both directions. Either way,
> it's just a byte-string message. We could also backport this sort of
> thing to TLS 1.2 and the signature algorithm still doesn't care about
> the DH share. That gets encoded into a byte string somehow.)
> 
> I'm trying to make the decompositions and premultiplications align
> with how the protocol is structured. TLS 1.2 decomposed algorithm,
> signing curve, and hash which isn't universal (Ed25519, Ed448, even
> RSA-PSS's params in full generality aren't the same shape, the
> definition of "digitally-signed" takes only a byte-string message as
> input), so they should be premultiplied. Whereas signature algorithm
> and DH group are cleanly separated in the protocol and needn't be
> premultiplied.

Problem I am pointing out is that NamedGroup specifies not only what 
curves can be used for signing but also what curves can get signed.

Or are you saying that the NamedGroup would stay, and would now specify 
only the supported parameters for the key exchange, not how they are 
authenticated (as it is now)?

Or to put it other way: what extensions and with what values should I 
sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either 
P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Tue, 19 Jan 2016 18:55:49 +0000

> authenticated (as it is now)?

Yes.

> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
on, NamedGroup is only used for (EC)DH.

> P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?

supported_groups {p256, p384}
supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384,
rsa_pkcs1_sha512}
(Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)

For your example, nothing on the wire changes at all. Before, you'd end up
sending:
supported_groups {p256, p384}
supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512, rsa}}
And rsa_pkcs1_sha256 should be allocated to align with {sha256, rsa}, etc.

The interesting case is Ed25519 and Ed448. You'd currently have to send:
supported_groups {..., eddsa_ed25519, eddsa_ed448}
supported_signature_algorithms {..., {sha512, eddsa}, {shake256[1], eddsa}}

However, this does not capture that {shake256, eddsa} + eddsa_ed25519 isn't
legal. Instead I want:
supported_groups {..., irrelevant to ed25519 and friends}
supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448}

David

[1] I have not been following the CFRG curve work very closely. Adam tells
me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion,
let's assume that's how it ends up.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 19 Jan 2016 21:28:15 +0200

> > authenticated (as it is now)?

Also, IIRC some have expressed that sometimes softare can sanely do
ECDHE over some curve but not signature verification. Or it can sanely
do signature verification but not ECDSA.
 
> (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)

Of course, one wants at least semi-sane behaviour when downnegotiating...

> let's assume that's how it ends up.

Actually, it isn't raw SHAKE256 but some weird prefixed variant...
Fortunately only matters for TLS 1.2 client signatures, due to every-
thing else being highly temporally localized.

I do have should-be-final reference implementation and test vectors
(and another implementation that is just slow and has the test
vectors pass). Currently waiting on co-editor.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 19 Jan 2016 22:08:45 +0000

> to see if my suggestion is viable.

Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more
often than not.
https://crt.sh/?CN=%25&iCAID=1516

But it's not actually all that many hostnames (all of which presumably
don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change,
and whether sigalgs are stronger than a hint w.r.t. X.509 is...
controversial. I wasn't able to find anyone else doing it. So +1 from me on
dropping the 3x3 product to just the three you listed.

I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_*
allocations, but I can't think of any weird behaviors, so it seems
reasonable.

(The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a
client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and
yet still speaking TLS 1.2 would have problems. But if we're actually
limiting to those three, that can't happen anyway, and this hypothetical
client seems pretty weird.)

If other people still want to allow ecdsa_p384_sha256 and friends, I'm also
happy with allocating 6 values and throwing out
ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512.

David

---

From: David Benjamin <[email-masked]>
Date: Tue, 19 Jan 2016 22:20:55 +0000

Sorry, sent from the wrong address.

On Tue, Jan 19, 2016 at 5:19 PM David Benjamin <[email-masked]> wrote:

> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck <[email-masked]> wrote:
>
>> Hi,
>>
> Sounds good. I included all the TLS 1.2 values thinking we'd want to
> retroactively express TLS 1.2 (DSA, MD5, and SHA-1 warts and all) this way
> too. But leaving it alone is probably simpler. Reserving the range should
> be sufficient to keep collisions out.
>
> If TLS 1.3 takes this proposal, I expect that I will make BoringSSL
> implement TLS 1.2 this way (with whatever quirks are needed around ECDSA)
> for convenience, but there's no reason this needs to be reflected in the
> spec.
>
>
>> > - rsapss_sha256
>> > - rsapss_sha384
>> > - rsapss_sha512
>> > - ecdsa_p256_sha256
>> > - ecdsa_p256_sha384
>> > - ecdsa_p256_sha512
>> > - ecdsa_p384_sha256
>> > - ecdsa_p384_sha384
>> > - ecdsa_p384_sha512
>> > - ecdsa_p521_sha256
>> > - ecdsa_p521_sha384
>> > - ecdsa_p521_sha512
>> > - eddsa_ed25519
>> > - eddsa_ed448
>>
> Brian Smith proposed elsewhere in the thread to cutting the ECDSA ones
> down to just
> - ecdsa_p256_sha256
> - ecdsa_p384_sha384
> - ecdsa_p521_sha512
> and folding them into the TLS 1.2 compatibility ECDSA values, which I
> think I am in favor of. I'm personally okay losing P-521 too since
> BoringSSL doesn't advertise it, but I imagine others might object, so
> *shrug*.
>
> That brings us down to 8. No strong opinions from me on whether we need
> all three rsapss_* values. I just took what was in the 1.3 draft.
>
>
> David
>

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 20 Jan 2016 12:50:38 +0100

> https://crt.sh/?CN=%25&iCAID=1516

This is my current count of ECDSA based signatures:
 ECDSA_SHA256        | 1970793
 ECDSA_SHA384        |      53

(That's all valid certificate I know about, most of those have
expired.)

Kurt

---

From: David Benjamin <[email-masked]>
Date: Fri, 22 Jan 2016 22:25:54 +0000

I've put together a pull request with some initial text for this proposal
if folks decide to adopt it.
https://github.com/tlswg/tls13-spec/pull/404

(I'm sure there's no end of editorial problems. I think this is the first
time I've done non-trival spec work.)

David

On Fri, Jan 15, 2016 at 3:45 PM David Benjamin <[email-masked]>
wrote:

> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to
> be messy to implement. Client certificate keys may be in smartcards via

---

From: David Benjamin <[email-masked]>
Date: Mon, 25 Jan 2016 17:35:33 +0000

Sorry, I'd meant to add this note to the message below and forgot:

In putting together the PR, I noticed that eddsa is currently in the draft
as always paired with no hash rather than the one it uses internally. So
the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur.
My bad, I should have looked at that more carefully.

I still think this change is worthwhile. If we expect that future signature
algorithms look like ed25519, this scheme only gives us 256 values to
allocate from and wastes one of the bytes, and it also simplifies and
unifies the interface for signature algorithms. The other benefits from
incorporating curve preferences into the negotiation also still apply.

David

On Fri, Jan 22, 2016 at 5:25 PM David Benjamin <[email-masked]>
wrote:

>> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping
>> to a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
>> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as
>> {hash(7), RSA}, they should ignore it since hash 7 doesn't exist.
>>
>