Subject: Re: [TLS] DSS with other than SHA-1 algorithms

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

Some time ago I wrote:

>Not really, use of DSA server certs is practically nonexistent (anyone want
>to trawl through the EFF cert database to count them?) and use of "DSA2"
>(i.e. > 1 kbit key) certs AFAIK *is* nonexistent,

Someone has now gone through the EFF cert database and counted the number of
DSA certs present on publicly-visible servers.  In the entire world, there are
exactly twenty-five of them (and some of these, I'm guessing, are test
certs/servers).  In contrast, there are several million RSA certs.  So not
only is "DSA2" nonexistent, but for all intents and purposes DSA is
nonexistent as well.

Peter.

---

From: Hovav Shacham <[email-masked]>
Date: Wed, 6 Apr 2011 16:45:25 -0700

On Tue, Apr 5, 2011 at 4:29 AM, Peter Gutmann <[email-masked]>wrote:

> So not only is "DSA2" nonexistent, but for all intents and purposes DSA is
> nonexistent as well.
>

How about we remove DSA support from TLS, then?

-hs.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 15:50:01 +1200

>How about we remove DSA support from TLS, then?

Possibly a bit extreme, but we could at least mark it "historical" or 
"deprecated" or something.  In fact we could do that for an awful lot of 
existing cipher suites.  Note that this isn't changing the standard in any 
way, it's just documenting what's already the norm among implementations.  If 
a cipher suite's been in there for ten years and there are, approximately, 
zero cases of it being used, then saying "Don't bother with this one" in order 
to help guide implementers seems sensible.

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Apr 2011 08:15:16 +0200

> to help guide implementers seems sensible.

Unfortunately I think DSA is still mandatory-to-implement in some
protocols.  That makes it a bit more complicated, but still doable.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Apr 2011 02:20:02 +0200 (MEST)

> > >How about we remove DSA support from TLS, then?

The decision in 1997 to mandate DHE_DSS was more of a political
than a technical decision, because the DH patent had just expired
and the RSA patent would not expire until 2000 (albeit the RSA
patent existed only in that part of the world where patent filing
was allowed up to a year after publication).

> > existing cipher suites.  Note that this isn't changing the standard
> > in any way, it's just documenting what's already the norm among
> > implementations.  If a cipher suite's been in there for ten years
> > and there are, approximately, zero cases of it being used, then
> > saying "Don't bother with this one" in order to help guide
> > implementers seems sensible.
> 

DHE_DSS was mandatory to implement _only_ for TLSv1.0 (but not SSLv3!):

 TLSv1.0      http://tools.ietf.org/html/rfc2246#section-9

   9. Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

 TLSv1.1      http://tools.ietf.org/html/rfc4346#section-9

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

 TLSv1.2      http://tools.ietf.org/html/rfc5246#section-9

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
   definition).

The wording in that section 9 looks garbled to me.
I assume this requirement was supposed to apply to
"TLS compliant implementations", and not application callers of TLS
(applications would not implement, but rather request cipher suites).

In practice, a TLS implementation without these two cipher suites

      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };
      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };

will likely encounter interop problems with a number of TLS peers,
whereas TLS implementations with _only_ RSA (no DH, no DHE, no DSS)
hardly ever missed those cipher suites, except maybe in a few
exotic PKIs.

SSLv3 does not appear to have any mandatory cipher suites.
Section D.1 of the SSL version 3 draft (draft302.txt) says this:

   D.4 CipherSuites

   SSL supports a range of key sizes and security levels, including
   some which provide no or minimal security.  A proper implementation
   will probably not support many cipher suites.  

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 12 Apr 2011 17:43:45 -0700

> hardly ever missed those cipher suites, except maybe in a few

Actually, the first one is almost certainly not necessary for a
client.  A small fraction (less than 0.5%) of servers still require
TLS_RSA_WITH_RC4_128_MD5, but generally if you have
TLS_RSA_WITH_3DES_EDE_CBC_SHA you'll be OK, and you can reasonably add
TLS_DHE_RSA_WITH_AES_256_CBC_SHA to obtain forward security on those
servers that support it.  Many servers do prefer RC4 (probably for
performance reasons, if their alternative was 3DES!) but if it's not
available they'll choose something else.

There are some Internet hosts with a DSA key signed by a popular root
CA, but we're talking 0.03% or so, and many of those are expired.

For future work, I would ignore DSS.  It has some useful
characteristics in some circumstances, but ECDSA has the same
characteristics and more.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Apr 2011 15:26:50 +1200

Geoffrey Keating <[email-masked]> writes:

>For future work, I would ignore DSS.

I missed a chance to comment on this earlier, but when someone asked "why 
would you need a TLS 1.3 when TLS 1.2 is infinitely extensible", my response 
would have been "we might need a TLS 1.3 precisely *because* TLS 1.2 is 
infinitely extensible and therefore potentially infinitely complex".  TLS 1.3 
would have the one or two standard cipher suites that everyone uses anway, the 
one or two standard hash algorithms that ..., and a fixed way of doing things 
that would satisfy (literally, from the figures we've seen posted here) about 
99.995% of all users while vastly reducing the complexity (and thereby attack 
surface) of implementations.

Speaking of fixing TLS 1.2 problems, what's the next move for the action list 
of TLS 1.2 issues I posted a week or so back?  Can I get the edit token for TLS 
1.2bis, or should I do a distinct draft that'll then be folded into a future 
TLS 1.2bis?

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Apr 2011 22:33:37 -0700

On Tue, Apr 12, 2011 at 8:26 PM, Peter Gutmann <[email-masked]> wrote
> 1.2bis, or should I do a distinct draft that'll then be folded into a future

With regard to the specific list of issues you raised:

1. I'm not convinced that the requirement that relying parties check
the signature_algorithm
should in fact be relaxed. In general, I believe that semantics that
are requested in the protocol
should indeed be enforced. However, even if we were to make this
change, the simplest
thing would be a standalone document that relaxed the requirement.

2. I don't have a problem with changing the name of
SignatureAndHashAlgorithm in some future
draft, but since this is basically an editorial change, I also don't
think it merits a -bis.

3. The ECC issues you raise are not issues in 5246 at all, since ECC
is specified in a
different document (4492).

So, with this list in mind, I don't believe a revision of 5246 is
either necessary or appropriate
at this time.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Apr 2011 22:35:19 -0700

> was allowed up to a year after publication).

Yes, I agree with that assessment of the situation. Not the IESG's finest
hour, really.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Apr 2011 18:20:04 +1200

Eric Rescorla <[email-masked]> writes:

>1. I'm not convinced that the requirement that relying parties check the 
>signature_algorithm should in fact be relaxed.

This despite the fact that every single person who responded considered it a 
really bad idea (and some were far more vigorous in their comments than just 
"bad idea"), and that no implementation actually checks it?  This sort of
approach sounds more like PKIX than TLS.

>3. The ECC issues you raise are not issues in 5246 at all, since ECC is 
>specified in a different document (4492).

5246 claims to be an update to 4492 (line 4 of the doc), and a far more 
drastic one than just adding a few new cipher suites since it's not 
backwards-compatible with 4492.  This would be just another update of 4492,
and one that's fully backwards-compatible.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 13 Apr 2011 11:11:18 +0300

> approach sounds more like PKIX than TLS.

Personally I was pretty shocked by this comment, should someone gather the related discussion from the mailing list into a single statement, in case the consensus wasn't clear enough already? I think there was only one argument for the strict checking, which was constrained devices that don't want to implement multiple hash functions and signing methods. But the bad sides presented clearly outweighed the good sides, having multiple certificates for each hash function just to fill this requirement in TLS 1.2 is simply not going to happen... It's far more likely that either the strict checking is ignored or TLS 1.2 is not implemented at all.

Juho

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Apr 2011 06:47:18 -0700

> and one that's fully backwards-compatible.

Yes, the "Updates:" language in IETF documents isn't very expressive.
Sorry about
that. Regardless, if you want to do a document which only affects ECC
algorithms,
the appropriate place to do it is in a separate document, not as a
revision to 5246.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Apr 2011 17:06:17 +0200 (MEST)

Eric Rescorla wrote:
> Peter Gutmann wrote:

rfc5246 is explicit about the little it updates:

  http://tools.ietf.org/html/rfc5246#appendix-A.7

> Sorry about that. Regardless, if you want to do a document which only
> affects ECC algorithms, the appropriate place to do it is in a
> separate document, not as a revision to 5246.

I think we need both.  An update to rfc-5246 to standardize
the use of DSA & ECDSA with hash function beyond SHA-1,
and then an update of rfc4492 to make use of this and to profile
a reasonable subset of algorithm parameters.

See last paragraph of Section 7.4.8 Certificate Verify, rfc5246

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

      Because DSA signatures do not contain any secure indication of
      hash algorithm, there is a risk of hash substitution if multiple
      hashes may be used with any key.  Currently, DSA [DSS] may only be
      used with SHA-1.  Future revisions of DSS [DSS-3] are expected to
      allow the use of other digest algorithms with DSA, as well as
      guidance as to which digest algorithms should be used with each
      key size.  In addition, future revisions of [PKIX] may specify
      mechanisms for certificates to indicate which digest algorithms
      are to be used with DSA.

Since truncation of SHA-256 for DSA keypairs with public prime q shorter
than the hash output size is actually well-defined in FIPS 186-3,
a pragmatic approach for TLSv1.2 would have been to use SHA-256 rather than
SHA-1 throughout by default, i.e. including for the handshake message hash
that goes into the ClientVerify handshake message, the signature in the
ServerKeyExchange handshake message and the input to the PRF.

We cannot fix that for TLSv1.2 (rfc5246), as it would be backwards-
incompatible, so our fixing options are either to define a TLS extension
(which could be used in TLSv1.0 and TLSv1.1 with ease), or to define
a TLSv1.3.

Considering the undesirable impact of the rfc5246 SignatureAndHashAlgorithm
on the original TLS design (not knowing which hash algorithm is going to
be used for the handshake message hash of the CertifcateVerify handshake
message in TLSv1.2), so I do not think it would be sensible to define
TLSv1.3 without fixing that part of TLSv1.2.

-Martin

---

From: "Juho Vähä-Herttua" <[email-masked]>
Date: Wed, 13 Apr 2011 19:33:48 +0300

> and one that's fully backwards-compatible.

I had to go to dig out the original email describing the ECC issues, because
I didn't read it well enough the first time. I was wondering if you could
clarify the following statement a bit:

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.

I don't see how this works, because in case of ECC the server is always
selecting the cipher suite and sending the ServerKeyExchange, and these both
happen between ServerHello and ServerHelloDone. What did I miss?

Otherwise I think we can agree that the ECC extension in TLS is very complex,
but then again I'm happy that it doesn't mandate for example supporting P256
curve, because I'm working with devices that wouldn't have the resources for
handling it.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Apr 2011 13:38:13 +1200

Eric Rescorla <[email-masked]> writes:

>the appropriate place to do it is in a separate document, not as a revision
>to 5246.

OK, I'll get to work on that.  It would be good to be able to connect to an
ECC-suporting server and not have to iteratively guess what parameters you
need to send it to get it to connect.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 16 Apr 2011 20:10:24 +1200

>happen between ServerHello and ServerHelloDone. What did I miss?

Say you (i.e. the server) see, and select,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, as the best suite.  Then later in the
exchange the client says, via an extension, that it wants to do P256, which
isn't really suited for use with SHA384 (unless you go through odd truncation
calisthenics, but then why use a hash with a key size that's too short for
it?), so you have to go back and reprocess the hello to see if there's
something with SHA256 present to match that.  Then you go back and reprocess
the extensions to see whether that's OK.  In the end you may end up falling
back to a non-ECC suite, depending on your heuristics.  Of course no
implementation actually does this, they just fail the handshake unless they
see the exact parameters they want.

In practice it's even worse than that, you can use completely different curves
for the key exchange, to sign the key exchange, and for client auth, and for
hashes it's nearly as bad.  What are you supposed to do if an implementation
uses (say) P192 for the keyex signature but P521 for the keyex itself?  What
security level do you treat this as being?  You can use the unnncessary
flexibility to make a complete mess of things, and from the little testing
I've done almost anything you do that's slightly unusual results in a
handshake failure or dropped connection, and I don't even want to try and see
what happens when you start using the really odd capabilities, non-named
curves and point compression and other oddities.

So at the moment we already have a kind of de facto profile, mostly it seems
to be P256+SHA256 everywhere, with optional P384+SHA384 everywhere, and I
think I got away with P521 once or twice.  The single profile we have for ECC
use with TLS, the Suite B one, already does this, it's 256-throughout (ECC
keys and hashes) or 384-throughout (ECC keys and hashes).

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 16 Apr 2011 22:18:21 +0300

> exchange the client says, via an extension, that it wants to do P256, which

I'm sorry I probably wasn't clear enough in my message. I was trying to ask, when exactly will the client say that it wants to do P256? Are we talking about an exchange where the client doesn't send the elliptic_curves extension in its hello message? Because how I see the ECC handshake is pretty much like:

1. Client sends a ClientHello with elliptic_curves extension specifying its supported extensions
2. Server selects an ECC cipher suite and a curve that can be found in its supported curves list and client's supported curves list
3. Server sends its Certificate message which includes the curve OID of ECDSA public key (server might want to check that this can be found from elliptic_curves extension, but I'm still not quite sure that TLS should care about PKIX too much)
4. Server sends its ServerKeyExchange message which includes the curve it selected
5. Client uses the information from ServerKeyExchange and uses the same curve to send ClientKeyExchange

I tried to think of how this could be broken and could only think of the case where client doesn't send elliptic_curves extension. In that case it becomes really complicated, but doesn't seem so serious because it can be solved by simply sending the extension. And the specification could be MUCH more clear about all this, it took me quite a long time to find out how the ECC handshake should actually be done.

> security level do you treat this as being?  You can use the unnncessary

How is this different from using 1024-bit RSA keys for keyex signature but 2048-bit Diffie-Hellman keys for the keyex itself? It's a valid concern, but I don't see how it is ECC specific. And I like to keep PKIX and TLS separate, but some guidelines defining the security levels would be very useful.

> curves and point compression and other oddities.

The non-named curves is a very strange feature, but I don't see it causing any harm. If someone needs to use it somewhere, it's nice that there's a defined and standard way to do it. I could imagine a need for something like that in proprietary implementations where the TLS implementations are only going to communicate with themselves and not any 3rd party software. The specification should be just made much more clear about what is actually used and what is there just because it might be useful some day. Now it doesn't make a clear difference, and as I already found out earlier a large part of the non-named curves is impossible to implement. (see RFC 4492 errata)

> keys and hashes) or 384-throughout (ECC keys and hashes).

I think I have seen 256+384+521 quite a lot, mostly because of the Suite B requiring 256 and 384. But I'm using TLS on some devices that simply don't have the processing capacity to do P-256 handshakes well. I tried to implement P-256 modular reduction, but first of all the key length is bigger and second the pseudo-Mersenne prime used in P-256 is 2^256 - 2^224 + 2^192 + 2^96 - 1. This means modular reduction needs 256/(256-224)=8 rounds and each rounds requires 4 addition operations. Compared with for example P-224 that uses prime 2^224 - 2^96 + 1 and requires just 2 rounds and 2 addition operations, the computational difference between the curves is much larger than the bit length would let one assume.

Sorry if I'm going too much into details here, but I'm simply trying to say that requiring support for P-256 might leave out a large number of devices with lower capabilities. But I think it would be fair to define that all implementations SHOULD implement at least P-256 and P-384, maybe also P-521 if it is considered useful. Now the specification is just giving a huge list of named curves with no idea about what curves are actually used, even though pretty much all of the implementations are just using two or three of them. That's not right.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 Apr 2011 17:24:20 +1200

=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <[email-masked]> writes:

>I'm sorry I probably wasn't clear enough in my message. I was trying to ask,
>when exactly will the client say that it wants to do P256? Are we talking
>about an exchange where the client doesn't send the elliptic_curves extension
>in its hello message?

Yes.  It transforms the current ECC "suites", which aren't really suites at
all but more an indication of intent to navigate a Chinese menu with details
to be decided later, into true cipher suites.

>1. Client sends a ClientHello with elliptic_curves extension specifying its

But the elliptic_curves extension isn't part of the ClientHello.  This is the
problem, the ClientHello contains a notification-of-intent and then later bits
and pieces contain the actual suite details.  If any of the later bits and
pieces don't as expected you have to go back to the ClientHello and try
another Chinese-menu option, then go back to the later extensions and see
if... and so on, although in practice everything I've seen so far just aborts
the handshake if they don't see exactly what they expect.

>But I'm using TLS on some devices that simply don't have the processing
>capacity to do P-256 handshakes well.

That's no problem, nothing in the ECC-suites proposal says you can't still use
ECC-Chinese-menu to negotiate whatever you want.  All ECC-suites does is
provide a few standardised true suites that everyone can agree on.

>Sorry if I'm going too much into details here, but I'm simply trying to say
>that requiring support for P-256 might leave out a large number of devices
>with lower capabilities.

Oh no, this doesn't mandate anything, it just provides a single, standard,
unambiguous way of indicating a few common ECC choices, leaving the full
Chinese-menu capability in place for people whose needs aren't met by the
fixed suites.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 27 Apr 2011 13:11:51 +0300

> the handshake if they don't see exactly what they expect.

I don't quite understand this part, I know it is not indicated as MUST 
in the current RFC, but the text quite clearly says:

    The extensions SHOULD be sent along with any ClientHello message that
    proposes ECC cipher suites.

...

    A client that proposes ECC cipher suites in its ClientHello message
    appends these extensions (along with any others), enumerating the
    curves it supports and the point formats it can parse.  Clients
    SHOULD send both the Supported Elliptic Curves Extension and the
    Supported Point Formats Extension.

So every client sending a ClientHello SHOULD append the Supported 
Elliptic Curves extension in ClientHello itself and therefore the 
selected curve should be clear immediately after receiving the complete 
ServerHello including ServerKeyExchange. I'm not saying the suggested 
draft is not a good idea, I think it looks pretty good, I'm just saying 
the situation doesn't seem quite as bad as suggested.

I think the reference to Microsoft's SChannel cipher suites was a very 
good one. I wasn't aware they have already chosen to take this approach 
and it's one more argument for defining it officially. However, I'm also 
wondering why ECDHE_RSA is dropped from the draft? Even Microsoft has 
included ECDHE_RSA cipher suites in their list and since almost all 
certificates in use are RSA certificates, it is quite likely that 
ECDHE_RSA cipher suites are the only cipher suites existing TLS servers 
can start to use immediately without applying for a new certificate. 
(one can argue that they could just use RSA key exchange, but that 
doesn't have forward secrecy like ECDHE does)

Also mandating the same curve in ECDSA signature as in ECDH keys could 
be debated, but I think it's quite well justified here. It's also worth 
to note that this draft doesn't require the whole certificate chain is 
signed with ECDSA and certain curve, so for example a certificate 
containing P-256 keys signed with something else would still be valid. I 
think this is good for flexibility, in case the server administrator is 
unable to obtain a ECDSA certificate signed with ECDSA. It's up to the 
client to find out if it's able to determine its validity then.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 30 Apr 2011 00:10:34 +1200

=?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= <[email-masked]> writes:

>So every client sending a ClientHello SHOULD append the Supported Elliptic
>Curves extension in ClientHello itself and therefore the selected curve
>should be clear immediately after receiving the complete ServerHello
>including ServerKeyExchange.

Hmm, I'll try and explain this again... consider how the parts of the Client
Hello are processed.  For standard suites the server iterates through a list
of suites and selects the most cromulent one.  In my case I just have a list
of suite IDs and parameters sorted in order of preference and select the
lowest-ranked suite I find, I assume most implementations do something more or
less similar.

For the Chinese-menu suites, the server finds a Chinese menu selector and then
has to skip the remaining suites and other parts of the hello and process the
extensions to see whether what's in there matches up with that the Chinese-
menu selector requested.  For example if the Chinese menu said
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves says P256
then you have to either hope the other side does the special-case X9.62
handling for hash truncation and gets it right (and I've never been able to
find anything that does this to test mine against so who knows whether
anything does do it, and does get it right), or not take the gamble and go
back to the cipher suites and look for another Chinese-menu option, and then
skip the rest of the hello and process the extension again to see if things
work out now, and if that doesn't work either then go back ...

In practice, with the servers I tried, it was hard enough just trying to
figure out which basic combinations they supported (the usual response was a
dropped connection or aborted handshake, so I had to use trial-and-error
probing, and with some servers I never did figure out how to do more than one
or two basic combinations), and I never got to the point of being able to
interop test any of the more exotic combinations like e.g. hash truncation.

So the sole purpose of this RFC is to try and indentify the common
combinations of parameters that everyone seems to implement anyway and list
them as conventional cipher suites, with no further parameterisation required.
The intent is to try and document what everyone's doing already anyway.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 29 Apr 2011 17:24:56 +0300

> lowest-ranked suite I find, I assume most implementations do something more or

Thank you for taking the time to explain it a bit more thoroughly. And 
sorry for asking so many questions, but I want to understand the 
motivation behind this well and on the mailing list it will at least be 
documented for future references.

> menu selector requested.  For example if the Chinese menu said

Everything clear so far.

> anything does do it, and does get it right), or not take the gamble and go

Actually, I tried to look through RFC 4492 (ECC), RFC 5246 (TLS 1.2) and 
RFC 5289, but I didn't find a requirement of using SHA-384 for 
signatures for that cipher suite. So in this case the server could 
choose SHA-256 (in case it can be found from signature_algorithms 
extension) and use that for signature hashing, but use SHA-384 for the 
PRF and therefore perform no hash truncation. It would be silly to use 
two different hashes, but that is how I would probably solve it to 
maintain compatibility. I think it's a general problem with both TLS 1.2 
and ECC specifications, that they're both trying to be flexible and 
extensible up to the point that finding out the actual details becomes 
tedious work and it's more likely for many implementations to "get it 
wrong". I suppose that's exactly the thing you're trying to fix with the 
draft...

> work out now, and if that doesn't work either then go back ...

I think this what makes this worse is that existing TLS 1.0/1.1 
implementations haven't necessarily prepared well for such complicated 
cipher suite selection ECC and TLS 1.2 introduce and that makes the 
transition a bit difficult.

> interop test any of the more exotic combinations like e.g. hash truncation.

Dropping the connection or aborting the handshake is clearly wrong, but 
again as just noted, selecting a cipher suite used to be a simple thing 
and now it's suddenly quite hard. Abortion in that case is an 
understandable solution.

> The intent is to try and document what everyone's doing already anyway.

Should it be added to the draft that for example implementations using 
mentioned SHA-256 cipher suites must also send signature_algorithms 
extension with corresponding hash and ECDSA pair? Right now it only 
points out the used hash functions, but TLS 1.2 specification quite 
clearly says that one should default to the {sha1,ecdsa} combination if 
no extension is sent. I think this draft doesn't make it clear enough if 
it overrides that requirement or not.

Also, the term "Chinese-menu" is a word I haven't seen in any existing 
TLS related RFC, even though it is very widely used in your draft and 
related discussion. I think it would make sense to at least define the 
meaning of the word a bit more clearly if it is going to be used, but it 
might be worth changing it to something completely different. I for one 
have lived in China for some years and have always managed to agree on 
the menu and the details, so I believe at least the Chinese people might 
find it puzzling. Not to mention someone might even consider it offending...

Juho

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 29 Apr 2011 13:15:10 -0400

> find it puzzling. Not to mention someone might even consider it

I agree that this should be clarified, and the term possibly replaced
with something more suitable.  I think the sense that Gutmann is going
for here is something like  "a la carte" (if we want to stay in the
culinary metaphor) or "combinatorial explosion of possible parameters"
(if we want to be dry and technical about it).

	--dkg