Re: [TLS] TLS 1.2 clarification requested

[[e-mail] (Martin Rex)]

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
> that is negotiated between client and server and the algorithm which signed
> the server certificate?

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.


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

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