IETF Logo Mail Archive

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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 28 April 2011 08:59 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 11355E06D6 for <tls@ietfa.amsl.com>; Thu, 28 Apr 2011 01:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.017
X-Spam-Level:
X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 QeKJ5JTH9TPd for <tls@ietfa.amsl.com>; Thu, 28 Apr 2011 01:59:36 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5DFDE06D4 for <tls@ietf.org>; Thu, 28 Apr 2011 01:59:36 -0700 (PDT)
Received: by pwi5 with SMTP id 5so1477531pwi.31 for <tls@ietf.org>; Thu, 28 Apr 2011 01:59:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y5JkcoC0HqaQEBWg9fSWhI5aK9brmyCiNiQSBm8OytU=; b=Kgk4EkHNUWU7DmbhxEygsO3sqJVsS00oucMiws5g8Cbw3cHuE7OA1WhohkaBPW/3Je TMoAVZeVNxjw7KNL8swBobIqXG1E0mZGYDeDiXXEwgqHimWlNRFhWPgveA1VH1C6A6q4 cQiBOYd8dzxHMi5V3BaTniXT+xf+6W4KKo1w8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Fzu6NvQBlMA6aCkrmACkuDSty0974RPemQ05PUg0XJfVVJ+HrI0E95vXFJiofZy7YH mNP22EyxTw91I9DLZ41Rv/qNOY6HAnefHYD3qNF1cKv6kDOFOuvnM1gssT5wromD6Bwq ryqmHjLjJ5kPZWspEUD6Ne5rpA18WnAc63iE0=
MIME-Version: 1.0
Received: by 10.68.33.8 with SMTP id n8mr3277991pbi.51.1303981176221; Thu, 28 Apr 2011 01:59:36 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.68.40.130 with HTTP; Thu, 28 Apr 2011 01:59:36 -0700 (PDT)
In-Reply-To: <E1QF0xG-00064o-8q@login01.fos.auckland.ac.nz>
References: <4DB6FD14.20203@gnutls.org> <E1QF0xG-00064o-8q@login01.fos.auckland.ac.nz>
Date: Thu, 28 Apr 2011 10:59:36 +0200
X-Google-Sender-Auth: JDCkqC-rewH0NzbuIvulRnQwy7s
Message-ID: <BANLkTikcf9wS7=5WuZBa-E1+Yg4bCob61w@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 28 Apr 2011 08:59:37 -0000

On Wed, Apr 27, 2011 at 11:22 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:

>>* 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.
> This doesn't replace the existing one, it complements it.  This profiles a set
> of de facto standard cipher suites (rather than RFC 4492's Chinese menus) that
> are already in common (well, as common as TLS-ECC gets anyway, which is to say
> "not very") use.  The point is to have them standardised before TLS-ECC does
> get common and the existing interop problems get worse.

Thinking about it, it would be very IPSec to have two ways to do the
same thing.
If this method is intended to replace the current ECC draft, it should
specify how
the extensions are used once this draft is supported. I'd suggest to make it
mutual exclusive. If this draft is supported then the extensions are used to
negotiate unnamed curves only or so.

regards,
Nikos

v2.23.0 | Report a Bug | By Email