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

Andrew Sullivan <> Thu, 06 February 2014 04:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C22B81A0367 for <>; Wed, 5 Feb 2014 20:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z3k8m6TKfS0J for <>; Wed, 5 Feb 2014 20:44:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7410D1A0365 for <>; Wed, 5 Feb 2014 20:44:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 22BE08A031 for <>; Thu, 6 Feb 2014 04:44:43 +0000 (UTC)
Date: Wed, 5 Feb 2014 23:44:40 -0500
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 04:44:46 -0000

On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote:
> I must plead ignorance of the obstacle, what do you have in mind?

I am repeatedly informed by my man pages, RFC 3493, and every web
browser implementer I've ever spoken to that getting the TTL on an RR
coming to you from the system resolver is hard.  I'd be more delighted
than I can express to be misinformed, so if you know otherwise please
say so.

There is a new API (more a meta-api) that Paul Hoffman worked on
( that I think we should all embrace
partly for the above reason, but we're not even at 0-day with that yet

> If learning DNS TTLs along with the RRset data is problematic,
> application caches should have reasonably short maximum lifetimes.

I recognise the basic impulse in what you're saying, but it gives me
pause.  Timing attacks involving DNS and the browser "pinning" policy
have always struck me as plausible (and ISTR a demonstration, but I'm
darned if I can come up with it now).  But using this sort of trick
for actual certificate stuff appears to make the target of any
pinning-timing attack more valuable.  Is that a problem?  (That's not
a rhetorical question.  I'm an idiot.)

[I get your other argument about lifetimes.  Not trying to ignore,
just accepting.]


Andrew Sullivan