Re: [dane] Digest Algorithm Agility discussion
Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 March 2014 20:25 UTC
Return-Path: <viktor1dane@dukhovni.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 DF8641A0223 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 13:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qa0anKg4GmdI for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 13:25:39 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 769A51A0200 for <dane@ietf.org>; Mon, 17 Mar 2014 13:25:39 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 145882AB275; Mon, 17 Mar 2014 20:25:31 +0000 (UTC)
Date: Mon, 17 Mar 2014 20:25:31 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140317202531.GH24183@mournblade.imrryr.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> <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3W-sojbbxvu2clo9OM3idlPS73U
Subject: Re: [dane] Digest Algorithm Agility discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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 20:25:42 -0000
On Mon, Mar 17, 2014 at 12:23:34PM -0700, Paul Hoffman wrote: > Not correct. It allows local policy of any sort. Some local > policies will be "do not use X because it is weak". The language seems to suggest that refusing a digest by local policy does not depend on the set of digests present in the server's TLSA RRset. If we are to fit my proposal into this "local policy" framework, it would be to block all digests except the strongest found for each usage/selector (thus depended on the RRset content). Is such a local policy acceptable within the context of 6698. Note that in Postfix in addition to ignoring all but the "strongest", administrators get to simply ban some digests (which is how I read 6698) "local policy". So my proposal does not contradict 6698 use of local policy to ban digests, but it lifts the mandate to honour all the rest, and replaces with a mandate to honour only the strongest remaining digest from each (usage, selector) pair. > > use of tarnished, but still acceptable digests even when untarnished > > digests are present. > > It does not because that choice is local policy. This boils down to how we define 6698 local policy. My reading was that one may decide to not support some digests, but nothing quite as subtle as pruning the digests dynamically to just the strongest presented by the server. > > 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. It does not specify which is strongest, that is deliberately local policy. It is also local policy which digests to not support even when the server supports nothing better. All it does is refine the 6698 loop to consider at most one (selected by the client using whatever policy it likes) digest algorithm per (usage, selector) combination. > > 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: Is it legal per 6698 to make the set of local policy removed RRs depend on the set of RRs presented by the server? If so, I am specifying a partial local policy, in which: - The set of outright banned digests is not fixed. - The preferences of the remaining digests are not fixed. - Once the client decides what to ban and the order of preferences, it bans all but the strongest TLSA RRs from the server. > > 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. I don't see this as overriding local policy. There is enough rope in the choice of digests to ban and in the preference order of the rest. Those are my definitions of local policy. Local policy can't for example change the structure of the TLSA record, or the meaning of SHA2-256, ... If we fix a more precise algorithm agility protocol, that fixed part ceases to be local policy, but that's OK, there is still local policy for what is not fixed and it is quite sufficient for being able to reject some algorithms and express preferences among the remainder. > 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? I don't. The TLSA record in 6698 employs multiple digest algorithms, I'm specifying an agility protocol for TLSA digest algorithms. Had 6698 specified multiple signature algorithms we'd be talking about those. -- Viktor.
- [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Martin Rex
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Jim Schaad
- Re: [dane] Digest Algorithm Agility discussion (c… Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion (c… Andrew Sullivan
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Scott Rose
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Scott Rose
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker