IETF Logo Mail Archive

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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 26 April 2011 17:12 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 91987E07E7 for <tls@ietfa.amsl.com>; Tue, 26 Apr 2011 10:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Y1wu+xH7bJwm for <tls@ietfa.amsl.com>; Tue, 26 Apr 2011 10:12:57 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9FE07A0 for <tls@ietf.org>; Tue, 26 Apr 2011 10:12:57 -0700 (PDT)
Received: by ewy19 with SMTP id 19so322725ewy.31 for <tls@ietf.org>; Tue, 26 Apr 2011 10:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=LKx/EWaMI6SrgtGc0kKE3aAnkhI/NF7Uexn1cY3g098=; b=IiaP7Byt5AaF+UlgZZKRBRLViZDVcfP+TIxs7touuG3Ape7g0tE0KSwn2e3vE/jtG9 +dPj4LTnvTb5CPEaeF4LU8pfF3Qy8xpBqWfKQKwKzS2CJFRyYJG8pX+SMeCXHDDWwl9T cB85z3MROGSDsnUVzJFCy2pC/++Bt6iyrgtZw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kG2rfWZyUad7Iej6BmHwVxZlvbWKtbNNV2Sw0bx3C80r3Gu68Chbhla/+hu5H48i88 7kLG0Et+KqRBwpMtS7R8lB9qUHrLzHoNbVwLiFNw3tw9z86500ZoatzYHnVRA7akvgZi tg84/eAPFebHK7udJ1nqHnv818Z+Tx4qHdZIo=
Received: by 10.14.126.73 with SMTP id a49mr459160eei.178.1303837975668; Tue, 26 Apr 2011 10:12:55 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id y7sm4948718eeh.7.2011.04.26.10.12.53 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 10:12:54 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4DB6FD14.20203@gnutls.org>
Date: Tue, 26 Apr 2011 19:12:52 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: tls@ietf.org
References: <E1QDyT7-0006mk-PF@login01.fos.auckland.ac.nz>
In-Reply-To: <E1QDyT7-0006mk-PF@login01.fos.auckland.ac.nz>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Tue, 26 Apr 2011 17:12:58 -0000

On 04/24/2011 02:31 PM, Peter Gutmann wrote:
> I've now posted a first draft for comment:
> http://www.ietf.org/id/draft-gutmann-tls-eccsuites-00.txt

I have not implemented ECC ciphersuites, but the things
that striked me while reading it are:
* There is no mention of ECDHE_RSA or anon ciphersuites.
For me they are the most important as they optimize normal DH
using existing RSA certificates (in the _RSA case).

* A single ciphersuite negotiates the ECDHE parameters
AND the parameters of the ECDSA certificate. Could there
be cases where one can verify any ECDSA certificate, and
only his capabilities to ECDHE are restricted? In that
case it might be better to allow for any ECDSA certificate
rather than handling each different parameter
as different algorithm. (but I repeat I don't have an
overview of ECC in practice).

* It doesn't really need to be that aggressive with
the previous attempt. If this one is better/simpler it
will be used in practice and replace the old one. Maybe
some examples of failures of the current TLS-ECC-RFC
might be more convincing.

regards,
Nikos

v2.23.0 | Report a Bug | By Email