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

Nico Williams <nico@cryptonector.com> Fri, 06 March 2015 15:05 UTC

Return-Path: <nico@cryptonector.com>
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 83EB51A0126 for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.043
X-Spam-Level:
X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 VvGC0fJAiVVf for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:05:45 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2434D1ACE63 for <ietf@ietf.org>; Fri, 6 Mar 2015 07:05:36 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id E1B20350082 for <ietf@ietf.org>; Fri, 6 Mar 2015 07:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zIrIDvWypczWLg7wOk8W VIAL6Hc=; b=yVa/85pw6VhWdIMvbjTCuurp/OCqzGrRKlb0ukzbE6l78rN9jJ9k H4lyqKE54O6JktMMz/xxFvmuhahGfNQFBEHP5PXXAYFxP6hNVrnstOONsOPevMXw iVXt+0uaMdzMjptR8YpKkZ/xW1vsoSLlzSjNNC5a2CfunYy4oOxDz2Q=
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id CB67A35005B for <ietf@ietf.org>; Fri, 6 Mar 2015 07:05:35 -0800 (PST)
Received: by iebtr6 with SMTP id tr6so12912416ieb.2 for <ietf@ietf.org>; Fri, 06 Mar 2015 07:05:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.171.170 with SMTP id av10mr54727770igc.28.1425654334974; Fri, 06 Mar 2015 07:05:34 -0800 (PST)
Received: by 10.64.130.66 with HTTP; Fri, 6 Mar 2015 07:05:34 -0800 (PST)
In-Reply-To: <F03661F9CDFC6686BF2AE425@JcK-HP8200.jck.com>
References: <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org> <tslvbircj0d.fsf@mit.edu> <0325DF3F-17F3-4400-BDEA-EDB5334BF35C@frobbit.se> <20150225180227.GT1260@mournblade.imrryr.org> <7AB921D35A7F9B23A53BD11A@JcK-HP8200.jck.com> <tslvbip8io6.fsf@mit.edu> <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>
Date: Fri, 6 Mar 2015 09:05:34 -0600
Message-ID: <CAK3OfOhFxsvn29+QneGCCGcbMSv9CMYaUKsXRfDDQ5QVO8ViXw@mail.gmail.com>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
From: Nico Williams <nico@cryptonector.com>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary=089e0111c0783589180510a00472
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/jz1XgzQNfGjptY0sFIcGPHm3-CM>
X-Mailman-Approved-At: Fri, 06 Mar 2015 08:09:53 -0800
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, "ietf@ietf.org" <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@frobbit.se>, Mark Nottingham <mnot@mnot.net>, Sam Hartman <hartmans-ietf@mit.edu>
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: Fri, 06 Mar 2015 15:05:47 -0000

That's mDNS, which is not the DNS, just an insecure local discovery
protocol based on DNS wire messages.  Surely mDNS is out of odd scope here.

Nico

On Friday, March 6, 2015, John C Klensin <john-ietf@jck.com>; wrote:

>
>
> --On Friday, March 06, 2015 07:28 +0100 Patrik Fältström
> <paf@frobbit.se <javascript:;>> wrote:
>
> > Thanks for the comments. While digesting them, I have one
> > comment:
> >
> >> On 6 mar 2015, at 07:14, John C Klensin <john-ietf@jck.com
> <javascript:;>>
> >> wrote:
> >>
> >> Generally, while I think you should warn that URI records may
> >> cause some risks that do not exist with, e.g., conventional
> >> name to address mappings (note that the "downgrade attack or
> >> not" considerations above would apply equally well to:
> >>
> >>  foo.example.com.  IN A 10.2.0.44
> >> being diverted into a response of
> >>  foo.example.com.  IN A 10.0.0.6
> >>
> >> (which would be, historically, a likely upgrade attack, but it
> >> has nothing to do with URI records but is equally preventable
> >> by an integrity check.))
> >>
> >> As long as there is a warning, I really don't care very much
> >> what you say, but whatever you do say should be as accurate as
> >> possible.
> >
> > I also see tons of zeroconf stuff (Apple Bonjour) using DNS
> > already today in the geographically local context without much
> > DNSSEC.
>
> I think that strengthens the argument for some Applicability
> Statement action about DNS-related threats, trust models, and
> attacks that integrity checks do or do not protect against
> rather than trying to push too much off on this particular
> document.  I still don't have a strong opinion about where the
> optimal boundaries lies, but I don't think it is rational for
> the IETF to not do the A/S work but then hold up individual
> documents because they don't contain all of the discussion that
> A/S might contain.
>
> 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.
>
> 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.
>
>     john
>
>