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

["Wiley, Glen" <[e-mail]>]

On 2/5/14 11:44 PM, "Andrew Sullivan" <[e-mail]> wrote:

>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
>(http://www.vpnc.org/getdns-api/) that I think we should all embrace
>partly for the above reason, but we're not even at 0-day with that yet
>AFAICT.  

We are very close to "0-day" for getdns :)

A few of us (NLNetLabs and Verisign) have been working on an open source
Implementation of the specification that we are planning to release prior
to IETF89.

The API provides pretty complete access to the RR data and includes
DNSSEC validation.  Per the spec the API can be used as a stub
Resolver (as with extant libc entry points) or as a recursive
Resolver (the default behavior per the spec).

>
>> 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.]
>
>A
>
>-- 
>Andrew Sullivan
>[e-mail]

-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.