Subject: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 23 Mar 2017 14:31:53 +0000

Hi all,

according to  TLS 1.2 section 7.4.1.4.1. a client may use the signature_algorithm extension to signal any combinations the client supports, listed in the order of preferences. If the client does not use this extension, the server must use the signature algorithm in combination with SHA1. This may lead to an error on the client side when validating the certificate. Unfortunately the server is not allowed to use this extension, otherwise he could tell the client his preferences according to his security policy. Is there a standard compliant way to utilize SHA256 based certificates on the server side even when a client does not signal additional signature algorithms?

I looked through the mailing list but did not find an immediate answer to my question, but I guess, it must have been discussed already. Thank you in advance for any hint.

Best regards
Steffen

--
Steffen Fries
Siemens AG
Corporate Technology
CT RDA ITS

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Mar 2017 10:39:05 -0400

> On Mar 23, 2017, at 10:31 AM, Fries, Steffen <[email-masked]> wrote:
>  
> According to  TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.

The signature algorithm is primarily about signatures made as part
of the TLS handshake, and not so much signatures in certificates.

> If the client does not use this extension, the server must use the
> signature algorithm in combination with SHA1.

For signing the TLS key exchange, however, it should still present
whatever certificate chain it has, even if that chain employs SHA256.
It is exceedingly unlikely these days that a client will not support
SHA256 signatures in the certificate chain.

> This may lead to an error on the client side when validating the
> certificate.

You really should not even deploy SHA1 certificates these days, though
some sites are still using their legacy SHA1 certificates that have not
yet expired.

> Unfortunately the server is not allowed to use this extension, otherwise
> he could tell the client his preferences according to his security policy.

The protocol (as it should) lacks the additional round-trips necessary for
the server to initiate signature algorithm negotiation.

> Is there a standard compliant way to utilize SHA256 based certificates on
> the server side even when a client does not signal additional signature
> algorithms?

Yes, just use them regardless of the client's signature algorithm
extension.  See the TLS 1.3 draft for improved language about the
interaction of signature algorithms and certificates.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 08:23:14 -0700

> of the TLS handshake, and not so much signatures in certificates.

This does not seem consistent with
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2

"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."

I appreciate that there are people who feel that this rule is bad, and
to some extent it has been relaxed in 1.3, but I think the text is
pretty clear here.

> SHA256 signatures in the certificate chain.

Yes, that's generally true. Though a TLS 1.2 client which does not offer
SHA-256
in its ClientHello but accepts SHA-256 is broken. So, this should generally
only happen with TLS 1.1 and below.

> the server to initiate signature algorithm negotiation.

I'm not sure quite what the OP Is trying to achieve here. For certificates
offered
by the server, the client just tells you what algorithms it will accept for
no negotiation
is needed. For certificates offered by the client, the server tells the
client
what algorithms it will accept in the CertificateRequest.
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4

-Ekr

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 23 Mar 2017 15:28:17 +0000

Hi Viktor,

thanks for the response, I replied inline.
> signature_algorithm extension to signal any combinations the client 
> supports, listed in the order of preferences.

The signature algorithm is primarily about signatures made as part of the TLS handshake, and not so much signatures in certificates.
[[stf]] In general I agree, but section 7.4.2 directly relates to certificates used by the server:
     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.
Based on that I concluded the same restriction (fallback to SHA1) regarding the absence of the signature_algorithm extension applies for the certificates.  

> signature algorithm in combination with SHA1.

For signing the TLS key exchange, however, it should still present whatever certificate chain it has, even if that chain employs SHA256.
It is exceedingly unlikely these days that a client will not support
SHA256 signatures in the certificate chain.
[[stf]] This is true, specifically, if the client offered SHA256 cipher suites

> This may lead to an error on the client side when validating the 

You really should not even deploy SHA1 certificates these days, though some sites are still using their legacy SHA1 certificates that have not yet expired.
[[stf]] Completely agree. I was curious if there is an option to signal to the client that the server is not willing to support outdated algorithms explicitly, rather than using a SHA256 based cert, which may lead to an error in a legacy client, it it does not support SHA256.

> Unfortunately the server is not allowed to use this extension, 
> otherwise he could tell the client his preferences according to his security policy.

The protocol (as it should) lacks the additional round-trips necessary for the server to initiate signature algorithm negotiation.
[[stf]] Yes, realized that. It gets better in TLS1.3

> Is there a standard compliant way to utilize SHA256 based certificates 
> on the server side even when a client does not signal additional 
> signature algorithms?

Yes, just use them regardless of the client's signature algorithm extension.  See the TLS 1.3 draft for improved language about the interaction of signature algorithms and certificates.
[[stf]] That is the point I stumbled about. The text in 7.4.2 describes what a server must do, when a client uses the signature algorithm extension, but does not describe the supported behavior if the client does not use this extension. It somehow implies that the server shall behave like described for the cipher suite case (section 7.4.1.4.1). From a security perspective I completely agree, one should not use outdated crypto. 

Best regards
Steffen

-- 
	Viktor.

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

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 23 Mar 2017 15:37:02 +0000

Hi Erik,

based on your reply my conclusion is that

-          there is no (standard compliant) way for a server to use a SHA256 based certificate for server side authentication in cases where the client does not provide the signature_algorithm extension

-          clients should always use the signature algorithm extension to ensure the server can apply a certificate with the appropriate crypt algorithms

Best regards
Steffen

On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <[email-masked]<mailto:[email-masked]>> wrote:

> On Mar 23, 2017, at 10:31 AM, Fries, Steffen <[email-masked]<mailto:[email-masked]>> wrote:
>

This does not seem consistent with https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2

"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."

Yes, that's generally true. Though a TLS 1.2 client which does not offer SHA-256
in its ClientHello but accepts SHA-256 is broken. So, this should generally
only happen with TLS 1.1 and below.

I'm not sure quite what the OP Is trying to achieve here. For certificates offered
by the server, the client just tells you what algorithms it will accept for no negotiation
is needed. For certificates offered by the client, the server tells the client
what algorithms it will accept in the CertificateRequest.
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 Mar 2017 17:44:38 +0100 (CET)

Fries, Steffen wrote:
> -  there is no (standard compliant) way for a server to use a SHA256
> based certificate for server side authentication in cases where the
> client does not provide the signature_algorithm extension

The statement quoted by Eric is an obvious and silly defect in the spec,
which the entire installed base of TLSv1.0 and TLSv1.1 completely ignored
--even Microsoft's implementation of TLSv1.0 and TLSv1.1 properly ignores it.

The only defective TLS implementation, that I am aware of, which put this
silly and obviously backwards-incompatible and defective requirement
from rfc5246 into code, seems to be Microsofts TLSv1.2 implementation
in Windows 7 through Windows 8.1.
One can interop with Windows 7 through Windows 8.1 just fine without
signature_algorithms when offering at most TLSv1.1, or offering TLSv1.2
in a SSL version 2 CLIENT-HELLO (in which case Microsoft SChannel will
negotiate TLSv1.1).

> 
> -  clients should always use the signature algorithm extension to ensure
> the server can apply a certificate with the appropriate crypt algorithms

Unless the server is creating his own certificate on the fly, the
signature algorithm on the server certificate is something which the
server has no control over, and which is therefore quite obviously
not up for negotiation in the TLS protocol handshake.

signature_algorithms can only be normative for signatures created as part
of the TLS handshake.  For signature algorithms on certificates, it is
a simple selection hint (similar to TLS extension server_name_indication
only being a selection hint).  That is a thoroughly intuitive requirement
for backwards compatibility.

Btw. there are a number of defects in the TLS spec (and the TLSv1.2 spec
rfc5246 in particular), one is introducing (rsa,md5) as a permissible
signature algorithm into TLSv1.2 handshakes.  While obvious to anyone
with a clue, it took a few implementors several years to understand
that blindly following wording of a "proposed standard" specification
is a terribly bad idea and a poor excuse for lack of common sense 
and lack of interop testing.  For those who missed the defect on
reading, a simple interop test will make this specification defect
stand out like a sore thumb.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Mar 2017 16:51:46 +0000

Hi Steffen,

You’re stepping on a sore point for this WG☺. Based on the strict interpretation of the TLS 1.2 RFC, your conclusions are correct.
If a TLS1.2 client does not send the signature algorithms extension (or the extension does not include SHA256), a compliant TLS 1.2 server with a SHA256 certificate has no choice but terminate the handshake.

Unfortunately, in practice there are TLS 1.2 clients that support SHA256, but don’t advertise it via the signature algorithms extension. Some of their implementers will argue that extensions are, by definition, optional functionality. Or that a TLS client may not have insight into its PKI library’s capabilities. Or that a TLS server is has no say in what certificate to use.

Be that as it may, from the server’s perspective, this strict compliance with the RFC reduces interoperability without a clear security gain. A server that favors interoperability over RFC compliance would send its SHA256 cert anyway, and let the client terminate the handshake. This is a change I made (rather reluctantly) in the latest versions of Windows.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Fries, Steffen
Sent: Thursday, March 23, 2017 8:37 AM
To: TLS WG <[email-masked]>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Hi Erik,

Best regards
Steffen

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 09:57:47 -0700

On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <[email-masked]>
wrote:

> -          there is no (standard compliant) way for a server to use a
> SHA256 based certificate for server side authentication in cases where the
Not quite. If the client offers TLS 1.1 or below, then you simply don't
know if it
will accept SHA-256 and you should send whatever you have. If the client
offers
TLS 1.2 and no signature_algorithm extension, then you technically are
forbidden
from sending it a SHA-256 certificate. Note that any client which in fact
supports
SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
is noncomformant. It's not clear to me how many such clients in fact exist.

-          clients should always use the signature algorithm extension to
> ensure the server can apply a certificate with the appropriate crypt
> algorithms
>
Yes.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 10:04:39 -0700

> --even Microsoft's implementation of TLSv1.0 and TLSv1.1 properly ignores

I don't think this statement is entirely accurate about what the
requirements are.

- TLS 1.0 and 1.1 did not offer any way for the client to tell the server
what algorithms
  it supported. For this reason, if you receive a TLS 1.0 or 1.1
ClientHello, all you
  can do is send whatever certificate you have. So, TLS 1.0 and 1.1
implementations
  are not ignoring any requirement by doing so, rather they are following
the
  specification.

- TLS 1.2 implementations which receive TLS 1.2 ClientHellos which either
  do not have signature_algorithms or which have signature_algorithms
without
  SHA-256 are not supposed to send SHA-256 certificates (per the text I
quoted
  above). Again, I realize opinions differ on the wisdom of this text. The
extent to
  which it is an interop problem depends on how many clients would support
  SHA-256 but for some reason offer 1.2 w/o the required extension. I would
be
  grateful for any data on the frequency of such clients.

- As has been noted elsewhere, TLS 1.3 relaxes the requirement to not send
  certificates which do not match signature_algorithms.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Mar 2017 17:11:04 +0000

Ø  Note that any client which in fact supports

Ø  SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,

Ø  is noncomformant. It's not clear to me how many such clients in fact exist.

We saw enough TLS 1.2 clients that are non-compliant in this way that I made the server-side change to accommodate them.
Obviously, Martin Rex’s code is one example.
I’ve also seen a number of embedded/IoT-oriented TLS stacks that had this defect initially, when they first implemented TLS 1.2, although they were quick to fix.
Some of our customers in East Asia reported that the TLS stacks they used had this defect; when pointed at the RFC, they took the issue to the corresponding SW vendor(s).
Overall, a small percentage, but it generated enough support calls that the server change was worthwhile.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, March 23, 2017 9:58 AM
To: Fries, Steffen <[email-masked]>
Cc: TLS WG <[email-masked]>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Erik,

-          there is no (standard compliant) way for a server to use a SHA256 based certificate for server side authentication in cases where the client does not provide the signature_algorithm extension
Not quite. If the client offers TLS 1.1 or below, then you simply don't know if it
will accept SHA-256 and you should send whatever you have. If the client offers
TLS 1.2 and no signature_algorithm extension, then you technically are forbidden
from sending it a SHA-256 certificate. Note that any client which in fact supports
SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
is noncomformant. It's not clear to me how many such clients in fact exist.

-Ekr

Best regards
Steffen

-Ekr

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

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 Mar 2017 18:24:37 +0100 (CET)

> is noncomformant. It's not clear to me how many such clients in fact exist.

rfc5246 makes it perfectly compliant for a TLSv1.2 client to support
sha256-based signature algorithms and be willing to use them,
and *NOT* send the TLS signature_algorithm extension.

https://tools.ietf.org/html/rfc5246#appendix-E.2

>> ensure the server can apply a certificate with the appropriate crypt

Except that the vast majority of servers only has a single certificate,
and will have to do "the right thing" in most situations anyway.
The definition of the "signature_algorithms" extensions is
sufficiently dense to say that you MUST not send it, except when
ClientHello.client_version=(3,3), and it is not possible to send it
when using a backwards-compatible SSL version 2 CLIENT-HELLO.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 11:24:39 -0700

On Thu, Mar 23, 2017 at 10:11 AM, Andrei Popov <[email-masked]>
wrote:

> We saw enough TLS 1.2 clients that are non-compliant in this way that I
> made the server-side change to accommodate them.
>

Thanks. That's interesting to know.

-Ekr

> I’ve also seen a number of embedded/IoT-oriented TLS stacks that had this
> defect initially, when they first implemented TLS 1.2, although they were
> quick to fix.
>
> Some of our customers in East Asia reported that the TLS stacks they used
> had this defect; when pointed at the RFC, they took the issue to the
> corresponding SW vendor(s).
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, March 23, 2017 9:58 AM
> *To:* Fries, Steffen <[email-masked]>
> *Cc:* TLS WG <[email-masked]>
> *Subject:* Re: [TLS] Enforcing stronger server side signature/hash
> combinations in TLS 1.2
>
>
>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 11:25:42 -0700

> https://tools.ietf.org/html/rfc5246#appendix-E.2

Yes, I agree with this, if you use the v2 ClIENT-HELLO.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 24 Mar 2017 01:00:07 +0000

Fries, Steffen <[email-masked]> writes:

>I looked through the mailing list but did not find an immediate answer to my
>question, but I guess, it must have been discussed already. 

It's been discussed several times, but I'm not sure which search terms you'd
have to apply to find the threads... the general consensus was that even
though the text says it applies to certificates as well, you ignore this
because it serves no obvious purpose but breaks functionality and
interoperability.  See several previous discussions on the rationale behind
this (hmm, if you can find them :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 24 Mar 2017 01:11:52 +0000

Andrei Popov <[email-masked]> writes:

>Unfortunately, in practice there are TLS 1.2 clients that support SHA256, but
>don’t advertise it via the signature algorithms extension.

It's actually pretty safe to just automatically assume SHA256 (for TLS 1.2),
regardless of what the other side advertises.  There was a survey paper
published a while back, I can't remember exactly which one, one of the many
TLS-in-the-wild ones, which showed that of the servers that supported ECC,
close to 100% did P256 + SHA256, some low single-digit figure were P521+512,
and 384 was lost in the margin of error, some fraction of a percent.  Of the
anecdotal evidence from SCADA etc which isn't publicly visible, it's about the
same, you can pretty much assume P256 + SHA256 by default.

Which is precisely why LTS specifies P256 + SHA256 as its MTI if you're doing
ECC.  To paraphrase Calvin's quote about success, "the secret to success is
changing your expectations so that they're already met".  Assume P256+SHA256
(when ECC is indicated), or just SHA256 in general for 1.2, and you won't be
disappointed.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Mar 2017 21:29:55 -0400

> On Mar 23, 2017, at 9:00 PM, Peter Gutmann <[email-masked]> wrote:
> 
> See several previous discussions on the rationale behind

See, for example, the thread that contains:

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

I chose that message because it was easy to find.  This particular
topic has been a bit of a focus of mine on this list, so searching
for my posts with a few of the related keywords pretty quickly
messages on this topic.

Given that TLS is opportunistic in SMTP, I strive to find ways to
achieve as much as security as one can get and not end up with
less by dogmatically insisting on more than is possible.  Hence
RFC7435, and more recently the dose of pragmatism that made it
possible to convince the group to avoid repeating the error in
the TLS 1.3 spec.

The net effect is that in practice you simply ignore the signature
algorithms when it comes to the certificate chain.  I've never seen
a TLS server that has multiple chains to choose from for the same
server identity.  This applies also to TLS 1.2, despite RFC 5246.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Mar 2017 16:08:45 +1100

On 24 March 2017 at 12:29, Viktor Dukhovni <[email-masked]> wrote:
> I've never seen
> server identity.

I didn't have to look far.  www.cloudflare.com will switch hit and
pick RSA or ECDSA on demand:

$ ./tstclnt -h www.cloudflare.com -p 443 -D -b -C
==== certificate(s) sent by server: ====
Certificate:
    Data:
        Serial Number:03:61:3e:ff:c0:fb:82:d6:a4:d8:45:8e:8f:18:04:3a
        Signature Algorithm: X9.62 ECDSA signature with SHA256
        Issuer: "CN=DigiCert ECC Extended Validation Server
CA,OU=www.digicert.com,O=DigiCert Inc,C=US"
        Validity:
            Not Before: Fri Oct 28 00:00:00 2016
            Not After : Fri Nov 02 12:00:00 2018
        Subject: "CN=cloudflare.com,O="Cloudflare, Inc.",L=San
Francisco,ST=CA,C=US,postalCode=94107,STREET=101
Townsend,serialNumber=4710875,incorporationState=Delaware,incorporationCountry=US,businessCategory=Private
Organization"
    Fingerprint (SHA-256):
12:C4:A5:74:7E:D5:6E:37:2C:87:89:02:25:E4:CD:51:89:6D:8E:AD:7D:55:CF:76:BF:D1:9B:6B:74:6C:70:D0

$ ./tstclnt -h www.cloudflare.com -p 443 -D -b -C -c :009c
==== certificate(s) sent by server: ====
Certificate:
    Data:
        Serial Number:01:bf:d1:dc:15:00:6e:0a:bb:a7:c6:70:ff:5e:11:01
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=DigiCert SHA2 Extended Validation Server
CA,OU=www.digicert.com,O=DigiCert Inc,C=US"
        Validity:
            Not Before: Fri Oct 28 00:00:00 2016
            Not After : Fri Nov 02 12:00:00 2018
        Subject: "CN=cloudflare.com,O="Cloudflare, Inc.",L=San
Francisco,ST=CA,C=US,postalCode=94107,STREET=101
Townsend,serialNumber=4710875,incorporationState=Delaware,incorporationCountry=US,businessCategory=Private
Organization"
    Fingerprint (SHA-256):
30:BA:61:01:2F:FE:7C:EA:AF:9A:14:8A:0C:B0:C5:C8:52:A9:C0:4F:4B:1C:27:DB:6E:FA:99:19:C7:F4:9C:CF

I just had to ask nicely.  I'm pretty sure that there are more out
there on the web; I'm sure that mail is a whole different proposition.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Mar 2017 01:23:41 -0400

> On Mar 24, 2017, at 1:08 AM, Martin Thomson <[email-masked]> wrote:
> 
>> I've never seen

Both chains of course use SHA256.

Sorry I meant to say multiple digest algorithms for otherwise
identical chains (same public key algorithm and server name).

Even in the SMTP space some servers have both RSA and ECDSA certs.
When that's the case, cipher negotiation ensures that the selected
EE certificate's public key algorithm is mutually supported.

There's still little need to pay attention to the client's signature
algorithms in choosing the EE-certificate and associated chain.

-- 
-- 
	Viktor.

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 24 Mar 2017 10:00:26 +0000

Peter Gutmann [[email-masked]] writes 
Andrei Popov <[email-masked]> writes:

>Unfortunately, in practice there are TLS 1.2 clients that support 
>SHA256, but don't advertise it via the signature algorithms extension.

It's actually pretty safe to just automatically assume SHA256 (for TLS 1.2), regardless of what the other side advertises.  There was a survey paper published a while back, I can't remember exactly which one, one of the many TLS-in-the-wild ones, which showed that of the servers that supported ECC, close to 100% did P256 + SHA256, some low single-digit figure were P521+512, and 384 was lost in the margin of error, some fraction of a percent.  Of the anecdotal evidence from SCADA etc which isn't publicly visible, it's about the same, you can pretty much assume P256 + SHA256 by default.

[[stf]] well,  assumed the other side sends any cipher suite containing SHA-256, the server can assume that technically the client is able to utilize it in signature operations.

Which is precisely why LTS specifies P256 + SHA256 as its MTI if you're doing ECC.  To paraphrase Calvin's quote about success, "the secret to success is changing your expectations so that they're already met".  Assume P256+SHA256 (when ECC is indicated), or just SHA256 in general for 1.2, and you won't be disappointed.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Mar 2017 12:37:26 +0000

> Sorry I meant to say multiple digest algorithms for otherwise identical chains
> (same public key algorithm and server name).

We used to have to do this, during the MD5-deprecation days.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Mar 2017 06:00:29 -0700

> Both chains of course use SHA256.

I am too lazy to check if it's still true but at least for a while
https://www.mozilla.org/
had both a SHA-1 and a SHA-256 certificate so that we could serve Firefox to
people on very downrev browsers (e.g., XP).

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Mar 2017 16:18:20 +0100 (CET)

Viktor Dukhovni wrote:
> algorithms when it comes to the certificate chain.

Essentially correct.  This is the only reasonable, highly backwards
compatible and perfectly secure choice.

>
> I've never seen a TLS server that has multiple chains to choose from
> for the same server identity.  This applies also to TLS 1.2, despite
> RFC 5246.

Servers with multiple chains for the same server identity have been
around for a while, and their number might be higher than you expect.

More often they choose cert by offered cipher suites (RSA vs. ECDSA),
rather than by signature_algorithms.

I have recently encountered three public CAs that issue such dual-certs,
two of them either thought about potential consequences (or got it right
by chance): VeriSign and DigiCert.

* The RSA and ECDSA dual server certs from VeriSign were issued under the same
(RSA) RootCA cert "VeriSign PCA3 - G5",

* The RSA and ECDSA dual server certs from DigiCert were issued under the same
(RSA) RootCA cert "DigiCert High Assurance EV Root CA"

However, the RSA and ECDSA dual server certs from Comodo were issued
under _distinct_ RootCAs.  I don't know whether Comodo or the purchaser
of the dual server certs goofed this, but unless you negligently dump an
overbroad "blindly trust everyone" into your client-software in a web-browser
fashion (which gives _everyone_ the creeps, see Certificate Transparency
and HPKP bandaids), those Comodo-issued RSA+ECDSA dual server certs
from distinct PKIs are a severe interop nightmare.

If you want to roll out support for ECDSA cipher suites into an installed
base of TLS that is currently limited to RSA, dual certs from distinct
PKIs may result in servers unexpectedly picking and responding with
an untrusted server cert in existing usage scenarios,
after a software update of the TLS client (which adds support for ECDSA
cipher suites).

Two Cloudflare (CDN) examples for dual cert servers:

  Comodo:    https://regmedia.co.uk/

  DigiCert:  https://www.cloudflare.com/

Actually, the latter seems to be a triple-cert server (try -sigalgs RSA+SHA1)

Things could be so much easier if folks would spend a little more
time thinking about backwards compatibility, i.e. what is necessary
so that a new feature can be rolled out into an installed base of
TLS client and servers, without causing interop failures for existing
usage scenarios.

TLSv1.3 has a few problems. Including the pointless hiding of ContentInfo
in the outer TLS record, which is non-interoperable with some of the
installed base and precludes efficient end-of-communication discovery.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Mar 2017 16:40:34 +0100 (CET)

> >> a TLS server that has multiple chains to choose from for the same
  [ https://www.cloudflare.com/  ]
> Both chains of course use SHA256.

Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com
I'm a little confused.

This is the cert chain (as visualized by Microsoft CryptoAPI):

  server-cert:  CN=cloudflare.com, ...
                contains ECDSA P-256 public key
                is allegedly signed with sha256ECDSA

  intermediate CA:  CN=DigiCert ECC Extended Validation Server CA
                contains ECDSA P-384 public key
                is allegedly signed with sha384RSA

  root CA:      CN=DigiCert High Assurance EV Root CA
                contains RSA 2048-bit public key
                is self-signed with sha1WithRsaEncryption

For those who insist on reading rfc5246 verbatim, this chain requires

   ECDSA+SHA384:RSA+SHA384:RSA+SHA1

The digital signature on the server certificate looks bogus to me,
that should be a sha384ECDSA signature according to NIST, because
it uses a P-384 signing key.

The signature on the intermediate CA is imbalanced, and
should be sha256RSA rather than sha384RSA. (that is only an interop issue,
not a security issue).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Mar 2017 16:44:40 +0100 (CET)

oops, typo:

>    ECDSA+SHA384:RSA+SHA384:RSA+SHA1

     ECDSA+SHA256:RSA+SHA384:RSA+SHA1

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 24 Mar 2017 12:31:22 -0400

> algorithms in choosing the EE-certificate and associated chain.

Cloudflare does with the SHA-1 and SHA-256 support (
https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ )

Google has a certificate chain that supports only SHA-256 (if you trust
GeoTrust) or which supports SHA-256 and SHA-1 (if you only trust Equifax,
and require the cross-sign). For example, OpenSSL without the ALT_CHAINS
fix of 1.0.2 would prefer the Equifax path over the GeoTrust path.

There are plenty of large CAs with complex cross-signs that introduce
additional digest algorithms at the intermediate level, and the server can
influence that path validation by using the signature algorithms (although
few do).

I would say that the vast majority of servers deployed on the Internet
using commonly publicly trusted CAs have more than one chain to choose from
- often dependent on the installed trust anchors - but the servers may
simply not be aware of it, and relying on clients to do the needful (for
example, with AIA fetching). The delta of sites that don't work in Firefox
(when SHA-1 is disabled) compared to Chrome (when SHA-1 is disabled)
illustrate this - as Chrome performs the AIA fetching to find the
alternative SHA-256 paths, while Firefox does not, and requires the server
supply them.

Similarly, a given server may have paths where the leaf uses SHA-256, but
intermediates use either SHA-256 or SHA-384 dependent upon the trust anchor
it is rooted in.

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Mar 2017 18:10:45 +0100 (CET)

> alternative SHA-256 paths, while Firefox does not, and requires the server

AIA-fetching is a security disaster waiting to happen,
it's insecure and irresponsible.

While it may be a browser's every day business to aggressively follow
each and every URL received over insecure communication channels
(plaintext HTTP), download the stuff and try hard to execute it
without the slightest amount of risk management (i.e. perform
dangerous stuff millions of time to make demonstrations of
SWEET32 and attacks on RC4-bias possible), such behaviour
is not what the typical programmatic client or server will do
(let alone should do).

Some users might have a hope that clicking a bookmarked https-URL
from a freshly launched web browser would save them from their browser
performing arbitrary requests for attackers.  Well, if a browser performs
AIA-fetching / AIA-chasing, then it is betraying its user, because
the AIA-URL received in the ServerCertificate TLS handshake message
is not authenticated until _after_ successful verification of the
digital signature of that server certificate (at which point AIA-fetching
has become unnecessary).

If Chrome really does AIA-fetching (*shudder*), how can it be disabled?

-Martin

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 24 Mar 2017 14:17:32 -0400

> If Chrome really does AIA-fetching (*shudder*), how can it be disabled?

I can understand and appreciate your viewpoint, although we disagree. I'll
save the rest of the list from rehashing that discussion, since the topic
at hand was the question of whether there can be multiple valid paths with
different hash algorithms. I attempted to demonstrate the various ways this
practically happens and how it can be measured.

Given that this is an intentional design decision and a disagreement on
core security principles, it may be appropriate for you to consider a
browser that aligns with your security perspectives, given that despite the
explanations and shared perspectives, I have been unable to convince you in
the past as to our disagreement.

But I do hope we can agree on the topic at hand - that servers routinely
have multiple certificate chains that combine a variety of digest
algorithms, both with a single leaf certificate (CA variations) or multiple
leaf certificates (e.g. Cloudflare, Facebook)

---

From: Michael StJohns <[email-masked]>
Date: Fri, 24 Mar 2017 15:30:01 -0400

>       ECDSA+SHA256:RSA+SHA384:RSA+SHA1

I don't think RSA + SHA 1 is actually required.   The Signature over the 
trust anchor (root CA) is basically a no-op - assuming the certificate 
is in the browser(client) trust store.  The trust is traced to the 
public key regardless of the form in which it's provided.  We use 
self-signed certs a lot to carry the public keys and names (and 
sometimes constraints), but that's not required by PKIX.

Mike

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Mar 2017 21:53:24 +0100 (CET)

> sometimes constraints), but that's not required by PKIX.

A server TLS implementation is *ALLOWED* to unconditionally include the RootCA
cert, and in that case a client not sending RSA+SHA1 clearly indicates
DO NOT SEND ME THAT PATH if the bogus words in rfc5246 about
signature_algorithms is taken literally.

Remember that were talking about *SERVERS* preempting the clients decision
(like Microsoft SChannel implemented it), not clients ignoring certs
sent by the server for policy reasons.

A server implementation refusing to send such a cert chain to a client
that doesn't include RSA+SHA1 (and blaming DigiCert for it)
is equally justified than Microsoft SChannel choking on absent
signature_algorithm extensions.

The only reasonable interpretation of that part of rfc5246,
is to completely ignore it.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Mar 2017 13:55:02 -0700

On Fri, Mar 24, 2017 at 12:30 PM, Michael StJohns <[email-masked]>
wrote:

> trust anchor (root CA) is basically a no-op - assuming the certificate is
> in the browser(client) trust store.  The trust is traced to the public key
> regardless of the form in which it's provided.  We use self-signed certs a
> lot to carry the public keys and names (and sometimes constraints), but
> that's not required by PKIX.
>

I agree that the text is a bit ambiguous on this point, but I tend to agree
that this is the best
reading.

-Ekr