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

Juho Vähä-Herttua <juhovh@iki.fi> Wed, 11 May 2011 06:59 UTC

Return-Path: <juhovh@iki.fi>
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 E9C61E06C1 for <tls@ietfa.amsl.com>; Tue, 10 May 2011 23:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 hEcC01PybTO8 for <tls@ietfa.amsl.com>; Tue, 10 May 2011 23:59:06 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 04D00E06B3 for <tls@ietf.org>; Tue, 10 May 2011 23:59:05 -0700 (PDT)
Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC7260191343B; Wed, 11 May 2011 09:58:52 +0300
Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id ADA5B201A6; Wed, 11 May 2011 09:58:46 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary="Apple-Mail-5-372411133"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Juho Vähä-Herttua <juhovh@iki.fi>
In-Reply-To: <E1QJzDG-0006iS-85@login01.fos.auckland.ac.nz>
Date: Wed, 11 May 2011 09:58:45 +0300
Message-Id: <ACDBA7CB-DF83-4624-BAF6-3EC1A9D814B7@iki.fi>
References: <E1QJzDG-0006iS-85@login01.fos.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.1084)
Cc: tls@ietf.org
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 06:59:11 -0000

On May 11, 2011, at 5:31 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:
>> 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?

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.

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

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