Re: [dane] Digest Algorithm Agility discussion

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 17 March 2014 19:23 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 2FFAA1A0492 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 12:23:49 -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 kbeXdXVYs41P for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 12:23:47 -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 D58261A0488 for <dane@ietf.org>; Mon, 17 Mar 2014 12:23:47 -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 s2HJNbtu035483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Mon, 17 Mar 2014 12:23:38 -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: <20140317182219.GF24183@mournblade.imrryr.org>
Date: Mon, 17 Mar 2014 12:23:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org>
References: <20140315051704.GY21390@mournblade.imrryr.org> <alpine.LFD.2.10.1403171115580.32251@bofh.nohats.ca> <20140317155049.GB24183@mournblade.imrryr.org> <B4473EDA-DAB4-4CC2-ACCD-B4F8939E5A2C@vpnc.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> <20140317182219.GF24183@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5PoqSDEtqL3W-nWEy7TGMd2bD74
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 19:23:49 -0000

On Mar 17, 2014, at 11:22 AM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> On Mon, Mar 17, 2014 at 11:14:32AM -0700, Paul Hoffman wrote:
> 
>>> There is no text in 6698 that even approximately suggests that clients
>>> get to use only the records with the strongest (local criteria) digest.
>> 
>> In Section 4.1:
>>   o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
>>      as a certificate association for TLS unless a local policy would
>>      prohibit the use of the specific certificate association in the
>>      secure TLSA RRSet.
> 
> This is not "use strongest".  

Correct.

> This is the opposite.

Not correct. It allows local policy of any sort. Some local policies will be "do not use X because it is weak".

>  It forces the
> use of tarnished, but still acceptable digests even when untarnished
> digests are present.  

It does not because that choice is local policy.

> The new proposal is to ignore all but the
> strongest, even when the remainder would be usable.

That new proposal mandates a view of "strongest". Local policy should still trump that mandate.

> Also the pseudo-code in the appendices loops over *all* "usable" TLSA
> RRs (those not banned by 4.1).  

Correct. And RRs that are prohibited by local policy have already been removed:
   for each R in TLSArecords {
     // unusable records include unknown certUsage, unknown
     // selectorType, unknown matchingType, erroneous RDATA, and
     // prohibited by local policy
     if (R is unusable) {
       remove R from TLSArecords
     }
   }

> My proposal modifies the pseudo-code
> to loop over only those records (for each usage/selector) with the
> strongest digest plus any records with matching type 0.

Over-riding local policy is a non-starter, at least in my opinion.

Also: your focus on digests is possibly misplaced; why do you believe that a digest is more likely to be tarnished than a signature algorithm itself?

--Paul Hoffman