Re: [TLS] TLS 1.2 clarification requested

[Yoav Nir <[e-mail]>]

On Oct 1, 2013, at 11:37 PM, Martin Rex <[e-mail]> wrote:

> 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.

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.

>> 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.

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?

> 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.
> 
> 
>> 
>> 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?
> 
> 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
>> be negotiated and used?
> 
> I can not currently think of a situation where the signature algorithm
> 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?

> 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.

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