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

Martin Rex <mrex@sap.com> Wed, 02 March 2011 01:49 UTC

Return-Path: <mrex@sap.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A3F3A6A24 for <keyassure@core3.amsl.com>; Tue, 1 Mar 2011 17:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.234
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1SvaEF39Fq6 for <keyassure@core3.amsl.com>; Tue, 1 Mar 2011 17:49:57 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 9FC933A6A21 for <keyassure@ietf.org>; Tue, 1 Mar 2011 17:49:56 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (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 <mrex@sap.com>
Message-Id: <201103020150.p221owI6017784@fs4113.wdf.sap.corp>
To: hallam@gmail.com (Phillip Hallam-Baker)
Date: Wed, 2 Mar 2011 02:50:58 +0100 (MET)
In-Reply-To: <AANLkTinE1QqjqY5g+nQtq3hKD7z5spkuFqsT=9tmB+WR@mail.gmail.com> 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
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=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 https://www.hp.com/).


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.


-Martin