Re: [dane] Digest Algorithm Agility discussion

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 17 March 2014 16:48 UTC

Return-Path: <paul.hoffman@vpnc.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 1FFFC1A0427 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 09:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 6IvExfgt14VN for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 09:47:58 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCD1A006F for <dane@ietf.org>; Mon, 17 Mar 2014 09:47:58 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2HGlllE029644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Mon, 17 Mar 2014 09:47:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20140317155049.GB24183@mournblade.imrryr.org>
Date: Mon, 17 Mar 2014 09:47:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4473EDA-DAB4-4CC2-ACCD-B4F8939E5A2C@vpnc.org>
References: <20140315051704.GY21390@mournblade.imrryr.org> <alpine.LFD.2.10.1403171115580.32251@bofh.nohats.ca> <20140317155049.GB24183@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tehhNTQq7NcwRw7q_dk4DcqLoiI
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: Mon, 17 Mar 2014 16:48:00 -0000

This discussion comes up in every security WG. The proposal tries to help a client who wants to always use the strongest algorithm without actually having to understand why a different algorithm is weaker. This makes the semantics pretty intractable.

On Mar 17, 2014, at 8:50 AM, Viktor Dukhovni <viktor1dane@dukhovni.org>; wrote:

> On Mon, Mar 17, 2014 at 11:26:58AM -0400, Paul Wouters wrote:
> 
>> On Sat, 15 Mar 2014, Viktor Dukhovni wrote:
>> 
>>> Goal:
>>> 
>>>  * It should be possible for servers to publish TLSA records
>>>    employing multiple digest algorithms allowing clients to
>>>    choose the best mutually supported digest.
>> 
>> Isn't that already possible?
> 
> Not based on RFC 6698 alone.  With RFC 6698 the client trusts all
> TLSA records whether "weak" and "strong".

Can you point to the specific text for that? It was not my intention, and I doubt it was the intention of the WG.

> My proposal is essentially the same.  The client uses the strongest
> acceptable digest algorithm.  The *client* decides what "strongest"
> means.  It never chooses an unsupported algorithm.

Again, that was at least my intention for 6698. If we need to clarify that, that would be much better than adding another layer of protocol grease.

>> If a certain digest is so weak it is basically broken, it should not be
>> left in a published TLSA record.
> 
> Weak digests (say SHA2-256 if/when broken) cannot be easily removed
> from RRsets until all clients support stronger ones.  The idea is
> to publish stronger digests and deploy stronger clients, then remove
> weak digests later.  

Yes.

> Stronger clients will never use the published
> weak records.  

I strongly doubt that is the desired outcome. If so, lots of zones will go invisible when the "later" in "remove weak digests later" stretches to a decade.

Instead, a stronger client can have a setting that says "I'm going to abort when seeing a weaker digest, and I will alert you". The latter part is important.

> Otherwise there's an Internet-wide flag-day.

Which will never happen, so bringing it up is just hyperbole.

>> If the most prefered TLSA record fails validation, the client should try
>> another TLSA record.
> 
> This works poorly.  While the weak algorithm is being phased out
> (years) even clients that support stronger algorithms are at risk.

At risk of what? Seriously: DANE is additional security over non-TLS, so a "weak" algorithm is still better than "no TLS". Reduction to absurdity is not helpful here.

>> Perhaps there is text in the DS record RFC to look at that describes
>> this better than I just did.
> 
> Perhaps Wes can chime in.  His comment to me was that the proposed
> DAA (digest algorithm agility) is essentially the only possible
> and largely analogous to the DNSSEC approach.

I believe he is talking about RFC 6975. I do not believe that it attracted any significant interest.

--Paul Hoffman