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> Sat, 28 February 2015 22:27 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 64F6A1A0052 for <ietf@ietfa.amsl.com>; Sat, 28 Feb 2015 14:27:38 -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 bI5aOWVRrdsO for <ietf@ietfa.amsl.com>; Sat, 28 Feb 2015 14:27:36 -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 E1D471A0040 for <ietf@ietf.org>; Sat, 28 Feb 2015 14:27:36 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 443423493A5; Sat, 28 Feb 2015 22:27:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F0F51160069; Sat, 28 Feb 2015 22:34:30 +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 82B5F160068; Sat, 28 Feb 2015 22:34:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 51B432A92EE3; Sun, 1 Mar 2015 09:27:33 +1100 (EST)
To: Eliot Lear <lear@cisco.com>
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> <20150224170209.GV1260@mournblade.imrryr.org> <54F03F38.9090601@cisco.com> <1ED9F633-40B1-4A90-85FE-14526C27A485@frobbit.se> <54F043F8.6090409@cisco.com>
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 "Fri, 27 Feb 2015 11:16:24 +0100." <54F043F8.6090409@cisco.com>
Date: Sun, 01 Mar 2015 09:27:32 +1100
Message-Id: <20150228222733.51B432A92EE3@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/WT7bpGQ8HhATh15dTMjUO9xB-TI>
Cc: ietf@ietf.org, Patrik Fältström <paf@frobbit.se>
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: Sat, 28 Feb 2015 22:27:38 -0000

In message <54F043F8.6090409@cisco.com>, Eliot Lear writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --37wX9j2rj3rvIoUsDT9HVLKQlhR047phw
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> On 2/27/15 11:04 AM, Patrik F=C3=A4ltstr=C3=B6m wrote:
> >> On 27 Feb 2015, at 10:56, Eliot Lear <lear@cisco.com> wrote:
> >>
> >> Given a slightly modified example from your document:
> >>
> >>   $ORIGIN example.net.
> >>   _http._web    IN URI 10 1 "httpS://www.example.com/"
> >>
> >> If the intent here is to declare an equivalence between
> >> http://example.com and https://www.example.com the problem is that
> >> absent DNSSEC one is subject to a downgrade attack.  Thus a browser
> >> cannot trust the equivalence.
> > Absolutely!
> >
> > I get that, completely.
> >
> > I wanted to know what is so special about URI that SRV and MX do _not_ =
> have.
> 
> Truthfully I do not think there is a substantial difference, although
> the form of attack varies slightly.
> 
> In the case of MX, the security properties (whether or not to use TLS)
> do not explicitly change, although as you know, Patrik, it is possible
> an attacker could divert someone's email with a low weight MX such that
> STARTTLS is not offered, or if it is offered, it is for another
> certificate.  We have no standard defense to indicate that STARTTLS is
> required at the MX level.

And that is coming "_25._tlsa" and it uses DNSSEC to prevent the
downgrade.  Whether your MTA uses STARTTLS or not is another matter
but we can prevent downgrade attacks from succeeding.

> In the case of SRV the situation is much the same.  You don't specify
> whether to start TLS based on SRV.

With SRV it depends on the protocol using SRV perhaps on concert
with TLSA.  As for the name needed to presented in the TLS negotiation
that depends on the protocol.

> But in the case of URI, if the
> returned URI is intended to contain https: and yet an attacker somehow
> prevents that from happening, no TLS is started.  There is no easy
> workaround for this sort of attack (or the others) because the traffic
> is redirected to a perhaps-faux service.

URI really is the same as MX, SRV, CNAME.  DNSSEC prevents it being
changed / removed.  The rest is up to the protocol that is using it.
Sometimes the original name is used and sometimes the target name
is used.  It also requires the client to do the right things.

For MX we have a single protocol and the leap-of-faith step of the
MX record is cleaned up using DNSSEC.  There more to securing a
SMTP session but that too depends on DNSSEC.

For SRV we have multiple protocols and multiple models.  The
leap-of-faith steps based on the SRV content are cleanup using
DNSSEC.  SRV couldn't possible enumerate all the additional steps
need which is why SRV said that each protocol needs to describe how
to use SRV and retrofits need to document how to use SRV.

URI is similar to SRV.  It is being introduced late.  Existing
protocol need to document how to use it.  New protocols need to
document how to use it.  That usage will vary according to the
protocol.  That said how you secure the contents of the records is
to use DNSSEC.

> DNSSEC: it's not just for breakfast anymore.
> 
> Eliot
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org