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

From: Peter Gutmann <[email-masked]>
Date: Tue, 05 Apr 2011 23:48:20 +1200

I wrote:

>Just out of interest, how are other implementers 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.

The informal straw poll (some on-list, most off-list) indicated that no
(known) implementation actually paid any attention to this requirement, for
reasons already pointed out in the original thread.  So I think we definitely
need an update to the TLS 1.2 spec.

>(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 implementers who, God help us, decide to try and follow the spec).

I finally got around to typing up the issues and suggested solutions:

-- Snip --

TLS 1.2 problems

Issue: The already-covered problem with requiring that all certs in the cert
chain match what's in the signature_algorithm extension.

Solution: Remove this requirement from the spec, everyone is ignoring it
anyway, and all it does is hurt interoperability.

Issue: When sending the list of supported signature and hash algorithms, the
name used throughout the text is SignatureAndHashAlgorithm.  This is incorrect,
since what's sent is actually HashAndSignatureAlgorithm.

Solution: Either rename SignatureAndHashAlgorithm to HashAndSignatureAlgorithm
or reverse the order of the parameters being sent to match the name.

Issue: Handling of ECC is a mess.  The IPsec guys found out the hard way with
IKEv1 that for interoperability you need a small, fixed number of suites, not
a 52-page Chinese menu that no two parties can agree on.  TLS seems to have
gone in the opposite direction, with so many options available for ECC that
they're a serious pain to deal with.  I've found this when interop-testing
against some of the ECC test servers that are up, you have to really, really
carefully choose what you send to the server, if you start getting flexible
with options then the other side typically disconnects, or can't complete the
handshake with various buggy behaviours (return an SSLv3 alert for a TLS 1.2
handshake, continuing with a TLS 1.1 handshake unless you manage to guess the
one specific combination of ECC parameters that the other side wants to see,
and other oddness).  ECC is actually so complex that it deserves an entire
subsection for itself.

Sub-issue: The overall suite chosen can be retroactively modified by ECC
parameters sent later in the handshake, so when choosing a suite you have to
remember not only the main suite but also one (or possibly more) backup suites
to fall back on if a later ECC parameter means you can't use your first
choice.

Solution: Select a few fixed, complete suites (rather than entire areas of
operation, with details to be sorted out later at the committee meeting) and
specify those as suites, with no further post-modification via ECC parameters
necessary.  For example I've found that absolutely everything can do
P256/SHA256/AES, so that even if I simply ignore every one of the ECC
parameters I can still connect by always choosing this combination, which
means that implementations are already using de facto fixed suites anyway.  So
adding the fixed suites:

  TLS_P256_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 = 168
  TLS_P384_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 = 169
  TLS_P256_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = 170
  TLS_P384_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = 171
  TLS_P256_ECDHE_PSK_WITH_AES_128_CBC_SHA256 = 172
  TLS_P384_ECDHE_PSK_WITH_AES_256_CBC_SHA384 = 173

to cover the common usage cases should keep about 99% of users happy while
using just one fifth of the number of ECC suites we already have now (and
that's before the infinite variety of parameter options come into play).  If
anyone really wants to make a fashion statement using Brainpool curves or
something else bizarre, they can use the parameterised way of doing things,
and good luck to them with getting anything else to talk to them.

Sub-issue: Another example of unnecessary flexibility is the way supported
curves are handled.  For example if I want to use ECDH-P256 with ECDSA-P521
then I have to specify, and the other side has to verify, groups of algorithms
(and eventually, hashes) rather than just one.  The result is the
combinatorial explosion of algorithms that made IKE such fun to get going.
Just for yucks I tried some odd combinations with one or two existing test
servers.  The ones that didn't simply disconnect couldn't complete the
handshake, except for one (semi-private) implementation.  This indicates that
if anyone did actually take advantage of the flexibility being provided, the
chances of any kind of interoperability are... low.

Solution: See previous, define some fixed suites with a single set of common
parameters, and if anyone wants to get exotic they're welcome to everything
they get.

Sub-issue: Because of the complexity of the ECC negotiation, it's quite
possible that the two sides can't agree on any common parameters, and continue
on with a standard (non-ECC) suite that they can agree on.  So the user
specifies ECC as their preferred suite(s), the negotiation completes securely,
but they're not using ECC.  Since negotiation always ends up proceeding with a
non-ECC suite, the ECC option may as well not be there.

Solution: Again, the fixed-suite approach would help address this, since
you're more likely to reach agreement on how to continue.  Alternatively,
provide an extension to say "must negotiate ECC, otherwise the connect attempt
fails".  This needs more investigation, the real problem here is Ian Grigg's
"There is only one cipher suite and that is Suite #1", i.e. you can have a
thousand suites in your handshake but the only one that matters is the first
in the list because things never get beyond that.

Issue: Because you don't know which hash algorithm will end up being used, you
need to either buffer arbitrary amounts of handshake data or speculatively run
multiple hashes in parallel, one for each algorithm you support, depending on
what ends up being negotiated.  This issue has been discussed before on the
list as well.

Solution: Yet again, the fixed-suite approach addresses this, if you're doing
(say) TLS_P256_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 then you only need to run a
SHA256 hash.

(What I've been doing, at least in the server, is to send out a cert-request
containing the single de facto hash algorithm that I use anyway, either SHA256
or SHA384 depending on the key size, forcing the client to adapt.  This is
effective in fixing the problem, but certainly not the way the mechanism is
meant to be used:

  /* In other words although it was planned as a means of indicating the
     server's capabilities, it actually acts as a mechanism for keeping the
     client-auth process sane */

So that's about it, in total there are really only three changes:

- Drop the signature_algorithm  -> cert requirement, which breaks the protocol
  and which everyone ignores anyway.

- Rename SignatureAndHashAlgorithm to HashAndSignatureAlgorithm to match
  what's actually being send.

- Provide six fixed suites for ECC to get rid of a whole host of ECC-related
  problems.

Peter.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 05 Apr 2011 10:05:34 -0700

> or reverse the order of the parameters being sent to match the name.

It would be impossible to switch the order of the parameters
sent on the wire at this point, so simply renaming the structure
is all we can do.  I support the name change.

Mike