Subject: [TLS] TLS 1.2 clarification requested

From: "Kain, Michael T" <[email-masked]>
Date: Tue, 1 Oct 2013 13:58:50 -0500

I'm trying to understand the TLS 1.2 restrictions and signature algorithms
and how they interact.  Is there a relation between the signature algorithm
that is negotiated between client and server and the algorithm which signed
the server certificate?

Does that affect the hash algorithm of TLS 1.2 - or is that always SHA256?

For example, if I've got a server configured with a server certificate
signed with SHA256, can it still establish a connection using the
TLS_RSA_WITH_AES_256_CBC_SHA?

Does the signature algorithm for a certificate affect which Ciphersuites can
be negotiated and used?

Mike

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Oct 2013 19:46:17 +0000

On Oct 1, 2013, at 9:58 PM, "Kain, Michael T" <[email-masked]<mailto:[email-masked]>> wrote:

I’m trying to understand the TLS 1.2 restrictions and signature algorithms and how they interact.  Is there a relation between the signature algorithm that is negotiated between client and server and the algorithm which signed the server certificate?

Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectively, and also MUST be signed by ECDSA and RSA respectively. I'm not sure why that last restriction is needed, but it's there. For non-EC ciphersuites, there is no restriction, but you still need to negotiate an algorithm that works with the public key.

Does that affect the hash algorithm of TLS 1.2 – or is that always SHA256?

The hash used in the algorithm (for example: to calculate the Finished message) is ciphersuite-specific, but all current ciphersuites that anybody uses specify SHA-256.

For example, if I’ve got a server configured with a server certificate signed with SHA256, can it still establish a connection using the TLS_RSA_WITH_AES_256_CBC_SHA?

Yes, and then you'll have
 - a certificate signed with RSA-with-SHA256
 - records MAC'd with HMAC-SHA1
 - SHA256 in the Finished calculation

Does the signature algorithm for a certificate affect which Ciphersuites can be negotiated and used?

Only because the ECC RFC says so. It is obviously restricted by the public key. There's also the DH and ECDH key exchanges (non-ephemeral) that have their own restrictions, but I'm not aware of anyone who uses them.

Yoav

---

From: [email-masked] (Martin Rex)
Date: Tue, 1 Oct 2013 22:37:38 +0200 (CEST)

Kain, Michael T wrote:
>
> I'm trying to understand the TLS 1.2 restrictions and signature
> algorithms and how they interact.

BEWARE!

The semantics of the TLS signature algorithms extension as specified
in TLSv1.2 (rfc5246):

   http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

and the specified interaction with the ServerCertificate chain as 
described in the last paragraph in page 49

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

is fubar'ed (as in the ...beyond recognition sense).

I don't know whether implementations of TLSv1.2 actually do/enforce any
of that crap, but Murphy's Law says that the implementation that your
customer/consumer wants to interop with, does so -- and that will
cause of lot of grey hair in the long run.

>
> Is there a relation between the signature algorithm

The description in rfc5246 sections "7.4.1.4.1 Signature Algorithms"
and "7.4.2 Server Certificate" require such a relation, but there is
some non-zero probability that a TLSv1.2 implementor either did not
notice or intentionally ignores this botched part of rfc5246.

> Does that affect the hash algorithm of TLS 1.2 - or is that always SHA256?

Beware !  there are two distinct types of default hash algorithms
in TLSv1.2:

   1.  SHA256  for the PRF plus the handshake message hash that goes
       into the Finished handshake message computation

   2.  either MD5 or SHA1 **alone** for "digitally_signed struct"
       as used in the ServerKeyExchange or CertificateVerify
       handshake messages.

(2) is a huge step backwards in security from all prior versions of
TLS and even from SSLv3.  Essentially, a client that is proposing TLSv1.2
and not including a TLS signature extension, is subjecting itself
to a downgrade attack that is worse than a fallback reconnect to SSLv3.

The "default" digital signature algorithm is the most ridiculous
breakage in TLSv1.2.  Had the TLS WG waited for FIPS 186-3 to complete
then there could have been SHA-256 everywhere in TLSv1.2, resulting
in less complex and faster code, and more secure implementations.

> TLS_RSA_WITH_AES_256_CBC_SHA?

With implementations of SSLv3 through TLSv1.1, this typically just works.

rfc5246 would "officially" require both server and client to fatally
abort the handshake, unless the client allowed the use of a server
certificate with a sha256WithRSAEncryption signature by including a TLS
signature extension to that effect in ClientHello -- which is ridiculous.

> Does the signature algorithm for a certificate affect which Ciphersuites can

I can not currently think of a situation where the signature algorithm
on the server's certificate would matter.

It is the public key in the server's certificate (plus the keyUsage attribute)
that determines which key exchange algorithms can be used, and that limits
the cipher suites from those proposed by the client in ClientHello
from which the server can choose.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Oct 2013 21:37:23 +0000

> cause of lot of grey hair in the long run.

No. Murphy's law says that that implementation is a perfect implementation of a misreading of RFC 5246. Except that perfect implementations don't crash so much.

> to a downgrade attack that is worse than a fallback reconnect to SSLv3.

How so? Section 7.4.8 says :
                                        RSA keys MAY be used with any
      permitted hash algorithm, subject to restrictions in the
      certificate, if any.

So if the client has an RSA certificate, the signature can be done with SHA-256. Yes, the client has to "advertise" this in a ClientHello extension. What of it?

> on the server's certificate would matter.

RFC 4492 said so. I now see that RFC 5246 relaxed that rule, but who reads all the way to appendix A.7, right?

> from which the server can choose.

That is the case for TLS 1.2, but for TLS 1.0 and 1.1, using ECDHE requires that the public key in the cert match the signature algorithm. 

Yoav

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 02 Oct 2013 11:42:59 +0200

> Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectively, and also MUST be signed by ECDSA and RSA r…

As you noted in your other post, RFC 5246 relaxes this restriction. And you don't have to go down until appendix A.7, it
is clearly stated in Section 4.2

 Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).

Appendix A.7 only points out that this changes the rules of RFC 4492.

Johannes

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Oct 2013 10:43:37 +0000

> Appendix A.7 only points out that this changes the rules of RFC 4492.

And that also means that such certificates are OK for TLS 1.2, but not for TLS 1.0 or 1.1.

Yoav