Subject: Re: [TLS] signature_algorithms extension definition

From: Peter Gutmann <[email-masked]>
Date: Fri, 12 Sep 2014 13:11:30 +0000

Adam Langley <[email-masked]> writes:

>I just didn't realise that the signature_algorithms extension was supposed to
>apply to more than just the TLS handshake.

This issue already came up several years ago, triggered by a comment by Martin
Rex:

>It is *MUCH* worse than that.
>
>TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension
>is sent, that the receiver MUST ensure that all certificates in the chain are
>from the signature_algorithm set.
>
>That is not just shooting yourself in the foot, that is shooting "the whole
>nine yards" (the entire ammunition belt) in your foot.

My response was:

>Just out of interest, how are other implemeters dealing with this?  I looked
>at that requirement in the spec, decided it was totally crazy, and ignored
>it.  So far I haven't found any other TLS 1.2 implementation (of the very few
>that are around) that has any problems with this, so my guess is everyone
>else is ignoring it as well.

Of the implementers who responded to this at the time, all of them took the
very sensible step of ignoring the requirement.  Quoting Martin Rex again:

>[TLS 1.2] adds several undue limitations and interop problems to the protocol
>that did not exist in TLSv1.0 and v1.1, that are technically inappropriate,
>completely unnecessary and in massive conflict with rfc-2119 section 6.
>
>The TLS spec should not mess around with PKI and X.509 issues. Negotiation of
>the algorithm used for the "digitally signed" struct ought to be _completely_
>seperate from characteristics of certificates.

Given that there's no obvious positive contribution provided by this
requirement and serious interop problems added if you adhere to it, ignoring
it, as implementers at the time indicated they were doing, seems like the
sensible approach.

Peter.