Re: [dane] Digest Algorithm Agility discussion

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 17 March 2014 18:14 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 2CD6A1A0488 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 11:14:46 -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 TV8n2FiZXXSU for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 11:14:44 -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 A33161A048D for <dane@ietf.org>; Mon, 17 Mar 2014 11:14:44 -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 s2HIEYDK032984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Mon, 17 Mar 2014 11:14:35 -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: <20140317174423.GE24183@mournblade.imrryr.org>
Date: Mon, 17 Mar 2014 11:14:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@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>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TQ-cJxId3Fa2rglzeRnru5mYWe4
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 18:14:46 -0000

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

> On Mon, Mar 17, 2014 at 09:47:46AM -0700, Paul Hoffman wrote:
> 
>>>>> * 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.
> 
> Per RFC 6698, the client evaluats all "usable" TLSA records until
> one matches, regardless of digest algorithm strength.

Umm, I asked for specific text. :-) If it is in Section 4.1 (which is where it should be), I'm not seeing it.

>>> 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.
> 
> 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.
And at the end of Section 8:
   Generators of TLSA records should be aware that the client's full
   trust of a certificate association retrieved from a TLSA record may
   be a matter of local policy.  While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may decline to accept the certificate (for reasons
   such as weak cryptography), as is also the case with PKIX trust
   anchors.

Crypto choice is definitely a local policy.

--Paul Hoffman