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

From: [email-masked]
Date: Mon, 23 Jan 2012 18:47:10 -0500

"Peter Gutmann"<[email-masked]> wrote:
> >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 ?
> 
> 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.

Thank you all for the answers, but this makes me wonder about the similar requirement from TLS 1.0 and 1.1 where it mandates that the server key algorithm must be the same as the algorithm used to sign the certificate. That seems to have the same sort of issues, right? Does that mean it's also generally ignored ?

Thanks,

Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 01:39:21 +0100 (MET)

[email-masked] wrote:
> 
> Thank you all for the answers, but this makes me wonder about the
> similar requirement from TLS 1.0 and 1.1 where it mandates that the
> server key algorithm must be the same as the algorithm used to sign
> the certificate. That seems to have the same sort of issues, right?
> Does that mean it's also generally ignored ?

I suppose you're now refering to statenent (2>) in the paragraph at
bottom of pg.49:

   http://tools.ietf.org/html/rfc5246#page-49

1>  If the client provided a "signature_algorithms" extension, then all
1>  certificates provided by the server MUST be signed by a
1>  hash/signature algorithm pair that appears in that extension.  Note
    that this implies that a certificate containing a key for one
    signature algorithm MAY be signed using a different signature
2>  algorithm (for instance, an RSA key signed with a DSA key).  This is
2>  a departure from TLS 1.1, which required that the algorithms be the
2>  same.

The previous discussion (1>) was about the bogosity of the signature
algorithms extension restricting signatures of certificates (and applies
to TLSv1.2 only)

The statement (2>) makes an bogus++ claim about prior TLS protocol versions,
because such a restriction NEVER existed in any previous protocol specs
(SSLv3,TLSv1.0,TLSv1.1), and none of the implementations that I've checked
contain any such restriction (they all worked fine with an RSA server cert
signed by a DSA root key).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jan 2012 16:50:14 -0800

On Mon, Jan 23, 2012 at 4:39 PM, Martin Rex <[email-masked]> wrote:
> (SSLv3,TLSv1.0,TLSv1.1),

http://tools.ietf.org/html/rfc4346#section-7.4.2

      The certificate type MUST be appropriate for the selected cipher
      suite's key exchange algorithm, and is generally an X.509v3
      certificate.  It MUST contain a key that matches the key exchange
      method, as follows.  Unless otherwise specified, the signing
      algorithm for the certificate MUST be the same as the algorithm
      for the certificate key.  Unless otherwise specified, the public
      key MAY be of any length.

Substantively the same text appears in RFC 2246.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 02:16:04 +0100 (MET)

> Substantively the same text appears in RFC 2246.

Well, OK.  I'm sorry.

Thanks for the pointer to this text, which is actually fenced off into
insignificance with the line "Meaning of this message:" (not quoted above).

But this text seems to be an invalid backwards-incompatible
change to SSLv3:
  http://tools.ietf.org/html/rfc6101#section-5.6.2

So expecting any implementor to notice or even honour such
a backwards-incompatible MUST would per rfc-2119 section 6
require a convincing rationale, otherwise it is in clear
conflict with rfc2119 and essentially null and void.

The wording (algorithm for the certificate ...) at least for me
(non-native english) appears to refer to a certificate _selection_
mechanism for the server -- which an implementor of a server that
supports only a single cert (per handle) is likely to completely
ignore (a selection mechanims is not applicable to a no-selection
situation).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jan 2012 17:22:40 -0800

> insignificance with the line "Meaning of this message:" (not quoted above).

Seeing as SSLv3 had no formal IETF standing, and was just an input
document to TLS 1.0, I'm not sure I agree with your arguments below.
However, since I wasn't the author of this text or the "Meaning of this
message:", and since it has been changed in RFC 5246 I don't really
see a lot of value in debating it.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 05:36:39 +0100 (MET)

Eric,

Eric Rescorla wrote:
> >>                            Unless otherwise specified, the signing
> >>       for the certificate key.

Curiously, rfc2246 does not reference rfc2119... anyhow I'm using
the rfc2119 section-6 guidance when reading specification --
and in particular for specifications that are at maturity level "Proposed",
because Proposed documents *MUST* be assumed to contain defects,
and in particular detrimental imperatives.

http://tools.ietf.org/html/rfc2119#section-6

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

That newly added MUST that was added to TLS-1.0 7.4.2 in a rash
and without rational amounts to "MUST abort" the TLS handshake,
if followed, i.e. total non-interoperability.

Total non-interoperability the extreme opposite of the purpose of
imperatives per 2246 section 6, and the only permissible exemption
would be "potential for causing harm".  So without describing the
harm that continuing the handshake would cause in comparison to
fatally aborting the handshake, this MUST is null and void.

What could have been among the original motiviation (and here it
would have helped extremely if any rationale would have been
provided!!), could have been that it is difficult to infer
the cryptographic algorithms that a client might support for
certificate path validation of the server certificate chain
from the information that the client has provided through
ClientHello.

Recommending conservative assumptions about the clients capabilities
would be OK -- but only for the situation where the server actually
has several different server certificates to choose from.

But even when the server can choose among several different
server certificates with different crypto algorithms,
even the worst of his choices has a non-marginal potential
for resulting in interoperability, while aborting the
handshake per that MUST has exactly ZERO potential for
interoperability.

No matter which way I look at it, that requirement is thoroughly
non-sensical on my scorecard, and is probably the most extreme example,
that I know, of a misplaced imperative with respect to rfc2119 section 6.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jan 2012 08:16:51 -0800

On Tue, Jan 24, 2012 at 8:36 PM, Martin Rex <[email-masked]> wrote:
> Curiously, rfc2246 does not reference rfc2119...

There's nothing curious about it.  2246 and 2119 were written more or
less concurrently and 2246 spent a long time in IESG processing and
the RFC Ed queue.

Honestly, Martin, I have no idea why you're arguing this point:

(1) This text isn't in the current spec.
(2) Neither I or anyone on this thread wrote it.

What's your point?

-Ekr

> anyhow I'm using

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 23:08:51 +0100 (MET)

> (1) This text isn't in the current spec.

The current spec for TLSv1.0 is rfc2246
The current spec for TLSv1.1 is rfc4346
and even the current spec for TLSv1.2 contains the claim that
this restriction applies to TLSv1.0 and TLSv1.1

so it is a defect in _all_3_ current TLS specifications.

from the above three, TLSv1.2 (rfc5246) is factually still the
least relevant spec, as it applies to much less than half of
the implementations, while rfc2246 applies to 98% of the implementations
and rfc4346 applies to maybe 70% of the implementations.

> (2) Neither I or anyone on this thread wrote it.

Agreed.

I will file erratas for all three current specifications.

-Martin