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

Rob Stradling <rob.stradling@comodo.com> Wed, 11 May 2011 10:50 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D865E0720 for <tls@ietfa.amsl.com>; Wed, 11 May 2011 03:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level:
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaU5R2hcoOdl for <tls@ietfa.amsl.com>; Wed, 11 May 2011 03:50:26 -0700 (PDT)
Received: from mcmail1.mcr.colo.comodo.net (mail1.comodogroup.com [91.199.212.133]) by ietfa.amsl.com (Postfix) with ESMTP id 39C78E0679 for <tls@ietf.org>; Wed, 11 May 2011 03:50:25 -0700 (PDT)
Received: (qmail 26456 invoked by uid 1008); 11 May 2011 10:50:24 -0000
Received: from mail.india.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mcmail1.mcr.colo.comodo.net (qpsmtpd/0.40) with ESMTP; Wed, 11 May 2011 11:50:24 +0100
Received: (qmail 8615 invoked by uid 1000); 11 May 2011 10:50:23 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Wed, 11 May 2011 11:50:23 +0100
From: Rob Stradling <rob.stradling@comodo.com>
To: tls@ietf.org
Date: Wed, 11 May 2011 11:49:12 +0100
User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r4; KDE/4.6.2; i686; ; )
References: <E1QK4wD-0007QV-Qp@login01.fos.auckland.ac.nz>
In-Reply-To: <E1QK4wD-0007QV-Qp@login01.fos.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201105111149.12286.rob.stradling@comodo.com>
Subject: Re: [TLS] DSS with other than SHA-1 algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2011 10:50:27 -0000

On Wednesday 11 May 2011 09:38:33 Peter Gutmann wrote:
> Martin Rex <mrex@sap.com> 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?

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