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

"Osterweil, Eric" <> Thu, 06 February 2014 17:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E0671A0176 for <>; Thu, 6 Feb 2014 09:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B40sdsamKzzh for <>; Thu, 6 Feb 2014 09:27:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D58B1A03ED for <>; Thu, 6 Feb 2014 09:27:43 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 06 Feb 2014 09:27:42 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s16HRfMl026524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Thu, 6 Feb 2014 12:27:41 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Thu, 6 Feb 2014 12:27:41 -0500
From: "Osterweil, Eric" <>
To: "<>" <>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Date: Thu, 6 Feb 2014 17:27:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Feb 2014 17:27:46 -0000

On Feb 6, 2014, at 9:16 AM, Viktor Dukhovni <> 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.