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

From: Peter Gutmann <[email-masked]>
Date: Sun, 30 Nov 2014 10:09:56 +0000

Stephen Checkoway <[email-masked]> writes:

>TLS 1.2 specifies
>
>   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.

Which is one of the nonsensical requirements in TLS 1.2 that you pretty much
have to ignore in order to get an implementation that works (it's been
discussed on the list before).  Consider how this is supposed to work in
practice: A client connects to Amazon and asks for ECDSA_P521_WITH_SHA384.
Amazon puts the client on hold and goes to Verisign and requests that they
reissue their entire cert hierarchy up to the root using ECDSA-P521 with
SHA384, and then buys a new certificate using the requested algorithm.  They
then wait for Windows Update to propagate the new CA certs out to the client,
and after a few weeks on hold the client connects.

At the time this was discussed, the approach by everyone who contributed was
that the client got whatever the server had available.  In the rare cases
where the server had more than one cert then "signature_algorithms" could be
used to implement a MAY, but it still won't change the fact that beyond the
server cert you get what the CA gives you and nothing else, no matter what the
TLS 1.2 RFC may wish for.

Peter.

---

From: Stephen Checkoway <[email-masked]>
Date: Sun, 30 Nov 2014 16:52:35 -0500

On Nov 30, 2014, at 5:09 AM, Peter Gutmann <[email-masked]> wrote:

> discussed on the list before).

Sorry, I missed the prior discussion.

> Consider how this is supposed to work in

That seems wrong. In practice, a client connects and says I'm willing to communicate using protocol parameters X, Y, and Z. If the server can't accommodate the client, it closes the connection. 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?

> TLS 1.2 RFC may wish for.

Why does this same reasoning not apply to the symmetric algorithm? E.g., the client wants AES but the server decides 3DES.

-- 
Stephen Checkoway

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Nov 2014 23:17:21 -0800

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.