Subject: [TLS] Consistency for Signature Algorithms?

From: Hubert Kario <[email-masked]>
Date: Fri, 21 Jul 2017 15:23:13 +0200

Signature Algorithms for ECDSA now define both the curve and the hash 
algorithm:

          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
any curve.

There are good reasons for that change:
 - less combinations to test
 - establishes the low water mart for security

I see few problems with that though:
 1). there are not insignificant number of clients that advertise support for 
      all (at least P-256 and P-384) curves, but don't advertise support for 
      hashes stronger than SHA-256 with ECDSA[1] 
 2). This is inconsistent with RSA-PSS behaviour, where key size is completely
      detached from the used hash algorithm.
 3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
      limit the signatures on certificates (in other words, as an implementer
      you need to support all hashes with all curves either way)

With the implementers hat on, I'd prefer to drop the curves from signature 
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes for 
RSA-PSS signatures too, as we did with ECDSA.

Any other ideas?

 1 - Nick Sullivan from Cloudflare provided me with some stats from random 
50000 client hellos from early 2017:

Sigalgs:
ECDSA + SHA-256 = 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)

Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]

Curves:
none = 757 (1.51%)
P-256 = 49243 (98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Jul 2017 08:38:32 -0500

> This is in contrast to the TLS 1.2 protocol, where any hash can be used with 

I assume you saw
https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
raised a different question in this same general area.

I do not see how the response here cannot be the same as it was there:
namely, that the current formulation is assumed to have WG consensus,
having been through two WGLCs; there would need to be rather strong
reasons to make changes at this stage.

-Ben

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

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 21 Jul 2017 14:41:50 +0100

On 21/07/2017 14:23, Hubert Kario wrote:
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> with any curve.
> 
> There are good reasons for that change: - less combinations to test -
> establishes the low water mart for security
> 
> I see few problems with that though: 1). there are not insignificant number
> of clients that advertise support for all (at least P-256 and P-384)
> curves, but don't advertise support for hashes stronger than SHA-256 with
> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> completely detached from the used hash algorithm. 3). This is not how ECDSA
> signatures in X.509 work, so it doesn't actually limit the signatures on
> certificates (in other words, as an implementer you need to support all
> hashes with all curves either way)
> 

There is another and significant problem with the change. In TLS 1.2 support
for a curve was indicated in the supported curves extension and it implied
support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
supported groups extension are for ECDH only. Support for a curve for ECDSA is
indicated in the signature algorithms extension.

I agree though that there is an anomaly here. For example AFAICS in
certificates for TLS1.3 you're allowed (with some caveats) to use a
P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
allowed at all. Is that likely to be a problem in practice? Are there many
such certificates about in the wild?

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

---

From: Hubert Kario <[email-masked]>
Date: Fri, 21 Jul 2017 16:34:57 +0200

> reasons to make changes at this stage.

MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
and no word about any of the other two.

given that we already have CAs that use P-384 for signatures. I'd say this is 
a big conflict between theory and practice.

> >  1). there are not insignificant number of clients that advertise support
> >  for>  
> >  2). This is inconsistent with RSA-PSS behaviour, where key size is
> >  completely>  
> > With my security hat on, I'd say that we should set the minimal key sizes
> > for RSA-PSS signatures too, as we did with ECDSA.
> > 
> > Any other ideas?
> >

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Jul 2017 18:00:55 +0300

> indicated in the signature algorithms extension.

I suppose some new dual-version TLS 1.2/1.3 libraries might have the
same issue as mine: supported groups is just plain ignored for ECDSA,
and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.

> such certificates about in the wild?

Actually, P-256+SHA512 is allowed with a caveat, even if the
certificate is not self-signed. And with the same caveat, server can
send a certificate signed with P-256+SHA3-512, despite TLS
codepoint for it having never existed (not many clients can validate it
through).

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Jul 2017 09:31:00 -0700

> codepoint for it having never existed (not many clients can validate it

But this doesn't affect security if i understand the model correctly.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Jul 2017 14:37:42 -0500

> a big conflict between theory and practice.

I'm afraid I don't understand this remark.  There is the caveat to which
Ilari alludes, that the server can send whatever chain it has, if the
server can't send a chain that complies with the client's
signature_algorithms.  Since certificate validation is assumed to be
largely a function of the PKI library and not really in scope for the
TLS spec itself, this is not particularly problematic.  The other main
usage of the signature_algorithms limits what can be used in
CertificateVerify, which is directly relevant to TLS and depends on the
key attested to in the certificate.  Are you claiming that there are
servers that only possess certificates with p384 keys (i.e., no RSA or
p256 or other fallback cert)?

-Ben

---

From: Dr Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Jul 2017 14:45:56 -0500

> indicated in the signature algorithms extension.

Could you say a bit more about why you believe this to be a problem?  On
the face of it, it seems that the previous state overloaded a single
field to mean multiple only semi-related things, whereas the new
formulation keeps things more orthogonal and easier to implement in a
modular way.  That is, groups are for key exchange, and signature
algorithms are for signing, and there is no muddy overlap between them.

Thanks,

Ben

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 21 Jul 2017 20:58:03 +0100

-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> Could you say a bit more about why you believe this to be a problem?  On the
> face of it, it seems that the previous state overloaded a single field to mean
> multiple only semi-related things, whereas the new formulation keeps things more
> orthogonal and easier to implement in a modular way.  That is, groups are for
> key exchange, and signature algorithms are for signing, and there is no muddy
> overlap between them.
> 

I didn't mean there was a problem with the current spec, I meant there was a
problem with the proposed change: i.e. to remove the curve requirement from
signature algorithms.

Steve.

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 21 Jul 2017 21:21:08 +0100

> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.

That is potentially a problem yes.

Suppose a server has an EE certificate with a P-256 public key and the client
preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3
it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256.

In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the
curve restriction. In this case the server might sign the message using
P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is
in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for
TLS 1.2 might abort the connection at that point.

> codepoint for it having never existed (not many clients can validate it

Yes you're right, the caveat of not otherwise having any suitable chain allows
that case.

Steve.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Jul 2017 12:49:00 +0200

On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > given that we already have CAs that use P-384 for signatures. I'd say this
> > is a big conflict between theory and practice.
> 
> TLS spec itself, this is not particularly problematic.  

true; that disjoint between "stuff that TLS library is supposed to do" and 
"stuff that PKI library is supposed to do" could be spelled out more 
explicitly in the RFC though

> The other main

Yes, there are servers that have P-384 keys. Not sure if they have a dual 
stack (but that is unlikely as only about 30% of servers with ECDSA certs have 
also RSA cert).

> codepoint for it having never existed (not many clients can validate it

the reverse is true too - if your TLS library supports some combinations, the 
PKIX library MUST support them
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Jul 2017 08:09:48 -0500

> explicitly in the RFC though

I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
don't have high hopes that it won't just get closed with no action.

> stack (but that is unlikely as only about 30% of servers with ECDSA certs have 

To clarify, you are arguing that P-384 should also be listed as MTI?

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Jul 2017 16:11:15 +0000

On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:

> signature_algorithms.

"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain.  I sure
hope that server implementation that abort instead of sending some
chain will be rare.

It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:

    1.  Negotiate algorithms suitable for signing TLS handshake
	messages.

    2.  Signal support for X.509 signature algorithms.

Using the same extension for both was perhaps a mistake.  As pointed
out in this thread,  X.509 admits more combinations for "2" than
TLS 1.3 does for "1".  Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Jul 2017 19:15:50 +0200

On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > stack (but that is unlikely as only about 30% of servers with ECDSA certs
> > have also RSA cert).
> 

no, I'm arguing either for dropping the curve from signature algorithms, or to 
bind RSA key sizes to hashes too

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Jul 2017 10:58:12 -0700

> bind RSA key sizes to hashes too

I don't think that either of these are good ideas. It turns out that curves
and
signature algorithms just aren't orthogonal (and even less orthogonal than
hash algorithms) nbut RSA is qualitatively different.

-Ekr

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 24 Jul 2017 18:07:46 +0000

I don't think that either of these are good ideas.

+1

Both of these ideas are pretty bad, especially the first one.

Listing P-384 as MTI would be just fine, IMHO.