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

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 06 February 2014 04:55 UTC

Return-Path: <viktor1dane@dukhovni.org>
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 2A9841A029D for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 20:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NVTNwzOGqb2g for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 20:55:26 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id F2E941A0277 for <dane@ietf.org>; Wed, 5 Feb 2014 20:55:25 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F0D6C2AB243; Thu, 6 Feb 2014 04:55:24 +0000 (UTC)
Date: Thu, 6 Feb 2014 04:55:24 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140206045524.GU278@mournblade.imrryr.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140206044440.GI21114@mx1.yitter.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
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
Reply-To: dane@ietf.org
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 04:55:28 -0000

On Wed, Feb 05, 2014 at 11:44:40PM -0500, Andrew Sullivan 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.

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.

Thanks for the eye-opener.

> 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.  

I'll endeavor to take a look once I am not swamped trying to get
the SMTP draft out the door.

> > 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.]

Agreed, somewheere underneath all of our security models there are
basic questions like the security of a system clock aggressively
synced with remote NTP servers.  Ensuring integrity at boot time
requires care to seed the PRNG properly, avoid clock rollback
attacks, ...

When designing reusable components, we can only try to do the right
thing at each layer, and hope it all fits together.  Building a complete
secure system requires a separate big-picture analysis.

-- 
	Viktor.