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

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 May 2011 20:56:01 +1200

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

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

While I haven't actually tried this, I strongly suspect (given the fact that 
servers generally fail the handshake if you try odd things) that this is 
another one of those tricks that you don't want to try applying :-).

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

That's quite possible.  At the moment both TLS-ECC and TLS 1.2 deployment is 
so vanishingly small that we have little data to go on, and as an implementer 
you really can't see how problematic things get until you do implement and 
deploy something.  One of the reasons for getting the draft out there is to 
try and both point out, and then address the problem before it becomes a real 
issue.

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

Hmm, it should already say that:

      ECDSA signature in Server Key Exchange message: P256 or P384 curve
      as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as
      indicated in the suite name.

And for client auth:

      Client authentication in Certificate Request/Certificate Verify
      messages: SHA1, SHA256, or SHA384 as indicated in the suite name.

In other words "if you're using SHA256 at location X then you should use it
at location Y as well" (I can't imagine why you'd want to use, say SHA-1 at
point X but then SHA256 at point Y, and if anyone really does want this they
can still do it using the existing Chinese-menu option).

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

I used the term "Chinese menu" because it's common usage in the US for a mix- 
and-match selection of items, the "one from column A, one from column B" 
selection, and figured using "table d'hote" and "a la carte" might be going a 
bit too far :-).  I'll add a rationale section that discusses the naming (see 
e.g. 
http://www.barrypopik.com/index.php/new_york_city/entry/one_from_column_a_one_from_column_b_chinese_menu_ordering/, 
from a quick Google search, perhaps it's a US-only colloquialism), and also 
more on why there's a problem and why it's a good idea to address it fairly 
soon.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 04 May 2011 13:40:53 +0300

> try and both point out, and then address the problem before it becomes a real

I think the deployment is very small on the server side, but I would say 
it is quite common on the client side. I know at least Firefox has had 
ECC cipher suites enabled by default for quite a long time (3 years or 
so), and I think that attributes to somewhere close to one third of all 
browsers globally. (according to Mozilla more than 350 million users) 
Calling TLS-ECC deployment vanishingly small is a bit of an 
understatement, don't you think? Should at least carefully consider what 
implications the draft has on interoperability with existing 
implementations, especially if the handshake methods are made mutually 
exclusive.

> can still do it using the existing Chinese-menu option).

That's exactly the parts of the draft I am referring to. This should be 
combined with the RFC 5246 text:

    If the client does not send the signature_algorithms extension, the
    server MUST do the following:
...
    -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
       ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Your draft does not mandate sending the signature_algorithms extension, 
but at the same time it does say one should use the SHA256 or SHA386 for 
signatures. Does it override the above clause of TLS 1.2 or does it 
implicate signature_algorithms have to be always sent in case any of 
those cipher suites are to be offered?

> more on why there's a problem and why it's a good idea to address it fairly

That explains it much better, I tried to google it before but didn't 
really get any sensible results. Looks like searching for "chinese menu 
column" gives more hits, although I wonder how common knowledge it is, 
because most search results seem to be explaining it to readers even 
though they are not technical specifications. But I can confirm at least 
it is not the common way to order food in China.

If we go into slight nitpicking, in Chinese menu the choice from column 
A doesn't affect the choice from column B and the two choices are 
independent. In case of TLS and ECC cipher suites, the choice from 
column A enables making the choice from column B making them mutually 
dependent. I just don't like the term very much, I think referring to 
the two options as simplified ECC parameter selection and extension 
based parameter selection or something similar should suffice. But I can 
wait for the rationale section, I think it's a good idea to add.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 May 2011 02:00:38 +1200

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

>I think the deployment is very small on the server side, but I would say it
>is quite common on the client side. I know at least Firefox has had ECC
>cipher suites enabled by default for quite a long time (3 years or so), and I
>think that attributes to somewhere close to one third of all browsers
>globally. (according to Mozilla more than 350 million users) Calling TLS-ECC
>deployment vanishingly small is a bit of an understatement, don't you think?

"Implemented in the client" != "used" though.  The only hard data that we have
at the moment, the SSL Observatory, indicates:

Number of deployed DSA TLS servers with certs chaining to a trusted root: 25
Number "  " ECC  "  "  ": Zero
Number "  " RSA  "  "  ": Millions

For non-trusted certs I think there were a total of six servers doing ECC in
the entire world, and I'm guessing most or even all of them are the small
number of public interop servers out there.

Both of those make it "vanishingly small" (at least for public deployment) as
far as I'm concerned :-).

>Your draft does not mandate sending the signature_algorithms extension, but
>at the same time it does say one should use the SHA256 or SHA386 for
>signatures. Does it override the above clause of TLS 1.2 or does it implicate
>signature_algorithms have to be always sent in case any of those cipher
>suites are to be offered?

Ah, I see what you mean.  OK, I'll add a note to address this.  RFC 5246
assumes the universal-substrate SHA1 if you forget the signature_algorithms
extension as a means of handling the lack of an explicit indication since
there's no other way to tell what to use, but the ECC-suites draft makes it
explicit what hash to use so there's no need to use the fall-back rules.

>That explains it much better, I tried to google it before but didn't really
>get any sensible results. Looks like searching for "chinese menu column" gives
>more hits,

I've added a note to explain it for non-US readers.  If you search for "one
from column A one from column B" you'll get an awful lot of hits, things
like medical papers using that in the title:

http://www.ncbi.nlm.nih.gov/pubmed/11827830

The search term "Chinese menu" gets overwhelmed by links to restaurants.

Peter.

---

From: Jack Lloyd <[email-masked]>
Date: Mon, 9 May 2011 16:05:43 -0400

> Number "  " RSA  "  "  ": Millions

So, nobody at all has an ECDSA certificate, but it makes sense to only
assign ciphersuites to algorithm sets that require ECDSA certificates
because that is the common case?  I'm having difficult reconciling
the above information with the apparent intent of the i-d.

-Jack

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 May 2011 01:49:35 +1200

Jack Lloyd <[email-masked]> writes:

>So, nobody at all has an ECDSA certificate,

Nobody has an ECSDA cert *signed by a trusted CA*, i.e. something that a
browser will connect to without setting off all sorts of alarms.

>but it makes sense to only assign ciphersuites to algorithm sets that require
>ECDSA certificates because that is the common case?

It's the common case based on a survey of all (known) publicly-deployed
servers running TLS-ECC, representing (at least) Microsoft, Apache (presumably
OpenSSL), and NSS.  That's the three biggest players in the market (and some
smaller ones as well), so I think it's a pretty good representative sample.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 May 2011 18:06:21 +0200

> browser will connect to without setting off all sorts of alarms.

Indeed but on the same study you based your point on deprecating DSA.

> smaller ones as well), so I think it's a pretty good representative sample.

I don't really understand. So is ECDSA used for self-signed
certificates? Is it used for client certificates (and thus not
discovered by this study?). According to me this study would be an
argument for the _RSA ecc ciphersuites rather than the ECDSA.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 10 May 2011 22:30:24 +0300

> argument for the _RSA ecc ciphersuites rather than the ECDSA.

I was about to say the same. The draft refers to http://msdn.microsoft.com/en-us/library/aa374757%28v=vs.85%29.aspx as a major implementation already doing the suggested suites, but at the same time drops all ECDHE_RSA ciphersuites from the exact same document and only includes the ECDHE_ECDSA ciphersuites. If it's true that there's basically zero ECDSA certs signed by a trusted CA, it would be a quite strong argument to do the opposite.

What's the motivation of dropping ECDHE_RSA suites if there are millions of RSA certificates?

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 May 2011 14:31:46 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>I don't really understand. So is ECDSA used for self-signed certificates?

Yes.

>According to me this study would be an argument for the _RSA ecc ciphersuites
>rather than the ECDSA.

Why?  The draft contains the combinations of parameters and options that
everything seems to support and everything seems to get right.  Why the
obsession with _RSA?

(Note, if you can document support for, and interoperability among, Microsoft,
NSS, OpenSSL, and one or two other implementations, for _RSA, I'll be happy to
add it).

To reiterate this yet again, the draft collects in one place the various
combinations of parameters and options that everything I could find supports
and handles correctly.  What it doesn't contain is speculative options that
may or may not work and may or may not be supported.  It is an attempt to
document the status quo and point out the best options to use in order to
maximise interoperability.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 May 2011 05:08:39 +0200 (MEST)

> Number "  " RSA  "  "  ": Millions

I believe the EFF slides give a figure of 1.3 million RSA certs issued
under a well-known commercial Root.

There are probably a number of reasons why we are seeing very
few (if any) ECDSA certs issued by commercial CAs.  EC algorithms are
still patent encumbered, and the licensing scheme by the patent holder
was a pay-per-issued-certificate targetting commercial CAs.

The other issue is that there still is an awfully large installed
base which doesn't support such certs--so as long as RSA is still
considered secure, why bother with EC certificates?

There seems to be a preference for ECDSA at NIST.  But there also
was a preference for DSA at NIST, including a bias for the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLSv1.0
that was completely ignored by the marketplace.

At the time when the not-EC-capable TLS implementations in the
installed base have died off, the current EC-patent issues will
also have evaporated...  :)

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 11 May 2011 09:58:45 +0300

> everything seems to support and everything seems to get right.  Why the

I wouldn't want to repeat myself and I certainly am not obsessed with _RSA (because in all ways it is a bad solution), but do you have any data about which implementations didn't support or "get right" the _RSA ciphersuites? 

ECDH and ECDSA are basically the same calculation (EC point multiplication), so it makes much more sense to do ECDHE_ECDSA from idealistic point of view, but the motivation seems to be purely practical. The fact is that I can only get RSA certificates from my CA, so if I want forward secrecy I need to do either DHE_RSA or ECDHE_RSA.

> NSS, OpenSSL, and one or two other implementations, for _RSA, I'll be happy to

Microsoft documents them on their website as supported, OpenSSL should support them as well and NSS based browsers (at least Firefox) are offering them in ClientHello by default. I can go to do some interoperability testing, but before that I would like to know did you ever test the _RSA ciphersuites? I think it is rather rude when people present a perfectly valid question and the response is to call them obsessive. And I would love to get some data about how _RSA suites fail so I wouldn't have to do any tests, but I think this question is completely in the scope of the draft and should be resolved before releasing it. It seems the motivation of dropping _RSA suites is either because they don't interoperate (for a reason that is difficult for me to see) or because the author rightly believes they are crap and not worth documenting. Either way the motivation should be known.

So to repeat my main point, were the ECDHE_RSA ciphersuites ever tested for interoperability and is the status of their interoperability known? Simple yes or no to both will do and you can ignore everything else I said above.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 May 2011 20:29:25 +1200

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

>So to repeat my main point, were the ECDHE_RSA ciphersuites ever tested for
>interoperability and is the status of their interoperability known?

This gets a bit political, see my reply off-list.  In short, if there's
demonstrated interoperability between the different implementations I'm happy
to add it, but the last I saw (and heard from others) this wasn't the case.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 May 2011 20:38:33 +1200

Martin Rex <[email-masked]> writes:

>There are probably a number of reasons why we are seeing very few (if any)
>ECDSA certs issued by commercial CAs.  EC algorithms are still patent
>encumbered, and the licensing scheme by the patent holder was a pay-per-
>issued-certificate targetting commercial CAs.

Are the CAs impeded by patents?  You can do ECC without infringing on any
patents, and I would guess the HSMs that do use any patented aspects of ECC
have already paid their tithe to Certicom.

>The other issue is that there still is an awfully large installed base which
>doesn't support such certs--so as long as RSA is still considered secure, why
>bother with EC certificates?

I think that's the real reason, use of ECC is essentially a fashion statement,
and the fact that any use condemns you to Browser Warning Hell makes it a very
expensive one.  The one upside to this is that after six years we still have
next to no (public) deployed base to potentially cause problems, so it's still
possible to fix issues without breaking lots of things.

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 May 2011 11:49:12 +0100

On Wednesday 11 May 2011 09:38:33 Peter Gutmann wrote:
> Are the CAs impeded by patents?

The first commercial CA to answer "No" and proceed to issue ECC certs will 
almost certainly end up in court with an expensive legal bill.  Even if the 
correct answer really is "No".

So yes, the CAs are impeded by patents.

> You can do ECC without infringing on any patents, and I would guess the HSMs
> that do use any patented aspects of ECC have already paid their tithe to
> Certicom.

nCipher have paid their tithe:
http://www.certicom.com/index.php/2005-press-releases/35-2005-press-
releases/247-certicom-licenses-intellectual-property-to-ncipher

However, last I heard, nCipher will only grant their HSMs' ECC functionality 
to be enabled for:
  a) customers who are not CAs.
  b) customers who are CAs and who have a suitable CA licence from Certicom.

> >The other issue is that there still is an awfully large installed base
> >which doesn't support such certs--so as long as RSA is still considered
> >secure, why bother with EC certificates?
> 
> I think that's the real reason, use of ECC is essentially a fashion
> statement, and the fact that any use condemns you to Browser Warning Hell

There doesn't have to be Browser Warning Hell.

A server could have an RSA cert and an ECC cert.  When a client advertises 
support for any ECC cipher suites in its "ClientHello" message, the server can 
send its ECC cert in its "Certificate" message.  When a client doesn't 
advertise support for any ECC cipher suites, the server can "fall back" to its 
RSA cert.
I believe that OpenSSL's server code behaves in this way.

Of course, configuring 2 certs would be extra hassle (and possibly extra 
expense) over configuring just 1 cert.  So my guess is that many sites would 
still not bother with ECC certs, even if they were bundled free with paid RSA 
certs.

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2011 07:14:10 -0700

> So yes, the CAs are impeded by patents.

This makes it sound like there are patents are issuing ECC certs. However, that statement seems to fly in the face of RFC 6090. Can you clarify? This seems particularly odd because Comodo has issued itself an ECC certificate that is now widely distributed.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 May 2011 18:19:58 +0200 (MEST)

Peter Gutmann wrote:
> > According to me this study would be an argument for the _RSA ecc
> > ciphersuites rather than the ECDSA.
> 
> (Note, if you can document support for, and interoperability among,
>  Microsoft, NSS, OpenSSL, and one or two other implementations,
>  for _RSA, I'll be happy to add it).
> 

I think it is worth considering to describe an interoperable set of
_RSA based EC ciphersuites and parameters.

In case that there are, in fact, interop problems with the existing
definitions in the installed base, TLS WG should try to figure out
the kind of problems that exist in the installed base and
try to come up with solutions for these interop problems.

Possible solutions for interop problems with _RSA cipher suites might be:

  - describe workarounds to deal with the problem within the currently
    defined protocol options.

  - modify the existing (TLS extension) definition (in a backwards-compatible
    fashion, of course) to overcome the problem

  - add a new extension

  - define new cipher suite codepoints to represent the intended purpose
    and interop-test _before_ shipping implementations this time around

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Thu, 12 May 2011 11:10:50 +0100

On Wednesday 11 May 2011 15:14:10 Paul Hoffman wrote:
> >>> There are probably a number of reasons why we are seeing very few (if
> >>> any) ECDSA certs issued by commercial CAs.  EC algorithms are still
> >>> patent encumbered, and the licensing scheme by the patent holder was a
> >>> pay-per- issued-certificate targetting commercial CAs.
> >> 
> > The first commercial CA to answer "No" and proceed to issue ECC certs
> > will almost certainly end up in court with an expensive legal bill. 
> > Even if the correct answer really is "No".
> > 
> This makes it sound like there are patents are issuing ECC certs. However,
> that statement seems to fly in the face of RFC 6090. Can you clarify?

Hi Paul.  Thanks for pointing me at RFC 6090.  I'd not seen it before.  I 
agree that it appears to claim that issuing ECC certs is unencumbered by 
patents.

I wonder if Certicom are aware of this RFC, and if so, what their opinion of 
it is.

> This seems particularly odd because Comodo has issued itself an ECC
> certificate that is now widely distributed.

Certicom are aware of our ECC root certificate and they have not raised any 
objections.  Several other CAs are now distributing ECC Roots too.  I think 
Certicom see this activity as increasing the likelihood that CAs will pay to 
license their patents.

However, AIUI, we've been led to believe that Certicom would object if a CA 
started to issue ECDSA-signed end-entity certs without some kind of license 
from Certicom.

Rob Stradling

---

From: Rob Stradling <[email-masked]>
Date: Fri, 13 May 2011 10:55:57 +0100

On Thursday 12 May 2011 11:10:50 Rob Stradling wrote:
<snip>
> I wonder if Certicom are aware of this RFC, and if so, what their opinion
> of it is.

Certicom made an IPR disclosure [1] in relation to draft-03 of what is now RFC 
6090.  Thanks to those who told me about this off-list.

I believe that Certicom's opinion is that commercial CAs would need to license 
at least [2] and [3] before they could...
  - verify the parameters of an EC public key supplied by a customer.
  - use the ECDSA algorithm to sign a certificate for a customer.

So I return to my original conclusion: Yes, the CAs are impeded by patents.

A colleague recalled a case (identities removed) to me recently:
"I remember that one of the biggest hits that Company X took was getting into 
a patent dispute with Company Y.  The Company Y claims were absolute 
unmitigated crud.  Company X won hands down.  But it cost them $2 million and 
it defocused their executive management team for over a year".

IANAL or a cryptographer.  I don't know if Certicom would win or lose a patent 
dispute against a commercial CA that issued ECC certs without a license.  But 
even if I was confident that Certicom would lose, I wouldn't want to pay $2M in 
legal fees.

IMHO, commercial CAs will only start issuing ECC certs if Certicom will first 
devise a suitable licensing scheme.

[1] https://datatracker.ietf.org/ipr/1337/
[2] http://www.freepatentsonline.com/6704870.html
[3] http://www.freepatentsonline.com/7215773.html

<snip>

Rob Stradling

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 14 May 2011 18:34:52 +1200

Martin Rex <[email-masked]> writes:

>I think it is worth considering to describe an interoperable set of _RSA 
>based EC ciphersuites and parameters.

Sure, as I've said ealier if someone can go around and find a common set of 
parameters that's supported by, and works, for { Microsoft, NSS, OpenSSL, and 
one or two others } I'll be happy to add them (meaning, "document that this 
particular combination works") for the draft.

This is a hint to someone else :-).  I'll try and get round to it when I can, 
but I'm a bit busy at the moment, and as I mentioned earlier the last time I 
looked there didn't seem to be a common set of parameters where things worked.

Peter.