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 <> Fri, 27 February 2015 09:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B16FF1A020B for <>; Fri, 27 Feb 2015 01:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.761
X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VI9ge6n-y8Uu for <>; Fri, 27 Feb 2015 01:46:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46C711A1B43 for <>; Fri, 27 Feb 2015 01:46:03 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::22] (unknown [IPv6:2a02:80:3ffc::22]) by (Postfix) with ESMTPSA id 6D6921FF86 for <>; Fri, 27 Feb 2015 10:46:01 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_06B33EE4-F62D-43F1-9B30-EA5895C6C181"; 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?= <>
In-Reply-To: <>
Date: Fri, 27 Feb 2015 10:41:28 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Feb 2015 09:46:06 -0000

> On 27 Feb 2015, at 10:24, Viktor Dukhovni <> wrote:
> 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?
>> Lookup of SRV for
> 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).

I understand that part, but for me (maybe wrongly) I think "badly designed RR Type" is a different argument than "SRV is different from URI". If both are crap, then I understand :-)

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

Ok, got it! Thanks!

> 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.

Yeah, for some for me weird reason...

"Just do it!"

I am btw also of the view that DNSSEC is so darn important that I think having validation in (the trusted) recursive resolver one uses is better than using the current CA/X.509 PKI. Sure, local validation in application is much much better, but I rather have/use DNSSEC with validation in recursive resolver than no DNSSEC.

I.e. if I do not trust the zeroconf we have today, then I am sort of toast anyways.

>> Get back for example 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:
> 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.


That they are non-trivial, absolutely!

I was the statement by Sam that SRV and MX did *not* have these security implications URI have I wanted to know more about.