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

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 1 Dec 2014 00:56:38 -0800

On Sun, November 30, 2014 11:17 pm, Martin Thomson wrote:
>  On 30 November 2014 at 13:52, Stephen Checkoway <[email-masked]> 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)

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 1 Dec 2014 11:33:16 +0200

> insufficient (although SignatureAndAlgorithms generally is... except where

Plus, it is easier to implement just ECDH than ECDSA over given curve,
so implementations that can do ECDH over curve X but not ECDSA over
curve X (but can do ECDSA over some other curve) should not be surprising.

This might especially be so for CFRG curves.

Vice versa might also happen (can do ECDSA over X, but not ECDH over
X).

Also, the algorithm lists can't specify restrictions like that ECDSA
P-256 only works with SHA-256 and P-384 only works with SHA-384 (because
code to do P-256 with SHA-384 is buggy).

-Ilari

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 1 Dec 2014 09:28:12 -0500

On Dec 1, 2014, at 2:17 AM, Martin Thomson <[email-masked]> 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?
> 

And clients can indicate that they support multiple options. I think there's something that I'm missing. A client can indicate that it supports {sha1, sha224, sha256, sha384, sha512} x {rsa, dsa, ecdsa} (I assume no one wants to support md5 any longer).

The quoted text that Peter objected to required all certs in the chain to be signed with one of the specified algorithms. It doesn't require the entire cert chain to be signed by the same algorithm.

If the issue is that the extension takes an extra 36 bytes to specify all combinations and people don't want to waste the bytes on the wire, then that seems like a reasonable concern to me. But that's not what I took Peter's point to be.

> and signature algorithms, but one is always easier in every regard.

Sure, but I don't see how that changes the analysis any. If a client supports n algorithm pairs, it can specify those n pairs. I don't see how this makes it a "nonsensical requirements in TLS 1.2 that you pretty much have to ignore in order to get an implementation that works." But again, I'm probably missing something here.

-- 
Stephen Checkoway