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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 10 February 2011 16:05 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A26D3A69FA for <tls@core3.amsl.com>; Thu, 10 Feb 2011 08:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIN7llyCmOFg for <tls@core3.amsl.com>; Thu, 10 Feb 2011 08:05:47 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 27F6B3A69C8 for <tls@ietf.org>; Thu, 10 Feb 2011 08:05:47 -0800 (PST)
Received: by qyj19 with SMTP id 19so1201372qyj.10 for <tls@ietf.org>; Thu, 10 Feb 2011 08:05:59 -0800 (PST)
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=JgjDhrtZOP9WOXMsOfjd5cB2krtbuvMzOe5qlzJVXG4=; b=pNtnnPkR+OrojjlmBGuc7ezr9E+LnHNMt7WOLOol3W52qnWVGFjPNWwlLqgKFbj342 qBxk5XxBI3Tw5UKAZeKMUbiB094wLJewIIt0St46SSIIwaZ3p44+vsm2KkO8Ic8HYal5 2nBw09KVwkIlRAa5lDHIP3d55FS4l9c6w+tsE=
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=IkqO9fFOqltiCNjQkyRPms4nhQoUSN35OEXcnOecHk73S0ocwwfIqJgT3rNxuAqhk5 JrcweagjvZy9eJrck0WDVE0tpRbDaNGMDSxe25IZcvo2ml4ZObabYRU8t1vJ6n3xstnz U6D4dm8CcjJzxdrWZXBtTVH967SSpD2/DWXjU=
MIME-Version: 1.0
Received: by 10.224.11.75 with SMTP id s11mr17345627qas.16.1297353959296; Thu, 10 Feb 2011 08:05:59 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.232.18 with HTTP; Thu, 10 Feb 2011 08:05:59 -0800 (PST)
In-Reply-To: <E1PnYjB-0004LT-9j@login01.fos.auckland.ac.nz>
References: <AANLkTinUrYTOT0kkw_jvQ3P3_jHWda6kCgDh+VwFKW8j@mail.gmail.com> <E1PnYjB-0004LT-9j@login01.fos.auckland.ac.nz>
Date: Thu, 10 Feb 2011 17:05:59 +0100
X-Google-Sender-Auth: YxDUHgv-Ukd1ZtTADwQu1--Hfrg
Message-ID: <AANLkTimT7rnEiSxMtCYyJkZHkXqpxAC2pK_UyNbvMyLu@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.9
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/listinfo/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, 10 Feb 2011 16:05:48 -0000

On Thu, Feb 10, 2011 at 4:46 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
>>So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you use
>>SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 that
>>requires 20 bytes of SHA-1... Quite some situation :)
> Not really, use of DSA server certs is practically nonexistent (anyone want to
> trawl through the EFF cert database to count them?) and use of "DSA2" (i.e. >
> 1 kbit key) certs AFAIK *is* nonexistent, so it's nothing to worry about.  To
> look at it another way, worrying about this is like worrying about what colour
> unicorns are.

Well, it is chicken and egg problem. If they cannot be used in practice with any
application because the spec is not clear, no-one will use them. If the spec was
clear, and interoperable implementations could be made then, someone could
apply for a certificate with a DSA key. But anyway since it's supposed to
be supported by TLS, it should be clarified, otherwise it's better to drop it
completely...

regards,
Nikos