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

Patrik Fältström <paf@frobbit.se> Fri, 06 March 2015 18:00 UTC

Return-Path: <paf@frobbit.se>
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 EBE1F1A1A7F for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 10:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level:
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 X80hjenjJhaz for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 10:00:09 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D211A1A00 for <ietf@ietf.org>; Fri, 6 Mar 2015 10:00:07 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::9148:8e10:ad61:ffb0] (unknown [IPv6:2a02:80:3ffc:0:9148:8e10:ad61:ffb0]) by mail.frobbit.se (Postfix) with ESMTPSA id 24940205F2; Fri, 6 Mar 2015 19:00:06 +0100 (CET)
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_544BB7E3-DD2C-4DD7-B175-62375EEADD44"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b5
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <707B021F63C5C411E563AE4B@JcK-HP8200.jck.com>
Date: Fri, 6 Mar 2015 19:00:05 +0100
Message-Id: <96DE349B-9F7D-4832-BD34-751123489B70@frobbit.se>
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>
To: John Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/wAWQkvlkct6m1XvKHE6oRYdbkjY>
X-Mailman-Approved-At: Mon, 09 Mar 2015 07:49:59 -0700
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, 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 18:00:10 -0000

> On 6 mar 2015, at 07:14, John C Klensin <john-ietf@jck.com> wrote:
> 
>> One description of
>> a threat model    to DNS, including description of what
>> threats DNSSEC is intended to    defend against can be found
>> in RFC 3833 [RFC3833].
>> 
>>   If for example the URI resource record is not signed with
>> the help of    DNSSEC and validated successfully, trusting the
>> non-signed URI might    lead to a downgrade attack.
> 
> While this may be obvious to experts, the experts probably don't
> need it.  For everyone else, you are probably missing a
> statement about interception, changes to the query or URI, and a
> system that won't respond as intended to STARTTLS or equivalent.
> Note, in particular, that if one started out with:
> 
> 
>  foo.example.com. IN URI 0 0  good.example.com.
> 
> and a query for that produced a response that contained
>  foo.example.com. IN URI 0 0  evil.example.com.
> 
> That would clearly be a problem for DNSSEC but, if both of the
> hosts designated by "good" and "evil" responded to STAETTLS by
> opening TLS connections at desired degrees of security, there
> would be no downgrade attack, "only" a MITM host diversion
> attack.

Well, I to some case disagree and I also thought that that was what Sam pointed out...one wanted to communicate with something at foo.example.com, and if one "normally" did use HTTP over TLS and got a 301 or 302 back, and now instead do a similar change of target with the help of DNS, you do get something very similar at least to a downgrade attack.

But I understand what your point is -- I claim ;-)

   Patrik