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

Sam Hartman <hartmans-ietf@mit.edu> Fri, 27 February 2015 15:19 UTC

Return-Path: <hartmans@mit.edu>
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 12BC61ACD4A for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 07:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 oJtE3n_0jAKT for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 07:19:03 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DDB1ACD47 for <ietf@ietf.org>; Fri, 27 Feb 2015 07:19:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 66F6A20608; Fri, 27 Feb 2015 10:17:53 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIr6HzUjpRBd; Fri, 27 Feb 2015 10:17:53 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 27 Feb 2015 10:17:52 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9BC9987131; Fri, 27 Feb 2015 10:18:30 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Eliot Lear <lear@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
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> <tsl7fv35sez.fsf@mit.edu> <54F0832A.4000409@cisco.com>
Date: Fri, 27 Feb 2015 10:18:30 -0500
In-Reply-To: <54F0832A.4000409@cisco.com> (Eliot Lear's message of "Fri, 27 Feb 2015 15:46:02 +0100")
Message-ID: <tslzj7z4c3d.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/-QOG2BYIp1PDjFpaiVCMVmlJIUk>
X-Mailman-Approved-At: Fri, 27 Feb 2015 08:12:19 -0800
Cc: Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, Patrik =?utf-8?B?RsOkbHRzdHI=?= =?utf-8?B?w7Zt?= <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: Fri, 27 Feb 2015 15:19:05 -0000

>>>>> "Eliot" == Eliot Lear <lear@cisco.com> writes:


I don't understand your statement.  What's a decision process?

Your DNS libraries definitely have a different trust validation process
than your application TLS libraries.
Your application is probably not entirely aware of its use of DNS;
that's how we write apps today.

Let's take a concrete example.
I felt greate unease when I heard Patrik talk about getting support for
the URI record added to libcurl.

Imagine that's done, and by default libcurl will follow a URI RR
redirection if it's DNSSec validated.

I am using libcurl to talk to some cloud service.
I've carefully configured libcurl's TLS parameters because I know
exactly what I'm expecting.
Let's say that I've done so in a way that's site specific.
If libcurl is fetching the URI https://cloud.example.com/ then my
validation rules apply.
(I believe that libcurl has sufficiently rich callback interfaces to
support this, but I get the various HTTP library capabilities confused)


I have a fairly strict set of trust anchors for that URI because I know
exactly what to expect.

however, an attacker has managed to steal example.com's DNS registry
account password and has compromised their zone.
With a version of libcurl that  does not support the URI rr, my
application is vulnerable to a denial of service attack if they mess up
the  DNS zone, but I am not vulnerable to an attack on integrity of my
interactions with the cloud services.

However, now that libcurl follows the URI RR, since the attacker has
compromised example.com's DNS zone, they can now redirect me elsewhere.
And since the URI RR draft specifies we're going to do our TLS
validation based on the target of the redirection rather than the
source, my validation rules for cloud.example.com no longer apply, and
so my security is likely weak enough to attack if the attacker can get a
cert for a domain controlled by the attacker.

OK, so perhaps libcurl should not default to following URI RR redirects.
Fine.  But we as standards authors need to help application authors
understand the implications of turning on the URI RR.  You probably
don't want to follow URI RR if you're supplying a non-default TLS trust
anchor set, pinning to a specific certificate or the like unless you're
somehow supplying specific acceptable DNSSec trust anchors for the zones
in question and not trusting the root trust anchor.  Note, however that
application TLS libraries ar much more customizable in their validation
than application-layer DNSSec libraries.  In practice TLS allows
application security policy to be specified, but DNSSec seems to use one
global security policy.  I understand that's not inherent in the
standards, although the way the two standards are written does
contribute to it.  It does seem true in the code for TLS and DNSSec I'm
aware of, and it is to the best of my understanding a practical reality
for authors of applications.