Subject: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms?

From: [email-masked]
Date: Wed, 18 Jan 2012 02:54:34 -0500

I'm wondering what is the proper behavior of a TLS1.2 server when none of its certificates satisfy the supported_signature_algorithms extension sent by the client. The spec indicates that the extension should guide the selection of the certificate, and even if there's only one to choose from, the server "... SHOULD attempt to validate that it meets these criteria." But the spec is silent about what should happen if that validation fails. I'm guessing the proper response is a fatal alert, but none seems to fit very well. Maybe handshake_failure, given that if you squint hard enough, this could be interpreted as a failure to "negotiate an acceptable set of security parameters" ?

Searching the archives I ran across this thread http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last year, which concludes with the observation that most implementations simply ignore this bit of the spec altogether. Is it reasonable to take that as a generally accepted consensus to follow at this point ?

Thanks,

Martin

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Jan 2012 18:48:25 +0200

Hi Martin.

First, I think you have confused supported_signature_algorithms, which is
sent by the server with signature_algorithms, which is sent in a
ClientHello extension.

Section 7.4.2 is very clear here:
   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.

But the requirement does seem to fade down to a SHOULD when there's only
one certificate. 

I guess most implementations would send the certificate, and let the
client figure out the proper alert.

Yoav

On 1/18/12 9:54 AM, "[email-masked]" <[email-masked]> wrote:

>I'm wondering what is the proper behavior of a TLS1.2 server when none of
>its certificates satisfy the supported_signature_algorithms extension
>sent by the client. The spec indicates that the extension should guide
>the selection of the certificate, and even if there's only one to choose
>from, the server "... SHOULD attempt to validate that it meets these
>criteria." But the spec is silent about what should happen if that
>validation fails. I'm guessing the proper response is a fatal alert, but
>none seems to fit very well. Maybe handshake_failure, given that if you
>squint hard enough, this could be interpreted as a failure to "negotiate
>an acceptable set of security parameters" ?
>
>Searching the archives I ran across this thread
>http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last
>year, which concludes with the observation that most implementations
>simply ignore this bit of the spec altogether. Is it reasonable to take
>that as a generally accepted consensus to follow at this point ?
>
>Thanks,
>
>Martin
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls
>
>Scanned by Check Point Total Security Gateway.

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Jan 2012 21:48:54 +0100 (MET)

[email-masked] wrote:
> 
> I'm wondering what is the proper behavior of a TLS1.2 server when
> none of its certificates satisfy the supported_signature_algorithms
> extension sent by the client. The spec indicates that the extension
> should guide the selection of the certificate, and even if there's
> only one to choose from, the server "... SHOULD attempt to validate
> that it meets these criteria." But the spec is silent about what
> should happen if that validation fails.
>
> I'm guessing the proper response is a fatal alert, but none seems
> to fit very well. Maybe handshake_failure, given that if you squint
> hard enough, this could be interpreted as a failure to "negotiate

The definition of the signature algorithms extension in TLSv1.2 (rfc5280)
is overly restrictive (read: defective) with respect to signature algorithms
on _certificate_ chains.

> http://www.ietf.org/mail-archive/web/tls/current/msg07608.html
> from last year, which concludes with the observation that most
> implementations simply ignore this bit of the spec altogether.
> Is it reasonable to take that as a generally accepted consensus
> to follow at this point ?

Using the information as a guidance/hint in selecting among alternative
certificates is OK--but trying to enforce it remotely, as one MUST
somewhere in rfc5280 suggest, would be unreasonable.

The original purpose of the TLS handshake, and the protected negotiation,
is to improve the chances for _completing_ the handshake successfully,
with the most desirable common characteristics between the peers,
not for the opposite (=handshake failures).

If the client cares strongly about specific algorithms,(=client policy
decision) then the decision to abort the handshake can not be offloaded
to the peer/server anyway (because that peer can be buggy or an
imposter/attacker)-- it is something that the client will have to enforce
himself when performing certificate path validation on the server
certificate.   Reasonably implemented, the client will then be in a
*much* better position to produce a clear and comprehensible error message,
describe which certificate it rejects and why, compared to a receiving
some unspecific fatal SSL Alert from the server--or worse, being faced
with a sudden closure of the network connection mid-handshake.
(Microsoft IIS seems to not send fatal SSL Alerts on the wire after
 handshake failures and prior to terminating the network connection).

So yes, the proper response will be to ignore the contents of the
signature_algorithm extensions in case that the server does not
have alternatives to choose from of the hints contained in the
signature_algorithm extension do not match any of the certificate
that the server has.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 21 Jan 2012 01:17:19 +1300

<[email-masked]> writes:

>http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last year,
>which concludes with the observation that most implementations simply ignore
>this bit of the spec altogether. Is it reasonable to take that as a generally
>accepted consensus to follow at this point ?

It seems so.  It's not so much "most" as "all known implementations", and
AFAIK the situation hasn't changed since last year.  This has always been a
nonsensical requirement whose sole effect is to hurt interoperability, so the
best approach is to ignore it.

Peter.