[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits
From: Martin Rex <mrex () sap ! com>
Date: 2011-03-23 0:58:56
Message-ID: 201103230058.p2N0wuwJ022566 () fs4113 ! wdf ! sap ! corp
[Download RAW message or body]
Dr Stephen Henson wrote:
>
> Using SHA-2 algorithms isn't possible in TLS 1.1 and earlier with RSA as they
> hard code the SHA1+MD5 signature.
"not possible in TLS 1.1 and earlier" is an inappropriate determination.
The two possibilities to do this in TLSv1.0 and TLSv1.1 are
- a specification of an RSA-based TLS cipher suite, intuitively one
that already uses SHA-256 for the data MAC, to produce the
"digitally signed struct" with SHA-256 instead of MD5+SHA1
- a specification of a TLS extension for the purpose of using
SHA-256 instead of MD5+SHA1 for the "digitally signed struct"
probably along with a replacement of the "default TLS PRF"
which is based on an P_MD5() XOR P_SHA1() in TLSv1.0&v1.1
with a PRF based on P_SHA256() such as in TLSv1.2
-Martin
PS: in case anyone is wondering "why not implement TLSv1.2"?
- the definition of the signature algorithms extension in rfc-5246
is pretty much fouled up that I wouldn't count to obtain a sensible
level of interoperability with it.
- the clients uncertainty about the hash that will be allowed/required
for the "digitally signed struct" of the ClientVerify handshake
message hash
- the protocol version intolerance for TLSv1.2 in the installed
base seems worse than the TLS extension intolerance, i.e.
A TLS record with protocol_version { 0x03, 0x00 } carrying
a ClientHello with client_version { 0x03, 0x03 } is not advisable
for clients that do not have application-level dirty hacks to close
the connection after a failed TLS handshake and restart a new
connection with a less "sophisiticated" ClientHello.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic