Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> Nikos Mavrogiannopoulos <[e-mail]> wrote:
> > If the server requests a client certificate then it has to store
> > all messages up to (but not including) the CertificateVerify message.
> > That is because he cannot possibly know which signature algorithm
> > hash the client will use.
> 
> Agreed. I can't recall if we discussed this when this feature was being
> designed for 5246 but ISTM that the only way to have this work that
> didn't have this property would be for the client to offer all his
> certificates up-front and the server to select one, since it's
> possible that each cert comes with a specific hash algorithm tied to it.

I am quite confused by a few issues in TLSv1.2 / rfc-5246 about hash
and signature algorithms.

In particular, that TLSv1.2 forces TLS-proprietary digital signatures
from the TLS handshake messages ServerKeyExchange and CertificateVerify
into the same single algorithm negotiation with digital signatures
on certificates appears to create significant new problems.


rfc-5246, 7.4.2  Server Certificate  last paragraph on page 49
   http://tools.ietf.org/html/rfc5246#page-49

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.  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).
?                                                               This is
?  a departure from TLS 1.1, which required that the algorithms be the
?  same.

I searched TLSv1.1 (rfc4346) from top to buttom but did NOT find any
requirements about signature algorithms of certificates in that spec.
I have also not noticed any such restrictions in TLS implementations
I looked at.

So I created a DSA-rootCA, an rsa-2048 server cert, started a TLSv1.0
with this and WindowsXP, Firefox3 an OpenSSL all happily communicate
with it.

So this part of rfc-5246 purports to solve a problem that actually
does not exist in earlier versions of TLS.  The "solution" that
TLSv1.2 alleges to provides looks more like a cumbersome
limitation to me.  While there is zero problem of using certificate
chains with arbitrary mixtures of signature algorithms in TLSv1.1
and prior, this doesn't work anymore when negotiating TLSv1.2,
in particular for signature algorithms which can not be represented
with the code points of TLSv1.2.


TLS implementations that do not want to hang on to carry along all
handshake messages may want the list of hashes permitted for the
"digitally signed" construct in ServerKeyExchange and CertificateVerify
to be as small as possible, while they may want to remain a liberal
as possible about digital signature algorithms on certificates,
similar to all version of TLS up to v1.1.

It's unclear for me what motivated conflating two quite contradictory
objectives into a single protocol element (the SignatureAlgorithm list
in the ClientHelloExtension SignatureAlgorithm applying to both
ServerCertificate and ServerKeyExchange handshake messages,
and the list of SignatureAlgorithms in CertificateRequest applying
to both ClientCertificate and CertificateVerify handshake messages.

As a result of this, any PKIs with less common digital signature
algorithms on path certificates that may have worked perfectly fine
with SSLv3, TLSv1.0 and TLSv1.1, and continue to work with an
implementation of TLSv1.2 that negotiates only v1.0 or v1.1 are
required to fail by the TLSv1.2 spec when TLSv1.2 is negotiated,
because of a lack of code points to represent digital signature AlgIDs
plus the complete lack of knowledge about the AlgIDs supported
in the PKI implementation within the architecturally independent
TLS protocol stack.



A year ago we started shipping support for GOST ciphersuites based on this
proposal:

      http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

in our (at that time OEM) implementation of TLSv1.0, with the
GOST crypto algorithms provided to the TLS stack through a plugin-
interface to a third-party (certifiable) GOST crypto plugin.
 

A very similar capability exists in Windows XPsp2, where the GOST cipher
suites can be used with SChannel and MSIE6 after installation
of an adequate CryptoCSP, although XP's SChannel is an implementation
of TLSv1.0 with _no_ TLS extensions.

I believe there exists more flexibility in TLSv1.0/v1.1 architecture
than rfc5246 asserts.


-Martin