Subject: [TLS] Signature Algorithms

From: "Mehner, Carl" <[email-masked]>
Date: Sun, 15 Mar 2015 03:40:38 +0000

>I believe we are going to remove this entire field and its associated
>code points because it is redundant with the signature algorithms.
sounds good.

Speaking of Signature Algorithms, what do you think of this?

Since root certificates are trusted by their identity rather than the signature I think that amendments to the text in the Server Certificates and Certificate Request sections are necessary.

As we move into a world that lacks trusted SHA-1 signatures, a change in the text would be necessary in order for clients that drop SHA-1 from the supported hash algorithms to continue to connect to servers that send a certificate_list that includes roots signed with SHA-1.

This has been an issue recently with a browser that did not include the MD2 signature algorithm in this client extension. When it encountered a certificate that sends the root in the certificate_list, the client closes the connection (likely before evaluating if there was an alternate trusted chain). I can see this being an issue in the future with the SHA-1 2048-bit roots.

In the Server Certificates section:
OLD:

If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.

NEW:

If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server, except for the self-signed
   root CA certificate, MUST be signed by a hash/signature algorithm
   pair that appears in that extension.  Note that this implies that
   a certificate containing a key for one signature algorithm MAY be
   signed using a different signature algorithm (for instance, an
   RSA key signed with a DSA key). This is a departure from TLS 1.2,
   which required that all provided certificate signature algorithms
   be included in the client extension regardless of whether or not
   they were evaluated.

Likewise in the Certificate Request section,
OLD:
-  Any certificates provided by the client MUST be signed using a
  hash/signature algorithm pair found in
  supported_signature_algorithms.
NEW: 
-  Any certificates provided by the client, except for the
  self-signed root CA certificate, MUST be signed using a
  hash/signature algorithm pair found in
  supported_signature_algorithms.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 16 Mar 2015 14:40:51 +0100

On Sunday 15 March 2015 03:40:38 Mehner, Carl wrote:
> Since root certificates are trusted by their identity rather than the
> signature I think that amendments to the text in the Server Certificates
> and Certificate Request sections are necessary.
> 
> As we move into a world that lacks trusted SHA-1 signatures, a change in the
> text would be necessary in order for clients that drop SHA-1 from the
> supported hash algorithms to continue to connect to servers that send a
> certificate_list that includes roots signed with SHA-1.

server that provides a self signed certificate is misconfigured in the first 
place...

a change that would reflect better the real world deployments would be to 
change the MUST to SHOULD - significant portion of servers ignore 
signature_algorithms when selecting server certificate (i.e. send sha-1 signed 
certs even when client didn't advertise SHA-1 in sig_algs)

and its the client's duty anyway to decide if it trusts a chain or not, the 
server should just provide one that is most likely to be trusted, not second-
guess client's intentions
-- 
Regards,
Hubert Kario
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: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Mar 2015 14:55:52 +0000

On Mon, Mar 16, 2015 at 02:40:51PM +0100, Hubert Kario wrote:

> Server that provides a self signed certificate is misconfigured in the first 
> place...

That's not correct.  TLS servers are generally not required to send
trust-anchor CA certs, but they may certainly do so.  In fact with
DANE TLSA records with the DANE-TA(2) certificate usage, servers
MUST send the trust-anchor certificate, which may be be self-signed.

With DANE-EE(3) the server's end-entity (leaf) certificate is often
self-signed.  That signature is irrelevant, the signature that
matters is the one on the DNSSEC TLSA RRset that authenticates the
server certificate.  Ditto for the trust anchor in the previous
paragraph.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 17 Mar 2015 13:41:39 -0400

> As we move into a world that lacks trusted SHA-1 signatures, a change in the text would be necessary in order for clients that drop SHA-1 from the supported hash algorithms to continue to connect t…

What's the viability of having TLS 1.3 drop support for SHA-1 for end-entity certificates? (not root or intermediary, yet) This would of course be in addition to dropping all support for MD5, which I think is pretty much a given at this point.

If it were to be new policy right this second, that wouldn't be great, but by the time TLS 1.3 is ready for widespread adoption I think that's a reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at about 2:3 and improving steadily. SHA-2 will probably be used in the majority within a couple months or so.

Dave

---

From: "Mehner, Carl" <[email-masked]>
Date: Tue, 17 Mar 2015 17:51:06 +0000

> From: Dave Garrett [mailto:[email-masked]]
> What's the viability of having TLS 1.3 drop support for SHA-1 for end-
> entity certificates? (not root or intermediary, yet) This would of course
> be in addition to dropping all support for MD5, which I think is pretty
> much a given at this point.
> 
My thoughts were that this would happen on or after the sunset date
(2017-01-01). Dropping SHA-1 for EE-certs is not something I am looking to
have mandated in this document, just allowed for. (By not requiring all the
certificates in the certificate_list to be signed with a supported algorithm
regardless of if the signature was calculated in validation.)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Mar 2015 10:59:58 -0700

On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett <[email-masked]>
wrote:

> > As we move into a world that lacks trusted SHA-1 signatures, a change in
> the text would be necessary in order for clients that drop SHA-1 from the
> What's the viability of having TLS 1.3 drop support for SHA-1 for
> end-entity certificates? (not root or intermediary, yet)

I would not be in favor of this. Many people have certificates with very
long lifetimes
and this would effectively mean that people could not drop in TLS 1.3 for
1.2 on
their servers, which would be bad.

-Ekr

> This would of course be in addition to dropping all support for MD5, which
> I think is pretty much a given at this point.
>
> If it were to be new policy right this second, that wouldn't be great, but
> by the time TLS 1.3 is ready for widespread adoption I think that's a
> reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at
> about 2:3 and improving steadily. SHA-2 will probably be used in the
> majority within a couple months or so.
>
>
> Dave
>

---

From: "Mehner, Carl" <[email-masked]>
Date: Tue, 17 Mar 2015 18:10:25 +0000

I’m not arguing for TLS 1.3 to drop support for SHA-1 (that’s up to the client configurer), I’m arguing for the TLS signature algorithms extension to not specify the signature of a root. This same argument applies for MD5 roots with long term SHA-1 end-entity certs.

If we want to drop MD5 EE-certs by removing MD5 from the signature algorithms, and you want to keep your long term SHA-1 EE-cert that has a chain which is capped by an MD5 root, you would not be able to send that root in the certificate_list as the document is written today. The text I suggested allows you to still send the root.

   pair that appears in that extension.
...

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, March 17, 2015 1:00 PM
To: Dave Garrett
Cc: [email-masked]; Mehner, Carl
Subject: EXTERNAL: Re: [TLS] Signature Algorithms

On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett <[email-masked]<mailto:[email-masked]>> wrote:

> As we move into a world that lacks trusted SHA-1 signatures, a change in the text would be necessary in order for clients that drop SHA-1 from the supported hash algorithms to continue to connect t…

What's the viability of having TLS 1.3 drop support for SHA-1 for end-entity certificates? (not root or intermediary, yet)

I would not be in favor of this. Many people have certificates with very long lifetimes

and this would effectively mean that people could not drop in TLS 1.3 for 1.2 on

-Ekr

   This would of course be in addition to dropping all support for MD5, which I think is pretty much a given at this point.

   Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Mar 2015 18:23:29 +0000

On Tue, Mar 17, 2015 at 06:10:25PM +0000, Mehner, Carl wrote:

> If we want to drop MD5 EE-certs by removing MD5 from the signature
> algorithms, and you want to keep your long term SHA-1 EE-cert that has a
> chain which is capped by an MD5 root, you would not be able to send that
> root in the certificate_list as the document is written today. The text
> I suggested allows you to still send the root.

It may be sensible to recognize that in many cases the server has
a single certificate chain and can only send that regardles of what
the client's signature algorithms extension indicates.

Therefore, though when possible, the server should prefer to send
something that the client is known to support, the server should
be able to send whatever it has, and it is then up to the client
to accept that, or not.

At that point, the client may choose to only validate the signatures
that matter.  In particular self-signatures might not be validated,
and their algorithm might be ignored.  Similarly the signature of
a DANE-TA(2) issuer CA (self-signed or not) would typically be
ignored, because the trust-anchor vouching for that is DNSKEY of
the zone with the TLSA RRset, and not the signer of the CA certificate.

>    certificates provided by the server, except for the self-signed root
>    CA certificate, MUST be signed by a hash/signature algorithm pair that
>    appears in that extension.

Therefore, even this is likely wrong.  The server SHOULD try to
send conformant chains, but is under no obligation to perform magic,
and should not unilaterally abort the connection when it can't.

This is what happens in practice anyway, servers send what they
have, ignoring this requirement.  The real question is what should
clients do.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 17 Mar 2015 14:27:45 -0400

On Tuesday, March 17, 2015 01:59:58 pm Eric Rescorla wrote:
> 1.2 on their servers, which would be bad.

On Tuesday, March 17, 2015 01:51:06 pm Mehner, Carl wrote:
> have mandated in this document, just allowed for.

Ok, then putting strict sunset dates into the specification could be a good route instead.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Mar 2015 18:48:32 +0000

> Ok, then putting strict sunset dates into the specification could

This is a PKIX issue, not a TLS protocol issue.  I don't think this
belongs in the TLS protocol specification.

Perhaps someone wants to write a sunset draft for SHA-1 that
deprecates SHA-1 in PKIX (RFC 5280) for intermediate CA certificates
where collision attacks matter.  At the root the signature is
irrelevant, and the leaf one needs a second-preimage attack, which
I don't recall being on the horizon for SHA-1.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Mar 2015 23:07:07 -0400

On Tue 2015-03-17 14:10:25 -0400, Mehner, Carl wrote:
> I’m not arguing for TLS 1.3 to drop support for SHA-1 (that’s up to
> the client configurer), I’m arguing for the TLS signature algorithms
> extension to not specify the signature of a root. This same argument
> applies for MD5 roots with long term SHA-1 end-entity certs.

The signature algorithm used in the self-signature a root certificate
shouldn't be relevant anywhere.  The root is either already trusted by
the peer (or identified via DANE-TA, in which case the digest
restrictions belong in DANE), or it is not.

TLS peers should never reject root certs on the grounds of the digest
algorithm within the root cert itself.

          --dkg