Re: [dane] Digest Algorithm Agility discussion

Mark Andrews <marka@isc.org> Sun, 23 March 2014 18:57 UTC

Return-Path: <marka@isc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820391A09AE for <dane@ietfa.amsl.com>; Sun, 23 Mar 2014 11:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW4eb0aQgTYe for <dane@ietfa.amsl.com>; Sun, 23 Mar 2014 11:57:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AAD0E1A09A9 for <dane@ietf.org>; Sun, 23 Mar 2014 11:57:35 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1B6C2C9468 for <dane@ietf.org>; Sun, 23 Mar 2014 18:57:22 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395601055; bh=NfVtIF26XSyZn30oVNgUxeWM5jGw2m7Gc2n5HiK0GIs=; h=To:From:References:Subject:In-reply-to:Date; b=iYEfs77uaM8/ShzfnE7P3V6aZb7TB3nhBtz9gqwnRag63VYOE84ZuASQstbA31Ocj IvZ+kNaCM+dCX/Iumzeh8fOd+/ebxaEQIKPQ4+wv4V2Nxp5V87buKggAAsbS4weEO+ 4AsciPLNvC4zmVQYCZuOKvl7I0Bowshxjpiqh7wA=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for <dane@ietf.org>; Sun, 23 Mar 2014 18:57:22 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C7C73160060 for <dane@ietf.org>; Sun, 23 Mar 2014 18:58:29 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1B7BD160047 for <dane@ietf.org>; Sun, 23 Mar 2014 18:58:28 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7A84711B2CB8 for <dane@ietf.org>; Mon, 24 Mar 2014 05:57:18 +1100 (EST)
To: dane@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org>
In-reply-to: Your message of "Sun, 23 Mar 2014 18:21:07 -0000." <20140323182106.GX24183@mournblade.imrryr.org>
Date: Mon, 24 Mar 2014 05:57:18 +1100
Message-Id: <20140323185718.7A84711B2CB8@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-sWcg2LuKVxnSRENwTHH0UYmErY
Subject: Re: [dane] Digest Algorithm Agility discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Mar 2014 18:57:37 -0000

In message <20140323182106.GX24183@mournblade.imrryr.org>;, Viktor Dukhovni writ
es:
> On Mon, Mar 24, 2014 at 04:42:05AM +1100, Mark Andrews wrote:
> 
> > Truly, we do not know which of SHA256 and SHA512 will be broken
> > first.  Both are more than strong enough for this job at this point
> > in time.
> 
> Agree with this 100%.
> 
> > When one is broken it will no longer be strong enough.
> > Neither will be broken by brute force.  They will be broken by
> > discoveries of flaws in the algorithms.  We support multiple
> > algorithms so that when/if one is broken we do not end up in a
> > situation of having no trusted algorithms supported.
> 
> I assume that once the SHA3 (aka Keccac) specification is finally
> published by NIST, there will be a DANE-related draft registering
> at least two new matching type algorithms for TLSA records:
> 
>     3	SHA3-256
>     4	SHA3-512
> 
> At that point, a client evaluating a TLSA RRset will have a real
> choice, for example: SHA2-256 vs. SHA3-256.
> 
> The reason the SHA3 competition was held and the Keccac sponge
> construction was selected, is that with MD5 and SHA1 looking broken
> and vulnerable respectively, there was a desire to find new hash
> primitives that are based on new ideas.
> 
> So SHA3 is essentially our insurance policy on further progress
> against the similar SHA1 and SHA2 designs.  While for now progress
> along these lines appears to be stalled, it is not unreasonable to
> admit the *possibility* that it might resume again.
> 
> Initially, clients may be configured to prefer SHA2-256 (which is
> both mandatory to implement and has stood the test of time).  However,
> later if there is any trouble on the SHA2 front, the client can be
> updated to prefer SHA3 (when published by the server) to SHA2.
> 
> The proposed specification provides a transition mechanism with no
> flag day, algorithms can be deprecated (relative to more preferred
> algorithms) without being disabled.
>
> If a server publishes:
> 
> 	SHA2-256
> 	SHA2-512
> 	SHA3-256
> 
> And the client's preference order is (best to worst):
> 
>     SHA3-256,
>     SHA2-512,
>     SHA2-256,
> 
> then the client will only evaluate the TLSA records with SHA3-256 digests
> and if none match, authentication fails.  Today the client can prefer:
> 
> 	SHA2-256,
> 	SHA2-512
> 
> And, since both are currently believed well out of reach of even
> state-funded adversaries, save itself the wasted cycles of computing
> SHA2-512 when both are published.
> 
> The point of Wes's choice "B" is that clients don't have to impose
> a flag on themselves and drop weakened algorithms entirely, given
> that many servers may not be publishing anything stronger.  Instead
> with "B", the client uses the strongest mutually available option.

If you don't trust a algorithm you should not be using it.  Period.
This fall back to this untrusted/broken algorithm is bad engingeering
and bad security practice.

If the site you want to email only has broken TLSA records, get
them on the phone to fix the problem.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org