Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 06 March 2015 09:05 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698D61ACD3C for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 01:05:09 -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 R66RFyymfVbr for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 01:05:07 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCB41ACD30 for <ietf@ietf.org>; Fri, 6 Mar 2015 01:05:07 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 21475282FC0; Fri, 6 Mar 2015 09:05:06 +0000 (UTC)
Date: Fri, 6 Mar 2015 09:05:06 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <20150306090505.GS1260@mournblade.imrryr.org>
References: <54F09A35.9060506@qti.qualcomm.com> <54F78650.6070503@qti.qualcomm.com> <20150305064513.GH1260@mournblade.imrryr.org> <54F7FE09.3030200@cisco.com> <7111545C27DE9021135BE185@JcK-HP8200.jck.com> <tslegp3o0zn.fsf@mit.edu> <6FC72D10-6AF2-4F84-B1AC-27F5B7E632AC@frobbit.se> <707B021F63C5C411E563AE4B@JcK-HP8200.jck.com> <93DFD15D-4ED3-4FEE-B26B-F6578459137D@frobbit.se> <F03661F9CDFC6686BF2AE425@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F03661F9CDFC6686BF2AE425@JcK-HP8200.jck.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dAlfx7K2YUrshYogT7KBqmwwKhA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2015 09:05:09 -0000

On Fri, Mar 06, 2015 at 02:28:44AM -0500, John C Klensin wrote:

> That said, if the IETF considers it to be a valid implementation
> of DNSSEC to have the closest-to-user validating system be an
> ISP-based forwarder rather than a machine on the user's LAN,
> there isn't a lot of point in building DNSSEC capability into
> zeroconf stuff that is mostly applicable intra-LAN or otherwise
> within a trust perimeter that the DNSSEC validator is outside of.

Where did this notion come from?  I've seen no documents that
suggest this.  On the contrary, there is even some push back to
using a security-aware non-validating stub resolver that chains to
a trusted loopback-net validating cache.  *Trusting* the ISP's
validating resolver is indeed pointless and I've not seen anyone
suggest this.

If grandma had wheels, she'd be a wagon.

Of course once can still *use* an ISP's validating resolver as an
untrusted cache, with or without "CD" as appropriate.

> Put differently, any time a DNSSEC-based trust model comes down
> to "trust your ISP", then it is pointless overhead for any of us
> who already know our ISPs can't be trusted.  And _that_ is why
> I'm reluctant to see it oversold in circumstances like the
> current document.

In any case nobody's suggesting over-selling DNSSEC here, all the
suggested changes have been about the claims for DNSSEC being
originally too strong.

Nevertheless if a URI RR is to be trusted to change the authenticated
authority (RFC6125 reference identifier), then one should at least
do DNSSEC or else (when DNSSEC is not fit for purpose) not change
the authority (and fail authentication when the target's certificate
fails to match the original domain).  In the latter case complications
may arise with SNI (which domain goes in the client's SNI extension
and may it differ from the HTTP request Host: header?).

All the document has to do is avoid claiming that trusting DNSSEC
is *equivalent* to trusting the application's "usual" PKIX
trust-anchors (whatever they might be).  Sometimes DNSSEC is worse,
sometimes it is better.  It should also caution against accepting
completely unauthenticated redirection, so given that the redirection
is via DNS you either use DNSSEC or don't trust the redirection
choose one.

Nothing controversial, just basic tautologies that may not be
obvious to all.

-- 
	Viktor.