Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 06 February 2014 17:27 UTC

Return-Path: <eosterweil@verisign.com>
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 1E0671A0176 for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 09:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 B40sdsamKzzh for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 09:27:43 -0800 (PST)
Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58B1A03ED for <dane@ietf.org>; Thu, 6 Feb 2014 09:27:43 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUvPGDopUmUD5hgrsqGZgl19n+tY5ba5p@postini.com; Thu, 06 Feb 2014 09:27:42 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s16HRfMl026524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dane@ietf.org>; Thu, 6 Feb 2014 12:27:41 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 6 Feb 2014 12:27:41 -0500
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: "<dane@ietf.org>" <dane@ietf.org>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAAcv8AgAAHWoCAAAJdAIAAA6QAgAADAACAAJyzgIAANXsA
Date: Thu, 06 Feb 2014 17:27:40 +0000
Message-ID: <EA7C4E13-5F42-4C9E-96BC-FE1DB47ED907@verisign.com>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <A1C41700-578C-45C1-9A66-ACC051970F47@gmail.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <alpine.LFD.2.10.1402052254590.13653@bofh.nohats.ca> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> <20140206045524.GU278@mournblade.imrryr.org> <20140206141615.GW278@mournblade.imrryr.org>
In-Reply-To: <20140206141615.GW278@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ACB8DD6A18D11440988EDD3D8092DEE9@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
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: Thu, 06 Feb 2014 17:27:46 -0000

On Feb 6, 2014, at 9:16 AM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> On Thu, Feb 06, 2014 at 04:55:24AM +0000, Viktor Dukhovni wrote:
> 
>> All I know is that libresolv (used in Postfix) returns the TTL with
>> each RR.  This is only a single data point, so I would not be at all
>> shocked to discover that other stub resolvers are different in this
>> regard, just very mildly surprised.
> 
> OK, I also used the DNS client library in Python once for SRV record
> lookups, and this too returned TTLs.
> 
> Independently of Mark (who beat me to the punch with a more foreceful
> objection), I was also wondering whether perhaps you're misremembering
> the issue.  Without DANE, browsers have no need for explicit DNS
> lookups, they just lookup network address information via getaddrinfo()
> and friends.  So perhaps the issue you had in mind was that
> getaddrinfo() returns no TTLs and no validation status.  This is
> a well known limitation.
> 
> Once applications are doing explicit DNS lookups (SRV, TLSA, ...)
> perhaps TTLs are generally available along with the RRDATA.

To follow all of this up: I think Andrew was illustrating a couple of important issues, and one of them is that we cannot always all rely on full knowledge of how people will adopt DANE processing (look at the TTL, don't look at AD, etc.).  Even if we fully specify how it should be used (only look here, don't look over there, etc.), we still have to be liberal in what we accept.  

Rather than focusing narrowly on how an RP might or might not find SMIMEA RRs, consider an incremental deployment case whereby someone rolls _SOME_ of their constituency over to DANE, and leaves some of their clients on (say) AD.  Now, I need my RPs (the MUAs) to know the difference between ``DANE doesn't want you to use a cert,`` and ``you may go find the cert somewhere else.'' 

IMHO, the TTL discussion is useful because it illustrates that not everyone will even _know_ to go looking for it, but we might want to realize that there are other issues we will have to confront when people consider operational rollouts of this.

Eric