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

[Stephen Checkoway <[e-mail]>]

On Dec 1, 2014, at 2:17 AM, Martin Thomson <[e-mail]> 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.

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.

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

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