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

Mark Andrews <marka@isc.org> Tue, 24 February 2015 22:00 UTC

Return-Path: <marka@isc.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 874651A903E for <ietf@ietfa.amsl.com>; Tue, 24 Feb 2015 14:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vHU_brwoHr9P for <ietf@ietfa.amsl.com>; Tue, 24 Feb 2015 14:00:51 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731171A9038 for <ietf@ietf.org>; Tue, 24 Feb 2015 14:00:51 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 2AC053493BB for <ietf@ietf.org>; Tue, 24 Feb 2015 22:00:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9D740160068 for <ietf@ietf.org>; Tue, 24 Feb 2015 22:07:44 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 6363C160052 for <ietf@ietf.org>; Tue, 24 Feb 2015 22:07:44 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6E5922A46A9D for <ietf@ietf.org>; Wed, 25 Feb 2015 09:00:45 +1100 (EST)
To: ietf@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20150127223859.28024.43756.idtracker@ietfa.amsl.com> <4257D8A3-0EFE-40E3-B0AD-8E23772B7693@mnot.net> <6F9BB11D-C224-4D7B-A06C-41EACBAAB4B2@netnod.se> <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
In-reply-to: Your message of "Tue, 24 Feb 2015 17:26:49 -0000." <20150224172649.GX1260@mournblade.imrryr.org>
Date: Wed, 25 Feb 2015 09:00:44 +1100
Message-Id: <20150224220045.6E5922A46A9D@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/74tIGxv8JZ83hJCcDfyf9kE1Isg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 24 Feb 2015 22:00:56 -0000

In message <20150224172649.GX1260@mournblade.imrryr.org>rg>, Viktor Dukhovni writes:
> On Tue, Feb 24, 2015 at 08:49:29AM -0800, Paul Hoffman wrote:
> 
> > On Feb 23, 2015, at 8:33 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
> > > Yes, I see significant security problems with this URI.
> > 
> > It sounds like you have issues with URIs in general, not in a DNS RTYPE
> > that carries a URI. That is, any URI that has a domain name that can lead
> > to redirection (though CNAME, DNAME, or SRV) would have the properties
> > that worry you. It that a fair summary?
> 
> That's not how I read it.  The issue here is that the draft introduces
> a DNS-based rewrite of the TLS reference identifier.
> 
> 	_mumble.example.com. IN URI "https://example.net/"
> 
> The draft language stipulates (correctly I think given that DNS
> also specifies the URI scheme) that DNSSEC is required and the TLS
> reference identifier becomes "example.net".  This is not the case
> for HTTP with either CNAME or DNAME, and HTTP does not use SRV
> records.
> 
> When pre-DANE MTAs use MX records with TLS securely (rather than
> just going through the motions), they use the nexthop domain (not
> the MX host domain) as the reference identifier.
> 
> Similar considerations come into play with RFC 6186 indirection of
> IMAP and SMTP server locations.  RFC 6186 just drops the ball in
> the user's lap.  A more comprehensive solution is hinted at in:
> 
>     http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-7
> 
> but I'm not sure where we are whether DNSSEC last-mile is as yet
> sufficiently addressed for that.

DNSSEC works all the way to the application.  This has been specified
for approaching a decade now (March 2005).  Yes, RFC 4035 covers
how to do DNSSEC in the application.  Yes it is a myth that the last
mile requires something special.  It doesn't.

Validating nameservers are a example of a *application* that validates
answers received from nameservers.  Yes, nameserver are configured
to to talk through recursive nameservers and to validate the answers
they get.

The code to do this exists in libraries which can be called from
applications other than nameservers.  Named is just a application
that calls libdns to do most of its work.

> Of course with the document under discussion, if mobile applications
> are in scope, then of course we again need DNSSEC to be usable in
> last-mile environments.
> 
> -- 
> 	Viktor.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org