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

[Martin Rex <[e-mail]>]

Geoffrey Keating wrote:
> 
> Martin Rex <[e-mail]> writes:
> 
> > Michael D'Errico wrote:
> > > 
> > > Matt DeMoss wrote:
> > > > I'd encourage consideration of client certificates also. If the client
> > > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it
> > > > needs a way to choose which chain to send during periods of transition
> > > > where some servers will reject SHA2 and others will reject SHA3.
> > > 
> > > Isn't this already in TLS 1.2?  When the server requests a client
> > > certificate, the CertificateRequest includes a list of acceptable
> > > signature algorithms.  The client can then check each of its
> > > certificate chains to find the best one the server can handle.
> > 
> > It is *MUCH* worse than that.
> > 
> > TLSv1.2 goes as far as _requiring_ that if the signature_algorithm
> > extension is sent, that the receiver MUST ensure that all certificates
> > in the chain are from the signature_algorithm set.
> 
> That's in the server's chain, though, not the client's.  For the
> client, the possible certificate algorithms and types are listed in the
> CertificateRequest, not in an extension, and the list is not optional.


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

  7.4.4.  Certificate Request

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

   supported_signature_algorithms
      A list of the hash/signature algorithm pairs that the server is
      able to verify, listed in descending order of preference.

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.


Adding support for sha256WithRsaEncryption in X.509 certs to the PKI
module of an existing implementation of SSLv3 or TLSv1.0 in your
installed base is an almost trivial software change.  About a magnitude(!)
less work&testing than implementing rfc-5746 (TLS extension RI).

It is so easy that even Microsoft did it for XP & Win2K3 (unfortunately
they only included it in XPsp3 -- for XPsp2 and XP 64-bit/Win2K3 it
is manual work to download and install hotfix KB968730.)


rfc5246 is a failed specification, because it adds several undue limitations
and interop problems to the protocol that did not exist in TLSv1.0 and v1.1,
that are technically inappropriate, completely unnecessary and in
massive conflict with rfc-2119 section 6.


The TLS spec should not mess around with PKI and X.509 issues.
Negotiation of the algorithm used for the "digitally signed" struct
ought to be _completely_ seperate from characteristics of certificates.

A TLS extension to convey hints about digital signature algorithms
ought to be a fairly black box to TLS, containing a list of
ASN.1 AlgIds, and with the semantic of a "hint to the PKI software
for selecting the most appropriate certificates", i.e. "MAY" not "MUST".


Having the prerequisite for a signature algorithm to be used with
TLSv1.2 that first official code points must be assigned by the IETF 
and then all TLS implementation must be updated to know how to
translate a particular AlgId() into a newly defined TLS SignatureAlgorithm
codepoint before a client certificate with a different crypto algorithm
can be used looks like a pretty deep rathole with lots of huge and
nasty rats at the bottom.


Even Microsoft managed to design their TLSv1.0 protocol stack in
Microsoft Windows XP in a fashion that it can be used with completely
different cryptoalgorithms (like entirely from the GOST suite)
with the installation of a CryptoCSP.


Changing TLS in a fashion that makes this _much_ harder to get working
is the wrong direction for the evolution of the TLS protocol.


Personally, I consider several aspects of TLSv1.2 _unimplementable_
(i.e. it would break functionality we use and have shippped).

But I believe it is possible to fix TLSv1.2, and in a fashion that
remains interoperable with implementations of rfc-5246 (i.e. without
breaking them).


I also think there is a necessity for smoothing the transition to
certificates with sha-2 based signatures for the installed base
of pre-TLSv1.2.   A transition that comes about 1/4 of the cost
of RFC-5746 in terms of implementation and testing effort.
Something that is so affordable that even Microsoft could
ship it for WindowsXP.


-Martin