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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 27 February 2015 09:24 UTC

Return-Path: <ietf-dane@dukhovni.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 07FE31A9175 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 01:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6] 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 3xsojL8XXcLx for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 01:24:31 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FFF1A9238 for <ietf@ietf.org>; Fri, 27 Feb 2015 01:24:23 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 45E0B282FC0; Fri, 27 Feb 2015 09:24:22 +0000 (UTC)
Date: Fri, 27 Feb 2015 09:24:22 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <20150227092422.GU1260@mournblade.imrryr.org>
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> <tsla901akgu.fsf@mit.edu> <16ABF6B9-F113-4A1F-8816-EE041CCF4C4B@frobbit.se> <20150227075813.GT1260@mournblade.imrryr.org> <1279CB63-FBF5-4839-B685-4EE1C6B7FD3D@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1279CB63-FBF5-4839-B685-4EE1C6B7FD3D@frobbit.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Im3I_vkcN5TBq_Npx23rJili-94>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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 09:24:33 -0000

On Fri, Feb 27, 2015 at 09:41:42AM +0100, Patrik F?ltstr?m wrote:

> So the difference for MX is that the MX model using TLS is wrong.

Specifically, absent DNSSEC+DANE, it is unwise to assume that much
if any security against active attacks results from using the MX
hostname as a peer identity attested via Web PKI CAs.

> Then SRV, can you explain that?
> 
> http://example.com/
> 
> Lookup of SRV for _web._tcp.example.com

Again "nobody" does that for HTTPS (well none of the browsers or
typical web client toolkits do).  Of course someone is probably
doing it some dark corner of the Internet, but they lose all the
usual security properties of TLS (unless they are also doing DNSSEC
+ DANE in this case).  

Plus SRV records don't specify a URI scheme, which can potentially
change the client's security expectations.

SRV records are used for LDAP lookups, often with GSSAPI auth, and
Microsoft (for example) gets it right in creating special principals
for the LDAP servers:

    ldap/<target-fqdn>/<service-domain-fqdn>@REALM

allowing clients to check that the target of the SRV record.
Admittedly GSSAPI often plays out behind enterprise firewalls,
where a lot more insecure DNS redirection is often tolerated than
might be wise on the public Internet.

There is a proposal in RFC 6186 to use SRV records for MUAs
discovering the appropriate IMAP service for their domain.  This
RFC predates DANE, and as I said "drops the ball on the user's lap"
by requiring the user to confirm the redirection.  Even the UTA
DEEP draft does not fully address that issue, thought makes a step
or two in the right direction.

It sure looks like everyone is still rather hesitant around DNSSEC.

> Get back for example 8080 example.net
> 
> http://example.net:8080/
> 
> What I am trying to understand is the _difference_ between URI and MX/SRV which was what Sam said there was.

Applications that use SRV records with TLS, see:

    https://tools.ietf.org/html/draft-ietf-dane-srv

generally use the service domain (not target host) as the reference
identifier, unless they are luck enough to support DNSSEC and DANE
and find a TLSA record for the target host (which was obtained via
a "secure" SRV RRset).

HTTP clients that do TLS, don't do SRV records, or don't understand
the security implications.  All I'm saying is that the security
implications are non-trivial and need discussion.

-- 
	Viktor.