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

"Wiley, Glen" <gwiley@verisign.com> Fri, 07 February 2014 02:12 UTC

Return-Path: <gwiley@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 034E61A059A for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 18:12:32 -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 HMSYPnr_kAbj for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 18:12:30 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD0281A0598 for <dane@ietf.org>; Thu, 6 Feb 2014 18:12:28 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUvRBCzdz1d/etgE6tlxHw5HBEJIlqd6A@postini.com; Thu, 06 Feb 2014 18:12:28 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 s172CQnq008226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:12:26 -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 21:12:26 -0500
From: "Wiley, Glen" <gwiley@verisign.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, "dane@ietf.org" <dane@ietf.org>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: AQHPCyZpntlQewVS0Euo6EoCwtd7epp7QbWAgAAPnwCALFghgIAAcv8AgAAHWoCAAAJdAIAAA6QAgAET/IA=
Date: Fri, 7 Feb 2014 02:12:26 +0000
Message-ID: <CF19AA46.34B2B%gwiley@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>
In-Reply-To: <20140206044440.GI21114@mx1.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27986BC63B2447479307ABA4A52C7A56@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: Fri, 07 Feb 2014 02:12:32 -0000

On 2/5/14 11:44 PM, "Andrew Sullivan" <ajs@anvilwalrusden.com> 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
>ajs@anvilwalrusden.com

-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.