Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

["Ryan Sleevi" <[e-mail]>]

On Sun, November 30, 2014 11:17 pm, Martin Thomson wrote:
>  On 30 November 2014 at 13:52, Stephen Checkoway <[e-mail]> wrote:
> > How is the signature algorithm any different from the cipher suite in
> > this respect? If the client says it can only do ECDSA, what's the point
> > of giving it an RSA cert that it cannot use?
>
>  I think that the difference is that - at least for most clients - they
>  support both.  Or at least, servers have been able to deploy ECDSA
>  certs that chain to RSA with the expectation that RSA hasn't gone away
>  yet.  And that's relatively new.
>
>  Peter refers to the fact that servers (and CAs) have picked a
>  certificate that works based on what they know of clients, and had
>  just the one.  That single cert is offered unconditionally.  If the
>  client doesn't like it, then it can be responsible for choking on it.
>  CAs could have offered a range of certificates with varying strength
>  and signature algorithms, but one is always easier in every regard.
>
>  Migrating away from mostly RSA might have changed that a little.
>

Plus, there are plenty of libraries where the ciphersuite implementation
is semi-independent of the certificate validation.

Perhaps the largest deployment is Chrome, which uses a separate TLS
library (NSS, BoringSSL) than its PKI validation (OS APIs such as
CryptoAPI, Security.framework, or Android Keychain Services). You can
certainly have skew where the TLS client supports a modern suite of
algorithms, but the underlying platform does not. On Windows XP, this is
the SHA-2 family (pre-SP3) and ECDSA (pre-Vista), and on OS X, some
releases had some buggy ECDSA handling.

There are also a number of embedded TLS stacks that provide the
cryptographic framework for TLS, but then defer to external components (or
hardware) for trust validation.

I just mention these as real world cases where ciphersuites alone are
insufficient (although SignatureAndAlgorithms generally is... except where
it isn't)