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

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> 
> The net effect is that in practice you simply ignore the signature
> 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