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> Wed, 25 February 2015 09:48 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 1BD1C1A6EF1 for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 01:48:05 -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 dyjA-2XsJFGZ for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 01:48:03 -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 A0D971A0318 for <ietf@ietf.org>; Wed, 25 Feb 2015 01:48:02 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::22] (unknown [IPv6:2a02:80:3ffc::22]) by mail.frobbit.se (Postfix) with ESMTPSA id C76872026C for <ietf@ietf.org>; Wed, 25 Feb 2015 10:48:00 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_BE1B87B4-3632-4A92-91A3-0C72DCFDC3AE"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
X-Pgp-Agent: GPGMail 2.5b5
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <20150224220045.6E5922A46A9D@rock.dv.isc.org>
Date: Wed, 25 Feb 2015 10:48:00 +0100
Message-Id: <C1AD051B-0CD3-4CEC-B578-7AE2E6A0BF46@frobbit.se>
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> <20150224220045.6E5922A46A9D@rock.dv.isc.org>
To: IETF Disgust <ietf@ietf.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/eDFk8Fnx4pDly2UTDF4VVQKqKRM>
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: Wed, 25 Feb 2015 09:48:05 -0000

Security issues related to URL resolution is as we all know complicated.

We do DNS lookup, and we do HTTP requests.

Redirect (equivalents) can happen in either.

We have various security mechanisms for both.

The ultimate solution that the IETF work with is that one have DNSSEC that covers everything we get from DNS, it is validated positively, and TLS session is used, and with the help of DANE the certificate is trusted and in turn the DN in the cert is compared with the host connected to.

Now, this is not deployed yet.

Today I claim the normal mechanism is:

1. Take URL

2. Lookup A/AAA without DNSSEC validation

3. Open HTTP connection and fetch data

What we are moving towards is to start with, which happens now and then:

1. Take URL

2. Lookup A/AAA with DNSSEC validation in a trusted resolver (not locally)

3. Open HTTP connection and fetch data

4. Get a redirect to the TLS version of the site

5. Open TLS connection, validate DN in cert with host, and local root cert

In this example, we have a few weak issues:

A. Trust resolver that do the validation
B. Get a redirect from non-TLS protected connection
C. The CA validation chain

With URI we get:

1. Take URL

2. Lookup URL RR with DNSSEC validation in a trusted resolver (not locally)

3. Lookup A/AAA with DNSSEC validation in a trusted resolver (not locally)

4. Open HTTP connection and fetch data

5. Get a redirect to the TLS version of the site

6. Open TLS connection, validate DN in cert with host, and local root cert

Now, we want to improve this even more, and get ultimately (if one use URI):

1. Take URL

2. Lookup URL RR with DNSSEC validation and do local validation

3. Lookup A/AAA with DNSSEC validation and do local validation

4. Open TLS connection, validate DN in cert grabbed with DANE (using DNSSEC and local validation) with host


So yes, of course there are weaknesses in a URI RR if one does not validate the response from DNS (directly or indirectly by trusting the validator). Just like one must trust the redirect in HTTP by validating cert used for TLS in a proper way. Both when DANE is in use requires proper DNSSEC signatures.

   Patrik