Re: [keyassure] Opening issue #21: "Need to specify which crypto

Martin Rex <> Wed, 02 March 2011 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9A3F3A6A24 for <>; Tue, 1 Mar 2011 17:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.234
X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u1SvaEF39Fq6 for <>; Tue, 1 Mar 2011 17:49:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FC933A6A21 for <>; Tue, 1 Mar 2011 17:49:56 -0800 (PST)
Received: from by (26) with ESMTP id p221oxoW020020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 02:50:59 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Phillip Hallam-Baker)
Date: Wed, 2 Mar 2011 02:50:58 +0100 (MET)
In-Reply-To: <> from "Phillip Hallam-Baker" at Mar 1, 11 04:37:27 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Mar 2011 01:49:57 -0000

Phillip Hallam-Baker wrote:
> Plenty is not the point.
> SHA1 is no longer regarded as acceptably secure. SHA2 is based on the
> same construction and is thus similarly suspect.
> We don't use SHA1 in legacy browsers because we like it. We use SHA1
> in legacy browsers because we have not worked out how to transition
> away from it. The transition from MD5 to SHA1 was painless only
> because all browsers were required to support both standards.

Transition from MD5 to SHA1?  I seem to have missed that entirely.

MD5 was removed from the PRF in the SSLv3->TLSv1.0 protocol revision,
but even TLSv1.1 uses a combination of MD5+SHA1 for digital signatures.

And there are still a number of TrustAnchors in every Browser that
carry an md5WithRsaEncryption signature.

But it's actually worse than that -- VeriSign still has a CA cert
in service with an md2WithRsaEncryption -- and is still using it
productively (check

Considering the transition SHA-1 --> SHA-256.  That was goofed
in TLSv1.2, by defining the default hash algorithm for the digital
signature structs to default to SHA-1 (only) -- which is actually
weaker than SSLv3/TLSv1.0/TLSv1.1 ...

> This particular topic is one on which the Security ADs and the IETF
> chair have very very specific opinions on. And given their role in
> trying to effect an industry wide transition to stronger algorithms, I
> think that they are quite right to insist on them.

DANEs security is vitally dependent on DNSSEC, and for DNSSEC, SHA-1
seems to be the mandatory-to-implement algorithm for signatures.

Inuitively, why don't we tie DANE's hash algorithm to DNSSECs algorithm?

Making DANE an early adopter of SHA-3 while DNSSEC still uses SHA-1
amounts to silicon snake oil -- i.e. needless complexity.