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

From: Matt DeMoss <[email-masked]>
Date: Fri, 4 Mar 2011 12:17:22 -0500

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.

An alternative design might have been to allow the client to send
multiple chains and let the server choose the end-entity certificate
of the chain it likes, but as it is now it looks to me like the only
options for the server are to "either continue the handshake
(considering the client unauthenticated) or send a fatal alert."

On Mon, Feb 21, 2011 at 3:42 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> On Mon, Feb 21, 2011 at 1:36 AM, Kyle Hamilton <[email-masked]> wrote:
>>> Forcing the TLS implementation to buffer all handshake messages is one
>>> thing that probably a performance problem in TLSv1.2, but it's not a
>>> compatibility issue and as someone said fixing it would require releasing
>>> TLSv1.3. However I don't see ANY sensible reasons why TLS would care about
>>> which signature algorithm is used for signing the actual certificate. As
>>> long as the certificate contains the keys necessary to sign the key exchange
>>> it should be fine just like it was before.
>> Because TLS is the layer where communications policies are negotiated.  The
>> client is informing the server that (e.g.) it doesn't accept MD5 as a valid
>> hash algorithm for realtime communication.  If it doesn't accept it for
>> realtime communication, there is also no reason to accept it for an offline
>> proof -- because an attacker has that much more time to find a preimage.
>
> Actually TLS negotiates things related to the TLS connection. The whole
> communication policy is something TLS shouldn't be concerned with.
> You say that the certificate signature algorithms are important enough
> to be negotiated with TLS, I would add that not only signature algorithms,
> but also the key length of the certificate, and even the issuing date of
> the certificate and the type of the SubjectAlternative name. This is perfectly
> valid under your assumption that TLS should handle this stuff.
>
> Fortunately TLS left all the "communication policy" parts that do not
> concern TLS (i.e. details of certificates), outside its negotiation. The
> signatureAlgorithms was the first extension to negotiate something that
> is not relevant for the TLS protocol.
>
>> Two reasons why this is inappropriate.  First, if the server doesn't have a
>> certificate chain the client will accept, it doesn't need to waste the
>> bandwidth (it doesn't need to broadcast the server's details to someone who
>> won't accept them anyway).
>
> Well, given the way certificates are being used today, that extension cannot
> really do much. A server will not request a new certificate from a CA,
> just because a
> client added the signatureAlgorithms extension in his clientHello and requested
> SHA-224.
>
> regards,
> Nikos
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Mar 2011 12:16:07 -0800

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

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Mar 2011 22:27:44 +0100 (MET)

> 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 is not just shooting yourself in the foot, that is shooting
"the whole nine yards" (the entire ammunition belt) in your foot.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 04 Mar 2011 14:06:24 -0800

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

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 Mar 2011 00:41:31 +0100 (MET)

> 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

---

From: Geoffrey Keating <[email-masked]>
Date: 04 Mar 2011 16:24:19 -0800

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

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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 05 Mar 2011 19:39:31 +1300

Martin Rex <[email-masked]> writes:

>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 is not just shooting yourself in the foot, that is shooting "the whole
>nine yards" (the entire ammunition belt) in your foot.

Just out of interest, how are other implemeters dealing with this?  I looked
at that requirement in the spec, decided it was totally crazy, and ignored it.
So far I haven't found any other TLS 1.2 implementation (of the very few that
are around) that has any problems with this, so my guess is everyone else is
ignoring it as well.

(There are a couple of other things in there that are completely nuts as well,
if we could document the general consensus on what to ignore it might help
other implementors who, God help us, decide to try and follow the spec).

Peter.

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Mar 2011 23:37:14 -0800

> are around) that has any problems with this, so my guess is everyone else is

My TLS code doesn't validate the server's certificate chain.  Instead it
passes all of the information to a callback function registered by the
application; the return code determines whether to continue the handshake
or not.

See, TLS 1.2 isn't so hard to implement after all.  :-)

> other implementors who, God help us, decide to try and follow the spec).

Can you please list the other things you found to be completely nuts?

Thanks,

Mike

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 Mar 2011 08:55:18 +0100 (MET)

> other implementors who, God help us, decide to try and follow the spec).

In case that you saw any of the I-D proposals and discussions around
"document maturity" -- documents at "Proposed Standard" should be assumed
to contain defects and Working Groups are expected to fix them...

So rather than documenting the quirks in TLSv1.2, we should really
fix them.  But honestly, I'd really like to give a TLS extension
for negotiating signature algorithms in a less aggresive fashion
some implementation experience and a few miles on the road of usage
before I would make it a mandatory part of a TLS spec, i.e. it should
come in a fashion that it can be easily adopted by the large installed
base of what is currently out there TLSv1.0 and v1.1.

I think it was a sensible idea to make IPSEC an optional feature
for IPv4 in order to gather experience, rather than holding it off
for everybody until IPv6 is deployed...

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 05 Mar 2011 09:40:13 +0100

> at that requirement in the spec, decided it was totally crazy, and ignored it.

Same for gnutls.

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Mar 2011 13:00:59 +1300

>From an informal survey of known TLS 1.2 implementations (several via off-list
exchanges) it now appears that *none* of them actually follow the bizarre
cert-algorithm requirement in the spec.  I'll follow up with more info on
other parts of the spec that need to be ignored as soon as I've had time to
grep my code for mental-health-related adjectives in comments :-).  (Sorry,
been a bit busy recently with other stuff).

Peter.

---

From: Matt DeMoss <[email-masked]>
Date: Thu, 10 Mar 2011 16:59:23 -0500

> for selecting the most appropriate certificates", i.e. "MAY" not "MUST".

This is interesting to me; as a kind of thought experiment do you
think it would ever be appropriate for TLS to negotiate hash
algorithms on CRLs or on OCSP responses? It seems unlikely that
multiple CRLs will be generated with different hashes and that is only
slightly less true for X.509 certs.

Does it make more sense for TLS to instead negotiate the version of
X.509 (or PKIX profile, or other credential) in use and hope some
future version will provide functionality for a smoother transition? I
read RFC 5280 to say there can only be one signature per certificate,
but it isn't hard to imagine having doubly signed certificates in the
future.

---

From: Geoffrey Keating <[email-masked]>
Date: 10 Mar 2011 14:40:26 -0800

> slightly less true for X.509 certs.

Well, let's look at the environment you'd be doing this in.

This extension is primarily useful if the server has multiple
certificates available and is trying to decide which to send because
there is no algorithm which all clients support.  So, some CA has
issued two certs for this server, one with SHA-1 and one with SHA256.

Presumably these two certs have different serial numbers.  That means
the OCSP responses will be different anyway.

If there are intermediate certificates, they also need to match the
hash algorithm, no point sending a SHA-1 certificate signed by an
intermediate with a SHA256 hash.  In that case, the leaf certificates
have to have different CRLs because the signers will be different.

It also makes no sense to issue two certificates and then point them
both at an OCSP responder or CRL which is signed by only one of the
hashes.  In any situation where you need to issue two certs, that just
won't work.  So you need to have different OCSP responders (or just
one responder that knows to use different hash algorithms for
different certificates) and different CRLs.

So, I don't think TLS needs to negotiate this, it's implicit in the
certificate negotiation.  The server probably won't even notice, it
just knows that 'this OCSP response goes with this certificate'.

BTW, this is a strong argument for negotiating certificate algorithms
separately from the "digitally signed" struct: the server does not
need to be able to verify its own certificates, or stapled OCSP
response, but it does need to implement the algorithm for the signed
TLS structures, so having them be negotiated to be the same causes an
unnecessary interoperability barrier (between the server and its CA).

> but it isn't hard to imagine having doubly signed certificates in the

I can't imagine a problem to which a solution is a new version of
X.509.  The deployment timeline would be so long that any problem
worth fixing would need to be fixed some other way.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Mar 2011 00:11:50 +0100 (MET)

Matt DeMoss wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >

As a black-box TLS extension where apps or the PKI-stack
can exchange hints that the peer could take into account when selecting
adequate certs, crls or ocsp-responses would be fine.

> future version will provide functionality for a smoother transition?

The most simple approach would be through the use of seperate trust
anchors for seperate algorithm sets.  It would work as is with most
of the installed base of TLS software.  But there are a few PKI diehards
(especially those from the "there can be only one Root" PKIs) that are
fiercly fighting against having to add a few trust anchors
and an 10% additional administrative overhead for a three-digit
number of CAs--they rather want the other 6 billions on the planet
to suffer long and hard with any migration.

>
> I read RFC 5280 to say there can only be one signature per certificate,

Unlike PKCS7/CMS and PGP keys, which can handle multiple independent
signatures, X.509 was created with insufficient thought on the
security needs of EndEntities.  With X.509, the EndEntities have
zero effective control about what CAs attribute to their identities.

The DANE/keyassurance working group is trying to provide a solution
that this problem can be mitigated for TLS server certificates in
the future (a solution outside of X.509).

I'm actually more concerned about the reluctance of some vendors
to ease a transition.  Why do I need to manually request a patch
like this:  http://support.microsoft.com/kb/968730
(I'm using WinXP 64-bit, which is Windows 2003 under the sheets)

Vendors with digital signatures on software (and timestamps on those
signatures) should not be using sha1 anymore for any of the signatures in
that process, and therefore have a genuine interest in getting SHA256
into all of their platforms and with the very next automatic
software update...

-Martin

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Mar 2011 18:50:15 -0500

On 3/10/11 4:59 PM, Matt DeMoss wrote:
> On Fri, Mar 4, 2011 at 6:41 PM, Martin Rex<[email-masked]>  wrote:
>
>
>>

Reinventing X.509 PKI ought to be done in PKIX ;)

spt