IETF Logo Mail Archive

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

Juho Vähä-Herttua <juhovh@iki.fi> Thu, 28 April 2011 11:02 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 5F001E0663 for <tls@ietfa.amsl.com>; Thu, 28 Apr 2011 04:02:32 -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 8RhvI+p-tIMP for <tls@ietfa.amsl.com>; Thu, 28 Apr 2011 04:02:31 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8CE06B1 for <tls@ietf.org>; Thu, 28 Apr 2011 04:02:30 -0700 (PDT)
Received: from mail.visino.fi (84.251.121.70) by jenni1.inet.fi (8.5.133) id 4D9AD3B801078B24 for tls@ietf.org; Thu, 28 Apr 2011 14:02:29 +0300
Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 89A50201C5 for <tls@ietf.org>; Thu, 28 Apr 2011 14:02:14 +0300 (EEST)
Message-ID: <4DB94922.7080806@iki.fi>
Date: Thu, 28 Apr 2011 14:01:54 +0300
From: Juho Vähä-Herttua <juhovh@iki.fi>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: tls@ietf.org
References: <4DB6FD14.20203@gnutls.org> <E1QF0xG-00064o-8q@login01.fos.auckland.ac.nz> <BANLkTikcf9wS7=5WuZBa-E1+Yg4bCob61w@mail.gmail.com>
In-Reply-To: <BANLkTikcf9wS7=5WuZBa-E1+Yg4bCob61w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
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: Thu, 28 Apr 2011 11:02:32 -0000

28.4.2011 11:59, Nikos Mavrogiannopoulos kirjoitti:
> 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.

Before suggesting making the extensions only to be used for unnamed 
curves, it should be mentioned that RFC 4492 defines total of 25 named 
curves, of which this draft redefines only the 2 most commonly used. 
Also there are a lot of existing implementations out there that already 
implement ECC and many browsers have ECC turned on by default, most of 
them implement the suites listed in the draft. Making the draft mutually 
exclusive with existing ECC methods would make the transition almost 
impossible, causing more compatibility problems than it is trying to solve.


Juho

v2.23.0 | Report a Bug | By Email