Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

Nicholas Weaver <nweaver@icsi.berkeley.edu> Fri, 21 February 2014 16:25 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 D8BF31A01F1 for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 08:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 dMpvDoQ9a1_H for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 08:25:05 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E77041A0170 for <dane@ietf.org>; Fri, 21 Feb 2014 08:25:05 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 100342C4047; Fri, 21 Feb 2014 08:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N9C5M1x2YVvy; Fri, 21 Feb 2014 08:24:59 -0800 (PST)
Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 15B7C2C400A; Fri, 21 Feb 2014 08:24:59 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C20B6DAC-7A29-42D4-AE82-32DD5EBFDE4F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <alpine.LFD.2.10.1402211058100.3311@bofh.nohats.ca>
Date: Fri, 21 Feb 2014 08:24:58 -0800
Message-Id: <C1C1A822-F92E-4BFE-84CD-F747DF01F781@icsi.berkeley.edu>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org> <CAMm+LwiDQwPy0uj4ja=ngnwuAzqNLC28JV=4hk-Bu5F8UTdX8A@mail.gmail.com> <DE057EDD-22E0-4268-8C81-A276761C0F97@icsi.berkeley.edu> <alpine.LFD.2.10.1402211058100.3311@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WGJyuvqIx_XH11eNDk37PZEzlvY
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
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, 21 Feb 2014 16:25:08 -0000

On Feb 21, 2014, at 7:59 AM, Paul Wouters <paul@nohats.ca> wrote:

> On Fri, 21 Feb 2014, Nicholas Weaver wrote:
> 
>> The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal.
> 
> huh? If I put a 9999999 rrsig timeout on my TLSA signature, once you
> fetched it, it is pretty irrelevant that somewhere upstream an rrsig
> expired.
> 
> Are you suggesting resolvers should throw away chains of dns from the
> cache once a single rrsig expires?

F-yeah.  An RRSIG's validity interval should not extend beyond the validity interval of all RRSIGs needed to validate this RRSIG.  DNSSEC does not have a revocation mechanism, but in lieu of a revocation mechanism you have the much more limited validity of RRSIGs, and if the upstream authority says your DS record expires in an hour, why should you be able to override that policy?



But even if thats not the case, an non-DNS server which provides the data on demand, namely a full validation chain, needs to treat things this way, as it would not be able to provide a valid-at-the-time RRSIG: yeah, your 9999999 RRSIG might still be valid, but the captured RRSIG for the DS from the authority server also needs to be valid when it is presented to the client.


So lets take a real world case, www.isc.org:

Record		Expires
DS org		2014-02-28-000000
DNSKEY org	2014-03-10-155510
DS isc.org	2014-03-10-155510
DNSKEY isc.org	2014-03-19-230128
A www.isc.org	2014-03-19-233241

A non-DNS server which is providing a DNSSEC validation chain for www.isc.org needs to be aware of all these expiration times: there are at least 3 (and possibly 4) separate expiration intervals, all with different phase to boot.

And I'd expect the expiration times for DNSSEC records to go down, rather than up, as people realize that online signing offers some significant advantages operationally (dynamic NSEC3 lies, quick reacting DNS load balancing, etc) and the cost of online signing may have been expensive 10 years ago but is nearly free today.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc