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

[Geoffrey Keating <[e-mail]>]

Martin Rex <[e-mail]> writes:

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

I think you're talking here about the signature_algorithms extension,
which is sent by the client to the server, not the CertificateRequest
you quoted immediately above, which is sent by the server to the
client.

The CertificateRequest in TLSv1.1 does not include a
supported_signature_algorithms field, so if you're using 1.1 or
earlier there's just no way for the server to tell the client which
hash algorithm to use if there's a choice.  So, the software change
required (to support a choice) is to implement TLSv1.2, which is
possibly another order of magnitude more complicated than deploying
basic TLS extension support.

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

What do they send for certificate_types for GOST?  IANA does not seem
to have allocated a ClientCertificateType identifier, and the
certificate_types field is present even in TLSv1.0.


All your other points are good, but most are not relevant to the
discussion of client certificates.  A point which you didn't quite
make, but which is close to one of the points that you did make and
which I would have agreed with, is that the CertificateRequest should
use OIDs to specify certificate types and algorithms rather than
values assigned using IANA registries, and I'd support this for TLS
1.4.  However, this is not quite as trivial as it sounds, because you
must still consider how this interacts with OpenPGP certificates.