Subject: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 11:54:34 +0200 (CEST)

I'm wondering which ssl/tls alert would be the most appropriate
for a TLS server to send if the server requested a client cert
and the client presents a certificate with a keyUsage that
does not have digitalSignature asserted.

OpenSSL seems to send "illegal parameter" alert when processing
CertificateVerify.  I might have chosen "bad certificate" alert.

A related issue would be that a TLS server is using a server
certificate with an RSA key and a keyUsage attribute with just
keyEncipherment.  Such a TLS server cert seems to preclude
its use for DHE_RSA and ECDHE_RSA cipher suites.  What would
be the appropriate alert (for the client to send) if the server
had such a certificate and chose a DHE_RSA or ECDHE_RSA cipher
suite anyway?

It is my impression that there exists CA software that creates
RSA certificates with ExtendedKeyUsage id-kp-serverAuth and
keyUsage limited to keyEncipherment by default.

Do we have a rough idea how common such TLS server certs are
(e.g. from SSL Observatory database)?

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Sep 2013 08:39:31 -0700

> CertificateVerify.  I might have chosen "bad certificate" alert.

BadCertificate seems better since it points the client toward the
encountered problem....

Mike

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 19 Sep 2013 08:43:32 -0700

> CertificateVerify.  I might have chosen "bad certificate" alert.

I would also choose an alert related to certificates, such as
bad_certificate, unsupported_certificate, or certificate_unknown.

As far as I can tell, NSS intends to send certificate_unknown under
this condition (and similarly for a server certificate with the wrong
keyUsage), but I don't know if it actually does that.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2886,2895-2897#2885

> its use for DHE_RSA and ECDHE_RSA cipher suites.

Yes. The TLS 1.0 RFC says:

       Key Exchange Algorithm  Certificate Key Type

       RSA                     RSA public key; the certificate must
                               allow the key to be used for encryption.

       ...

       DHE_RSA                 RSA public key which can be used for
                               signing.

RFC 4492 says:

          Key Exchange Algorithm  Server Certificate Type
          ----------------------  -----------------------

          ...

          ECDHE_RSA               Certificate MUST contain an
                                  RSA public key authorized for
                                  use in digital signatures.  It
                                  MUST be signed with RSA.

Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."

Wan-Teh Chang

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Sep 2013 09:10:45 -0700

>           Key Exchange Algorithm  Server Certificate Type

A certificate authority could, in theory, sign a certificate using
any algorithm it chooses.  Since the client is known to have code
for dealing with RSA (it asked for ECDHE_RSA) but not whether it
has code to validate any other type of signature algorithm, it makes
(practical) sense to limit the CA signature to RSA.

Mike

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Sep 2013 12:18:15 -0400

> (practical) sense to limit the CA signature to RSA.

But do we limit the certificate signature in any other context?  if not,
why limit it here?  for example, if the EE certificate is signed by an
intermediate CA using RSA, but that CA's own cert is signed using DSA or
ECDSA, is that OK?

Why haven't we applied these same-algorithm constraints to EE certs used
in DHE_RSA or RSA key exchanges for that matter?

I can see why the spec might recommend the use of RSA signatures on
certs that supply RSA keys (for the implementation-simplifying reasons
you propose), but making it an RFC 2119 MUST is pretty strong stuff, and
weirdly inconsistent with the rest of the specs, as i understand them.

	--dkg

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Sep 2013 10:01:29 -0700

> weirdly inconsistent with the rest of the specs, as i understand them.

Page 47 of RFC 5246 hints at these rules:

    If the client does not send the signature_algorithms extension, the
    server MUST do the following:

    -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
       DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
       sent the value {sha1,rsa}.

    -  If the negotiated key exchange algorithm is one of (DHE_DSS,
       DH_DSS), behave as if the client had sent the value {sha1,dsa}.

    -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
       ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Prior to TLS 1.2 it could be assumed that all clients supported RSA, and
if any supported DSA, they would be asking for DSS cipher suites.  Once
people started wanting to use new algorithms (ECC), it became necessary
to have a way for a client to indicate which algorithms it could process.

Mike

---

From: Rob Stradling <[email-masked]>
Date: Thu, 19 Sep 2013 22:18:55 +0100

>>>> Note: I don't understand why RFC 4492 says "It MUST be signed with
<snip>
> Page 47 of RFC 5246 hints at these rules:
<snip>

RFC 5246 relaxes the "It MUST be signed with RSA" rule, doesn't it?

Appendix A.7 (Changes to RFC 4492) says:
   "As described in Sections 7.4.2 and 7.4.6, the restrictions on the
    signature algorithms used to sign certificates are no longer tied to
    the cipher suite (when used by the server) or the
    ClientCertificateType (when used by the client).  Thus, the
    restrictions on the algorithm used to sign certificates specified in
    Sections 2 and 3 of RFC 4492 are also relaxed."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: [email-masked] (Martin Rex)
Date: Fri, 20 Sep 2013 15:37:54 +0200 (CEST)

>           Key Exchange Algorithm  Server Certificate Type

On my scorecard, this is a clear defect of rfc4492.  But it is a defect
that it inherited from a non-obvious statement in TLSv1.0 (rfc2246):

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

  7.4.2. Server certificate

   Meaning of this message:
       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 which 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.

This unreasonable restriction is *NOT* present in SSLv3:

http://tools.ietf.org/html/rfc6101#section-5.6.2

5.6.2. Server Certificate

   If the server is to be authenticated (which is generally the case),
   the server sends its certificate immediately following the server
   hello message.  The certificate type must be appropriate for the
   selected cipher suite's key exchange algorithm, and is generally an
   X.509.v3 certificate (or a modified X.509 certificate in the case of
   FORTEZZA(tm) [FOR]).  The same message type will be used for the
   client's response to a certificate request message.

So this artificial limitation is a hidden backwards-incompatible change
in TLSv1.0, that should have never existed in the first place--and
I'm not aware of a TLS implementation which "enforces" this stupidity.

What is particularly strange about this defect is that EVERYONE has
been using RSA certificates for SSL&TLS Servers since 1996, and the
TLSv1.0 spec that was published in 1999 has (due to crypto-political
reasons of that area) mandatates a DHE_DSS cipher suite:

  9. Mandatory Cipher Suites

TLSv1.0  http://tools.ietf.org/html/rfc2246#section-9

  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLSv1.1  http://tools.ietf.org/html/rfc4346#section-9

  TLS_RSA_WITH_3DES_EDE_CBC_SHA

This limitation should be seen as a guidance to CAs to promote interop
rather than a self-imposed crippling of TLS implementations.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 20 Sep 2013 15:51:04 +0200 (CEST)

>     Sections 2 and 3 of RFC 4492 are also relaxed."

Not really.  Actually, it makes things worse,

because rather than the "hidden" backwards-incompatible self-imposed
limitiation from TLSv1.0, rfc5246 now contains a very explicit limitation
to those algorithms negotiated by the signature algorithms TLS extension,
and stupidly asks TLS implementations to enforce this for the entire
certificate chain up to the root.  In TLSv1.0 this limitiation, for
anyone who actually noticed it, was clearly limited to the signature
algorithm on the EE cert itself, but not signature algorithms of
any intermediate and cross-CA certificates further up the chain.

-Martin