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

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Feb 2015 14:07:54 +0100

I'm also sorry for not commenting earlier in thread.  My point was
informational, and not an issue.  However, what you describe below seems
appropriate.

Eliot

On 2/23/15 2:04 PM, Patrik Fältström wrote:
> All,
>
>
> Due to a mistake from my side, the new version I have been hacking in based on comments coming back during the still open last call was posted the other day. I am sorry for that and my apologies for people being confused.
>
> It was my intention "only" to describe here what I have found so far in comments, so let me summarize in no specific order:
>
> - It is confusing to have a full section called "examples" and then only have one example.
>
> - The registries that existed when the draft was first posted was (only) the ENUM registry, while now we also have a registry for SRV prefixes, and this draft can and should reference both
>
> - The example(s) given should because the draft reference a registry use actual values that are registered.
>
> - As no web browser have implemented lookup for the URI RRType (as far as I know), the example should not be using "homepage" as an example, but something else
>
> - Minor clarifications that mostly are editorial
>
> Some of these, but not all, are already implemented in the prematurely posted version -11 which should not have been posted.
>
> Once again, my apologies. Thanks to Eliot, Mark, Suzanne and Pete for helping me.
>
>    Patrik
>
>> On 29 jan 2015, at 08:05, Patrik Fältström <[email-masked]> wrote:
>>
>>
>>
>>
>>> On 29 jan 2015, at 07:59, Eliot Lear <[email-masked]> wrote:
>>>
>>> Hi Patrik,
>>>
>>> On this one point:
>>>
>>>
>>>> On 1/28/15 9:46 AM, Patrik Fältström wrote:
>>>>
>>>> The RRType is registered and can not be changed.
>>>>
>>>> That said, what can be referred to is a "better" registry for services. IETF do not have a registry for services for SRV. If IETF did, then I would have referenced that registry. I think it is "stupid" to create a new registry.
>>> Stupid or not, it exists.  Go to [1] and select "Service name only".
>>> RFC 6335 updated RFC 2782 on this point[2].
>> Ok, I have been sleeping by the wheel!
>>
>> Mea culpa.
>>
>> Let me come back on this.
>>
>>   Patrik
>>
>>> Eliot
>>>
>>> [1] http://www.iana.org/form/ports-services
>>> [2] http://tools.ietf.org/html/rfc6335
>>>

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Feb 2015 10:05:15 -0500

Hi.

Since the Last Call ends tomorrow and much of what I have to say
about this draft is really more general observations about
architecture and IETF procedures about which the draft is either
the beneficiary or the victim, this is a short and focused note
for the Last Call and those who are not interested in my
(inevitably longer) musings and/or explanations of concerns.

We have dug ourselves into a bit of a hole (or more than one)
wrt mechanisms for resolving references and DNS entries that
reference other DNS entries, some of them with the potential for
triggering multiple trips to the DNS with intermediate
processing.  Independent of that problem (see other note), I
believe this I-D should be approved, and approved as a Proposed
Standard, on the grounds that we (and the Internet) are better
off with it than we are with only the NAPTR record and its
S-NAPTR refinement.

I do note that having "priority" and "weight" separated is not
well-motivated (or even explained) in either this document or in
the original application.  Certainly we have had sufficient
experience with confusion about MX and SRV priorities to be
cautious about adding another ranking field, especially one
whose values are interpreted as "largest integer has the highest
preference" while the more traditional priority is interpreted
as "smallest integer is highest preference".   Because IANA
registered this RR four years ago, it is too late to change that
(see the forthcoming longer note) but somewhat more explanation
in this document would, IMO, be helpful and might even above
confusion-related problems in configuration and implementations.
Noting that none of the examples in -11 use Weight in a
substantive way, I would hope that explanation would include a
discussion of when one would use "Weight" as distinct from
finer-grained Priorities and what benefits would be associated
with using it.

    john

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 15:37:57 +0000

On Mon, Feb 23, 2015 at 10:05:15AM -0500, John C Klensin wrote:

> the original application. 

This is simply carried over verbatim from SRV, where priorities
yield strict ordering, while weights (for entries with the same
priority) support weighted load-sharing.  This draft does not appear
to differ from SRV except in replacing target+port with an URI.

> Certainly we have had sufficient
> as "smallest integer is highest preference".

I see nothing new added here, it just carries over priority/weight
from SRV, and priority (which takes precedence over weight) is the
same as SRV and MX in as far as lowest number wins.  Clearly with
load-sharing relative weights, highest weight gets the most traffic,
but only statistically, some fraction of the time lower-weight URIs
are (to be) used.

While I am here, a few quick (likely not comprehensive) spelling/wording
fixes:

	Section 1:

		s/For resolution the application need to/For resolution the application needs to/

		s/number of implications/number of limitations/

		s/is not replacing/is not intended to replace/

	Section 2:

		s/repetitive queries/repeated queries/

	End of Section 3:

	    s/stake holders/stakeholders/	

	Section 4.1:

		s/DNS labels that occur in nature/regular DNS labels/

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Feb 2015 10:52:17 -0500

--On Monday, February 23, 2015 15:37 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> well-motivated (or even explained) in either this document or
>> in the original application. 
> 
> priority) support weighted load-sharing.  This draft does not
> appear to differ from SRV except in replacing target+port with
> an URI.

But here, as distinct from SRV, a good deal is known about the
relationship (or, more accurately, association) among targets
because of what is in the owner field while, with SRV, there are
potentially different hosts and mechanisms for the same service.
One of the presumed attractions of this mechanism relative to
SRV (and NAPTR) is that one does not have to go fishing around
in, and parsing, RDATA fields to figure out what is going on.
In that regard, it appears to be more like the single-service MX
record, which has never needed a weight.

If "make this as much like SRV as possible" is a motivation,
then I'd expect that to be written a little more clearly and
might expect Weight to be specified as "reserved for future
extension; set to zero in all cases".  Or, if not, I expect its
use to be clearly explained.  Perhaps that explanation could be
just a reference to SRV, but I doubt it.

>...
> While I am here, a few quick (likely not comprehensive)
> spelling/wording fixes:
>...

I have nothing to add to/above your editorial suggestions.

     john

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 15:52:41 +0000

> to differ from SRV except in replacing target+port with an URI.

I neglected to comment on the "Security Considerations" section.

As observed in the DANE SMTP draft (draft-ietf-dane-smtp-with-dane-14
section 1.3.2) mixing DNS indirection with TLS significantly changes
the security picture.  The URI draft mentions the need for DNSSEC
but likely understates the significance of the impact.

For example, what determines whether to use TLS?  The target URI,
or some prior policy in the application?  Must URI RRsets always
be DNSSEC validated?  If not what prevents downgrade attacks to
HTTP?  If the DNS (via DNSSEC) is a critical "trusted entity",
should not then TLS use the DANE PKI (any DNS compromise cannot be
compensated for by a public CA validating a URI that has been
redirected to a hostile site)?

So I take issue with the opening sentence of "Security Considerations".

    "The authors do not believe this resource record cause any new
     security problems."

I think the use of DNS indirection via URI RRs (as also with SRV,
MX, ...) profoundly changes the security model for TLS.

-- 
	Viktor.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 23 Feb 2015 17:00:29 +0100

John,

> as "smallest integer is highest preference".   Because IANA

While the text is clear to ‘me’ - I have to agree I’ve more than once seen this go wrong during initial implementations (all easily fixed by a few emails with the authors though).

BUT given that the confusion arises from text[1] which is very similar to the original in SRV rfc2782[2] - and given that we have (and will have) that issue for all use of SRV I am not sure if this should go into this draft.

And am wondering why it would not be better to have a separate explanation RFC which deals with this; and the Order/Preference of NAPTR (3). 

Dw.

1: From version 10 of the  draft:

4.2.  Priority

   The priority of the target URI in this RR.  Its range is 0-65535.  A
   client MUST attempt to contact the URI with the lowest-numbered
   priority it can reach; URIs with the same priority SHOULD be tried in
   the order defined by the weight field.

4.3.  Weight

   A server selection mechanism.  The weight field specifies a relative
   weight for entries with the same priority.  Larger weights SHOULD be
   given a proportionately higher probability of being selected.  The
   range of this number is 0-65535.

2: RFC2782:

 Priority
        The priority of this target host.  A client MUST attempt to
        contact the target host with the lowest-numbered priority it can
        reach; target hosts with the same priority SHOULD be tried in an
        order defined by the weight field.  The range is 0-65535.  This
        is a 16 bit unsigned integer in network byte order.

   Weight
        A server selection mechanism.  The weight field specifies a
        relative weight for entries with the same priority. Larger
        weights SHOULD be given a proportionately higher probability of
        being selected. The range of this number is 0-65535.  This is a
        16 bit unsigned integer in network byte order.  Domain
        administrators SHOULD use Weight 0 when there isn't any server
        selection to do, to make the RR easier to read for humans (less
        noisy).  In the presence of records containing weights greater
        than 0, records with weight 0 should have a very small chance of
        being selected.

        In the absence of a protocol whose specification calls for the
        use of other weighting information, a client arranges the SRV
        RRs of the same Priority in the order in which target hosts,
        specified by the SRV RRs, will be contacted. The following
        algorithm SHOULD be used to order the SRV RRs of the same
        priority:

        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.

        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.

3: RFC2915 —> rfc3404.

Order
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

   Preference
      A 16-bit unsigned integer that specifies the order in which NAPTR
      records with equal "order" values SHOULD be processed, low
      numbers being processed before high numbers.  This is similar to
      the preference field in an MX record, and is used so domain
      administrators can direct clients towards more capable hosts or
      lighter weight protocols.  A client MAY look at records with
      higher preference values if it has a good reason to do so such as
      not understanding the preferred protocol or service.

      The important difference between Order and Preference is that
      once a match is found the client MUST NOT consider records with a
      different Order but they MAY process records with the same Order
      but different Preferences.  I.e., Preference is used to give weight
      to rules that are considered the same from an authority
      standpoint but not from a simple load balancing standpoint.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Feb 2015 14:04:54 +0100

All,

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 16:24:30 +0000

> just a reference to SRV, but I doubt it.

A couple of years back I wrote (for my employer) a Python LDAP
iterator that fully implements the SRV record priority and weight
specification.  I found that others looking over the code later
were surprised by the attention to detail.  It seems that many
implementations don't even pay attention to SRV priorities, let
alone weights.

So perhaps you're right, in that the SRV priority+weight design is
likely over-engineered in general, and for this use-case in
particular.  It seems likely that many implementations simply ignore
the full semantics.

-- 
	Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Feb 2015 11:33:11 -0500

>>>>> "Viktor" == Viktor Dukhovni <[email-masked]> writes:

    Viktor> On Mon, Feb 23, 2015 at 03:37:57PM +0000, Viktor Dukhovni wrote:
    >> in > the original application.
    >> 
    >> appear to differ from SRV except in replacing target+port with an
    >> URI.

    Viktor> I neglected to comment on the "Security Considerations"
    Viktor> section.

    Viktor> As observed in the DANE SMTP draft
    Viktor> (draft-ietf-dane-smtp-with-dane-14 section 1.3.2) mixing DNS
    Viktor> indirection with TLS significantly changes the security
    Viktor> picture.  The URI draft mentions the need for DNSSEC but
    Viktor> likely understates the significance of the impact.

    Viktor> For example, what determines whether to use TLS?  The target
    Viktor> URI, or some prior policy in the application?  Must URI
    Viktor> RRsets always be DNSSEC validated?  If not what prevents
    Viktor> downgrade attacks to HTTP?  If the DNS (via DNSSEC) is a
    Viktor> critical "trusted entity", should not then TLS use the DANE
    Viktor> PKI (any DNS compromise cannot be compensated for by a
    Viktor> public CA validating a URI that has been redirected to a
    Viktor> hostile site)?

    Viktor> So I take issue with the opening sentence of "Security
    Viktor> Considerations".

    Viktor>     "The authors do not believe this resource record cause
    Viktor> any new security problems."

Yes, I see significant security problems with this URI.

In particular, prior to this URI, your security depends on your TLS
trust anchors.  Since this RR encourages folks to validate the
certificate in the target URI, not the expected name entered by the
user, even if DNSSec validation is done, the security now depends on the
DNS trust anchors and the TLS trust anchors.

For the public web, those trust anchors probably have similar enough
security that it is reasonable to assume they are similar by default.

For most other applications I don't think that's true.  For some
applications i'd expect TLS trust anchors for that application to be
much stronger than DNS trust anchors, while for other apps I'd expect
DNS trust anchors to be much stronger.

I think the security implications of this draft, and by implication the
advisability of this draft have been inadequately considered.  I believe
a last-call is premature at this time.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Feb 2015 08:49:29 -0800

> Yes, I see significant security problems with this URI.

It sounds like you have issues with URIs in general, not in a DNS RTYPE that carries a URI. That is, any URI that has a domain name that can lead to redirection (though CNAME, DNAME, or SRV) would have the properties that worry you. It that a fair summary?

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Feb 2015 17:02:09 +0000

> Yes, I see significant security problems with this URI.

With MX and SRV indirection, prior to DNSSEC/DANE, TLS applications
have generally used the service domain (not the target domain) as
the relevant reference identifier.  Also MX and SRV records do not
specify whether TLS is or is not to be used, that decision is made
by other means.  Here, the language specifies using the target,
which makes the DNS trusted as with DNSSEC/DANE and this seems
unavoidable, because the URI includes the scheme!

One might make the case that it is not the new DNS RRtype itself
that changes the security model.  Rather, it would be its use in
with a particular protocol.  This document then just provides the
means, and future documents specify when URI records are (or are
not) to be applied to a particular application protocol.  The draft
then just defines the record type format, with specific discussion
of when to use it, exactly how to decide whether TLS is required
and which PKI to use deferred to documents that specify a particular
application context.

> DNS trust anchors and the TLS trust anchors.

Yes, both, in a way that means that compromise of either breaks
security.  So at the very least, I would advocate to go with DANE
for verification: in for a penny, in for a pound!  Adding a second
set of trusted parties increases exposure without any compensating
increase in security.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Feb 2015 17:26:49 +0000

On Tue, Feb 24, 2015 at 08:49:29AM -0800, Paul Hoffman wrote:

> It sounds like you have issues with URIs in general, not in a DNS RTYPE
> that carries a URI. That is, any URI that has a domain name that can lead
> to redirection (though CNAME, DNAME, or SRV) would have the properties
> that worry you. It that a fair summary?

That's not how I read it.  The issue here is that the draft introduces
a DNS-based rewrite of the TLS reference identifier.

	_mumble.example.com. IN URI "https://example.net/"

The draft language stipulates (correctly I think given that DNS
also specifies the URI scheme) that DNSSEC is required and the TLS
reference identifier becomes "example.net".  This is not the case
for HTTP with either CNAME or DNAME, and HTTP does not use SRV
records.

When pre-DANE MTAs use MX records with TLS securely (rather than
just going through the motions), they use the nexthop domain (not
the MX host domain) as the reference identifier.

Similar considerations come into play with RFC 6186 indirection of
IMAP and SMTP server locations.  RFC 6186 just drops the ball in
the user's lap.  A more comprehensive solution is hinted at in:

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-7

but I'm not sure where we are whether DNSSEC last-mile is as yet
sufficiently addressed for that.

Of course with the document under discussion, if mobile applications
are in scope, then of course we again need DNSSEC to be usable in
last-mile environments.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Feb 2015 09:00:44 +1100

> sufficiently addressed for that.

DNSSEC works all the way to the application.  This has been specified
for approaching a decade now (March 2005).  Yes, RFC 4035 covers
how to do DNSSEC in the application.  Yes it is a myth that the last
mile requires something special.  It doesn't.

Validating nameservers are a example of a *application* that validates
answers received from nameservers.  Yes, nameserver are configured
to to talk through recursive nameservers and to validate the answers
they get.

The code to do this exists in libraries which can be called from
applications other than nameservers.  Named is just a application
that calls libdns to do most of its work.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 25 Feb 2015 10:48:00 +0100

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Feb 2015 12:32:50 -0500

Viktor> On Tue, Feb 24, 2015 at 08:49:29AM -0800, Paul Hoffman wrote:
    >> It sounds like you have issues with URIs in general, not in a DNS
    >> RTYPE that carries a URI. That is, any URI that has a domain name
    >> that can lead to redirection (though CNAME, DNAME, or SRV) would
    >> have the properties that worry you. It that a fair summary?

    Viktor> That's not how I read it.  The issue here is that the draft
    Viktor> introduces a DNS-based rewrite of the TLS reference
    Viktor> identifier.

Victor is correct.  This draft introduces indirection through DNS.
Typically in the past when we've done indirection through DNS, we've not
changed the expected security principal that we're targeting.
It's that change  that significantly changes the security model.

There are times when an indirection through a trusted directory service
is the right approach.
However, I think the security model change has been inadequately
explored in this draft as evidenced in the text and in responses I
received.

So I continue to believe that last-call is premature until the security
model changes are adequately explored and then documented.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 25 Feb 2015 10:22:38 -0600

> a last-call is premature at this time.

I presume you meant "approval is premature at this time". Obviously the 
discussion of this document prior to Last Call did not surface the 
issues that are now being discussed, so Last Call seems like exactly 
what was required.

I don't think the discussion here has completely come to ground. I am 
reading it with great interest. I'll decide what to do once the 
discussion has completed. Yes, Last Call officially completed yesterday, 
but the loop wasn't closed on some of the earlier comments, so I'm not 
about to stop the discussions that are now happening.

Thanks to everyone for their input.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 25 Feb 2015 17:28:35 +0100

> On 24 Feb 2015, at 18:32, Sam Hartman <[email-masked]> wrote:
> 

It is not new with this draft and URI, it is done for example with SRV, and also MX.

That said, it is an important discussion to have, and I have waited for the DNS and Applications Community to talk about it.

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Feb 2015 18:02:28 +0000

> It is not new with this draft and URI, it is done for example with SRV, and also MX.

DNS redirection indeed has precedents in MX and SRV records.
However, there is little to no prior practice in combining such
rediction with "strict" TLS wherein the client's reference identifier
for the server "chases" the redirection.

I am sure that some MTA implementations just blindly apply TLS
verification to the insecurely obtained MX hostname, even without
DNSSEC.  Such "going through the motions" is not in my view a real
precedent.  [ IIRC there was, and perhaps still is, a large email
filtering provider that verifies the name the server returns in
the clear in the first line of the EHLO response!  This too is not
a precedent for the proposed URI security model. ]

> That said, it is an important discussion to have, and I have
> waited for the DNS and Applications Community to talk about it.

You might wonder why I of all people should be making a fuss about
using DNS for TLS security.  After all, I'm co-authoring two DANE
documents and described DANE as a candidate mechanism for opportunistic
use of authentication in the Opportunistic Security [RFC7435]
document.

The reason is absolutely not that I am opposed to designs that
employ and trust DNSSEC to enable TLS reference identifier indirection.
I support the use of such designs.  Rather, it seems that the URI
draft glosses over the implementation details and implications much
too casually.  This is a major change from current practice, and
I think should be acknowledged as such and explored in more detail.

Some considerations relevant to combining DNSSEC-validated redirection
(which updates the client's notion of what to expect in peer
certificates) appear in:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-1.3

I should note that MTA-to-MTA SMTP is a specific opportunistic TLS
application with a long history of deployment, so the above reference
is about that singular use-case in which the issues are relatively
well understood.

With URIs, it is far less clear what applications are in scope,
and what their security requirements might be.  So a proper discussion
of DNS-based URI redirection might need to be described as a set
of considerations to apply when determining which schemes in the
URI to accept, when to "chase" the reference identifier to the
URI's target and even whether the DANE PKI might then be more
appropriate in some situations,

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Feb 2015 15:32:23 -0500

>> > Victor is correct.  This draft introduces indirection
>> > through DNS. Typically in the past when we've done
>> > indirection through DNS, we've not changed the expected
>> > security principal that we're targeting. It's that change
>> > that significantly changes the security model.
>> 
> rediction with "strict" TLS wherein the client's reference
> identifier for the server "chases" the redirection.
>...

Victor,

Incorporating parts of my "long version" note from earlier today
by reference, but...

It now seems to me that this particular document has
accidentally conflated at least three things under a title,
abstract, and introduction that is only about the first.

(1) The description of a particular, registered, DNS RRTYPE.

(2) A lot of applicability information about how the thing is to
be used in or with other protocols, including security
implications and applicability of security add-ons (like
encrypted tunnels).

(3) Some technical changes to NAPTR/DDDS whose connection to
this RRTYPE are not particularly clear to me beyond the ability
of either to specify a URI in the RDATA.

The second of these includes not only the issues you are
identifying but also a variety of "what is a URI and what are
its implications" questions, some of which have shown up on the
IETF, Apps-Discuss, and URN lists in the last several months as
well as in discussions in WHATWG and W3C.  If one is even
slightly sensitive to those issues, then the document is
probably in need of a discussion about what types of URIs (or
URI schemes and constructions) are appropriate and/ or what an
application is supposed to do when an inappropriate one is
encountered.  We have traditionally not considered those DNS
issues but, once one goes beyond the DNS (i.e., beyond (1)
above) it is not clear where one should reasonably stop.

So...  I think Patrik and Olaf should remove the NAPTR/DDDS
stuff unless they are willing to do a lot of revising to explain
why it is present and how things relate.

I think the rest is a bit of a judgment call.  While I'd be
happy to see a comprehensive document that would address all of
those issues, I would also like to get a good description of the
RRTYPE published somewhere soon, ideally a couple of years ago.
It seems to me that making a complete analysis of security
alternatives, or a complete analysis of the URI situation as it
relates to this RRTYPE, much less both are likely to be a _lot_
of effort and that, if we want to get the document published,
what should be done should probably be confined to explicitly
noting the issues, e.g., that any indirection through the DNS
raises security issues that need careful understanding and for
which there is no magic bullet.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Feb 2015 03:29:12 -0500

--On Wednesday, February 25, 2015 22:18 -0500 Sam Hartman
<[email-masked]> wrote:

>     John> I think the rest is a bit of a judgment call.  While
> I'd be     John> happy to see a comprehensive document that
> would address all     John> of those issues, I would also like
> to get a good description     John> of the RRTYPE published
> somewhere soon, ideally a couple of     John> years ago.  It
> seems to me that making a complete analysis of     John>
> security alternatives, or a complete analysis of the URI
> John> situation as it relates to this RRTYPE, much less both
> are     John> likely to be a _lot_ of effort and that, if we
> want to get the     John> document published, what should be
> done should probably be     John> confined to explicitly
> noting the issues, e.g., that any     John> indirection
> through the DNS raises security issues that need     John>
> careful understanding and for which there is no magic bullet.
> 
> I'm happy with an informational document that does the above
> and claims only to describe the existing RR type.
> I'm not happy with a standards-track document that fails to
> cover the security issues in significantly better detail.

I'm inclined to be a little more flexible, but certainly a
choice between a narrowly-written Informational document and a
comprehensive Standards-track one -- with "comprehensive"
including careful discussion of both security considerations and
relationships to other alternatives -- would be my first
preference.

The current I-D is none of the above.  Instead, it is a mixture
of description of a new RRTYPE with an update to an existing
RRTYPE and weak coverage of relationships, alternatives,
security, and other tradeoffs.

   john

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Feb 2015 13:56:33 -0500

>>>>> "Viktor" == Viktor Dukhovni <[email-masked]> writes:

    Viktor> You might wonder why I of all people should be making a fuss
    Viktor> about using DNS for TLS security.  After all, I'm
    Viktor> co-authoring two DANE documents and described DANE as a
    Viktor> candidate mechanism for opportunistic use of authentication
    Viktor> in the Opportunistic Security [RFC7435] document.

    Viktor> The reason is absolutely not that I am opposed to designs
    Viktor> that employ and trust DNSSEC to enable TLS reference
    Viktor> identifier indirection.  I support the use of such designs.
    Viktor> Rather, it seems that the URI draft glosses over the
    Viktor> implementation details and implications much too casually.
    Viktor> This is a major change from current practice, and I think
    Viktor> should be acknowledged as such and explored in more detail.

I too support designs like this that use DNSSec to support TLS reference
identifier indirection as an approach that is appropriate for a
significant number of deployments.
So, I do think we should have standards in this space, but I think we
need to explore the implications of this major change.

I also want appropriate policy controls in place.  This is great for
some deployments and would significantly reduce the security of other
deployments.  So, in terms of policy, I'd want us to explore what sort
of policy we need to enable and also to find credible mechanisms for the
policy we decide we need.  One of the simplest ways to apply policy is
to do so at the protocol/application level.  For example we might decide
that mechanisms like the URI RR are appropriate when we're using large
trust anchor sets like the web PKI, but not when we're using application
or protocol-specific trust anchor sets.
That sort of policy is easy because you can codify it in standards
documents and implementations.

Where we decide that the policy is deployment specific, it it may get
much more complicated.

Still, I think we need to have at least the general version of that
discussion prior to putting a mechanism like this on the standards
track.

Earlier, I said that I thought it was premature to have a last-call on
this draft and Pete questioned me about that.  What I mean is that I
think it is premature to approve this draft without an additional last
call.  Even if we make minor textual changes, the implications are
significant enough that I think we should have a full re-review with a
better understanding of the security implications.  I didn't get that
when I approached the existing last call.
I agree with Pete that drawing out this round of comments was very
useful.

I disagree that SRV or MX introduces similar complexity into standards.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Feb 2015 22:18:17 -0500

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> I think the rest is a bit of a judgment call.  While I'd be
    John> happy to see a comprehensive document that would address all
    John> of those issues, I would also like to get a good description
    John> of the RRTYPE published somewhere soon, ideally a couple of
    John> years ago.  It seems to me that making a complete analysis of
    John> security alternatives, or a complete analysis of the URI
    John> situation as it relates to this RRTYPE, much less both are
    John> likely to be a _lot_ of effort and that, if we want to get the
    John> document published, what should be done should probably be
    John> confined to explicitly noting the issues, e.g., that any
    John> indirection through the DNS raises security issues that need
    John> careful understanding and for which there is no magic bullet.

I'm happy with an informational document that does the above and claims
only to describe the existing RR type.
I'm not happy with a standards-track document that fails to cover the
security issues in significantly better detail.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Feb 2015 11:25:56 -0500

On Wed, Jan 28, 2015 at 2:12 AM, Mark Nottingham <[email-masked]> wrote:

> The document effectively gives a "type" for the URI by associating a value
> from the ENUM service registry. While that makes sense from the standpoint
> of ENUM, if this mechanism is truly generic to *all* URIs, it seems to me
> that it'd be much more sensible to use the typing system already in place
> for URIs -- link relations <http://tools.ietf.org/html/rfc5988>.
>

Such a good idea that there is already a draft with just such an approach:
https://datatracker.ietf.org/doc/draft-newton-link-rr/

-andy

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Feb 2015 10:41:03 -0600

> security issues in significantly better detail.

An Informational RFC that merely describes the RR type as it is already
registered with the IANA would add little value unless it came with a
warning about the unexplored security space.

We do need a Standards-Track RFC for this RR because uses of it are
starting to pop-up that really could use more information about how to
use URI RRs securely.

Also, I don't see why we're even talking about publishing as FYI before
the shepherding AD and I-D authors decide how to continue.  ISTM that
the right thing to do here is to give the authors a chance to choose
whether to address the comments made here fully, or fall back on the
simpler FYI approach.  It's not like there's any urgency to publish an
FYI here...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Feb 2015 11:06:23 -0600

FYI, there is discussion (off IETF lists for now) about using the URI RR
type for Kerberos KDC discovery.  Presumably that would yield an update
to RFC4120.  Such an update would have to be on the Standards track,
natch.

If the URI RR I-D ends up on the Informational track then we'll either:
need a downref (feasible but uncomfortable), update the URI RR to be on
the Standards track, or give up.

Clearly it would be better if the URI RR lands on the Standards track.
It will take more work, but it will be worthwhile.

If the authors lack the energy for it, perhaps we can move this
discussion to SAAG and find volunteers to write and debate the necessary
text.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 26 Feb 2015 18:26:07 +0100

> On 26 feb 2015, at 18:06, Nico Williams <[email-masked]> wrote:
> 

At the moment, as I have been trying to push this draft through the IETF process since 2007 (!) I have obviously not run out of energy yet.

That said, I want clear instructions from IETF in what direction I should go, i.e. I want IESG to tell me (i.e. an AD).

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Feb 2015 13:27:27 -0600

On Thu, Feb 26, 2015 at 06:26:07PM +0100, Patrik Fältström wrote:
> At the moment, as I have been trying to push this draft through the
> IETF process since 2007 (!) I have obviously not run out of energy
> yet.

!

> That said, I want clear instructions from IETF in what direction I
> should go, i.e. I want IESG to tell me (i.e. an AD).

Well, given that new uses are popping up, and given all the commentary
here, if we have another go at this, I'll review and participate.

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Feb 2015 17:49:48 +1100

Cool! Some quick feedback:

* you should explicitly accommodate target attributes (i.e., extension fields)
* 'rev' was only included in 5988 for backwards compatibility with some fairly esoteric use cases; don't think it's necessary or good here.
* you need to specify how to determine the context of the link (using RFC5988 terminology). 

Cheers,

> On 27 Feb 2015, at 3:25 am, Andrew Newton <[email-masked]> wrote:
> 
> 
> 
> The document effectively gives a "type" for the URI by associating a value from the ENUM service registry. While that makes sense from the standpoint of ENUM, if this mechanism is truly generic to *all* URIs, it seems to me that it'd be much more sensible to use the typing system already in place for URIs -- link relations <http://tools.ietf.org/html/rfc5988>.
> 
> Such a good idea that there is already a draft with just such an approach: https://datatracker.ietf.org/doc/draft-newton-link-rr/
> 
> -andy 

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 08:09:22 +0100

> On 25 feb 2015, at 19:56, Sam Hartman <[email-masked]> wrote:
> 

Sam, I feel I need to understand this.

For MX, you have to start with a URI like this:

mailto:[email-masked]

One look up the MX for frobbit.se and get mail.frobbit.se

One then open an SMTP connection to mail.frobbit.se, and can use TLS where the cert is compared to mail.frobbit.se.

To me that is a change of a domain name given data in DNS.

But there must be something I do not understand.

Please explain.

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Feb 2015 07:58:14 +0000

> For MX, you have to start with a URI like this:

MTAs don't work with URIs.  Those are for occasional use by MUAs,
which don't use MX records.  MTAs (as SMTP relays) deliver mail to
a nexthop domain to another MTA found in the domain's MX RRset.

> One look up the MX for frobbit.se and get mail.frobbit.se

Most MTAs servers either do not support TLS at all, or do opportunistic
TLS in which there is simply no effort to authenticate the peer.

    https://tools.ietf.org/draft-ietf-dane-smtp-with-dane-14#section-1.3

That document explains why SMTP transport security is fundamentally
dependent on DNS security, and why scalable TLS security for SMTP
requires DANE.  We accept redirection and detail the consequences.

Some MTAs "go though the motions" of pretending to do TLS
authentication, but get it wrong by verifying either the hostname
from an insecure DNS MX lookup or worse.

Other MTAs offer reasonably secure TLS configurations, but this
requires that the peer server has the nexthop domain in its
certificate or (and generally in any case) bilaterally negotiated
security settings.

    http://www.postfix.org/TLS_README.html#client_tls_limits
    http://www.postfix.org/TLS_README.html#client_tls_levels
    http://www.postfix.org/TLS_README.html#client_tls_secure
    http://www.postfix.org/TLS_README.html#client_tls_policy

> the cert is compared to mail.frobbit.se.

Except that this is not done in MTAs written by people with clue,
and is known to be insecure ("going through the motions").

> To me that is a change of a domain name given data in DNS.

That's the naive model, but it is wrong.

-- 
	Viktor.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 09:41:42 +0100

> On 27 Feb 2015, at 08:58, Viktor Dukhovni <[email-masked]> wrote:
> 

Ok, trust me, I know how SMTP and mail works :-)

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

Then SRV, can you explain that?

http://example.com/

Lookup of SRV for _web._tcp.example.com

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.

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Feb 2015 09:24:22 +0000

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

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 10:41:28 +0100

> On 27 Feb 2015, at 10:24, Viktor Dukhovni <[email-masked]> wrote:
> 

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 :-)

> change the client's security expectations.

Ok, got it! Thanks!

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

Ok.

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

> implications are non-trivial and need discussion.

Thanks!

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.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Feb 2015 10:56:08 +0100

> unavoidable, because the URI includes the scheme!

I think the real issue here we are concerned about is this:

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.

Eliot

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 11:04:52 +0100

> On 27 Feb 2015, at 10:56, Eliot Lear <[email-masked]> wrote:
> 

Absolutely!

I get that, completely.

I wanted to know what is so special about URI that SRV and MX do _not_ have.

I was surprised I was coming up with some _NEW_ attack vector.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Feb 2015 11:16:24 +0100

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

In the case of SRV the situation is much the same.  You don't specify
whether to start TLS based on SRV.  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.

DNSSEC: it's not just for breakfast anymore.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Feb 2015 09:34:11 -0500

On Tue, Feb 24, 2015 at 11:49 AM, Paul Hoffman <[email-masked]>
wrote:

> to redirection (though CNAME, DNAME, or SRV) would have the properties that
> worry you. It that a fair summary?
>

I think Sam is raising an important point. But it is an easy one to solve.

The DNS is really providing multiple layers of lookup. The question is what
layer the TLS credentials should bind at and what assurances should be
presented to users if any. It is really independent of URI but it is an
important one.

Take the following discovery path

Application provides: Service: _new._ws   Domain: example.com

SRV / URI lookup returns

host1.example.net:443
host2.example.net:443

A / AAAA lookup returns

10.2.3.1:443
10.2.3.2:443

So the question is which TLS certificate should be accepted and what
assertions should be made to the end user?

I don't think the question can be properly be answered without considering
the security policy. At the moment we only have the security policy that
results from explicitly using https:// as the URI.

If someone types in https://www.example.com/ then I think it is clear that
the security policy is ONLY met if the site has a certificate for
example.com.

If someone types in http://www.example.com/ and then gets redirected to
https://www.example.net/ which has an EV certificate, then we have met the
security policy and we have an assurance the site has accountability. So we
can show a security indicator [but I am not going to say which one]

If someone types in http://www.example.com/ and we get back a redirect to
https://www.example.net/ and a DV cert then things are a little different.
The only fact that the cert is attesting to is something we allowed to be
overwritten with an untrusted redirect. We should definitely turn on TLS.
But we should not be telling the user they have any security because they
don't.

This does not map onto the SRV/URI lookup cleanly because we don't have the
notion of a security policy yet. In order to make it work we need to
specify what the security policy is.

Another difference is that SRV and URI should really be considered as being
equivalent to A or AAAA mappings rather than http redirects.

So in my view, if someone types in https://www.example.com/ and there is an
SRV record for _http._tcp, this is not semantically equivalent to a http
redirect as the address bar value does not change. There is no visual
signal. It is a purely internal DNS mapping like a CNAME record.

So I believe that for the example above, a Web Service client should:

* Only accept a TLS certificate for example.com for the purposes of meeting
a 'must meet EV' security policy.

* Accept a TLS cert for example.com OR a DNSSEC trust chain for a
SRV/URI/etc mapping and a TLS cert for host1.example.net for the purposes
of meeting a 'must meed DV'

* Accept any cert at all for the purposes of promiscuous encryption
accepting that this does not provide authentication or confidentiality
guarantees against active attack.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Feb 2015 15:46:02 +0100

On 2/27/15 3:40 PM, Sam Hartman wrote:
>>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:
>
>     Eliot> DNSSEC: it's not just for breakfast anymore.
>
> I've mentioned this before, but DNSSec is not really a complete answer
> here.
> DNSSec is only an appropriate answer when the set of DNS trust anchors
> are appropriate to the information being protected.
>
> Today, I expect for many applications that the information entered by
> the user will be validated against an application-specific set of trust
> anchors.  If DNS is trusted to make decisions about what my target
> security principal can be, then the DNS trust anchors become part of
> that trusted set.  For a number of enterprise applications that's really
> bad from a security standpoint.

You imply that somehow DNS has a separate decision process from the
application.  Why is that?

Eliot

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Feb 2015 09:54:19 -0500

On Fri, Feb 27, 2015 at 1:49 AM, Mark Nottingham <[email-masked]> wrote:

> * 'rev' was only included in 5988 for backwards compatibility with some
> fairly esoteric use cases; don't think it's necessary or good here.

Thanks Mark. Excellent feedback!
-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Feb 2015 10:02:10 -0500

On Fri, Feb 27, 2015 at 2:07 AM, Patrik Fältström <[email-masked]> wrote:

> My feedback to Andrew when he presented this to me was that:
>
> - In general I am nervous of moving HTTP header attributes into the DNS,
> as it might create inconsistencies when for example the data in DNS do not
> match what is in the HTTP header, and we already have a content-negotiation
> mechanism in HTTP
>
>
I think that is simply solved by stating none of it overrides the content
negotiation of the application. But a mismatch here is an adminstrative
error, in my opinion.

> - Given experience with length of URI / text fields in DNS, I would have
> had the encoding of RDATA as "flag" "flag" "flag" "uri" (while being
> nervous over the size restrictions of the URI...which is the reason in URI
> the uri is all of RDATA except the weight and priority).
>
> - I am also nervous over the size of the RRSet, i.e. same issue I see with
> NAPTR, and the reason why I added the prefix (like SRV) to the URI RR
>

I plan to move to use this advice. Thanks.

-andy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Feb 2015 17:11:44 +0100

Ok, I understand what you are saying.  The changing of the origin that
gets validated is the fundamental no no.

Eliot

On 2/27/15 4:18 PM, Sam Hartman wrote:
> 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.
>
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Feb 2015 09:00:24 -0500

>>>>> "Patrik" == Patrik Fältström <[email-masked]> writes:

    >> I disagree that SRV or MX introduces similar complexity into

    Patrik> Sam, I feel I need to understand this.

    Patrik> For MX, you have to start with a URI like this:

    Patrik> mailto:[email-masked]

I'm sorry,  I don't understand how a URI is involved in MX processing.
I don't think any of the specs are written in terms of URIsand I find
thinking of MX processing in terms of URIs to be confusing.

For email, we've never really had wide-scale deployment of TLS that does
certificate validation.
Across the Internet, starttls tends to provide something similar to
opportunistic security.
Within an organization where specific certificates are being validated
to specific anchors, I'd be mildly surprised if MX processing was a
significant part of the configuration.

I suspect there's not much uniformity about whether you check the
queried domain or the resulting domain for the certificate, and I
suspect that you'll probably need MTA-specific configuration to get cert
validation to be particularly useful with SMTP.  If I were writing an
MTA, I'd expect the cert to match what went into the MX query, not what
came out.  However, I'd have a variety of configuration options all
defaulting to not checking the certificate at all.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Feb 2015 09:40:36 -0500

For other applications, this is a great technology and DNSSec is a
reasonable way to protect it.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Feb 2015 10:18:30 -0500

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 08:07:25 +0100

- In general I am nervous of moving HTTP header attributes into the DNS, as it might create inconsistencies when for example the data in DNS do not match what is in the HTTP header, and we already have a content-negotiation mechanism in HTTP

- Given experience with length of URI / text fields in DNS, I would have had the encoding of RDATA as "flag" "flag" "flag" "uri" (while being nervous over the size restrictions of the URI...which is the reason in URI the uri is all of RDATA except the weight and priority).

- I am also nervous over the size of the RRSet, i.e. same issue I see with NAPTR, and the reason why I added the prefix (like SRV) to the URI RR

   Patrik

> On 27 feb 2015, at 07:49, Mark Nottingham <[email-masked]> wrote:
>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 27 Feb 2015 10:24:21 -0600

On 2/25/15 9:18 PM, Sam Hartman wrote:
>>>>>> "John" == John C Klensin<[email-masked]>  writes:
>>>>>>              

After speaking with Patrik, I think you have convinced us: The correct 
thing to do at this point is to take out all of the information beyond a 
simple description of the RR, beef up the security considerations to 
describe the security issue, and make that document Informational.

I'm going to ask Patrik to publish a revised ID at this point, which I 
expect to see in the next couple of days. Unless I hear loud objections 
(and I will cormfirm with the rest of the IESG as well), I'm inclined to 
simply extend the current Last Call by 2 weeks after the revised ID 
instead of restarting an entirely new 4 week Last Call. I think the 
discussion is active enough here on the list that nobody is going to 
lose track of it, and we're now talking about an Informational document 
rather than something that's going to be Standards Track, so the level 
of required scrutiny is certainly less. If we make this go another 4 
weeks, I'll be off of the IESG and someone else is going to have to pick 
up the ball, which I'd rather avoid having to do. Either way, I'll be 
sure to make an announcement.

pr

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 Feb 2015 10:46:12 -0600

On Fri, Feb 27, 2015 at 10:24 AM, Pete Resnick
<[email-masked]> wrote:
>> [...]
> After speaking with Patrik, I think you have convinced us: The correct thing
> to do at this point is to take out all of the information beyond a simple
> description of the RR, beef up the security considerations to describe the
> security issue, and make that document Informational.

I would much prefer a Standards-Track document that says to
authenticate the origin domainname as follows:

 - use DNSSEC for all DNS queries needed to find the URI RRs and DANE
to authenticate the authorities of the resulting URIs

or

 - expect the target authorities to have certificates that
authenticate the origin, using SNI if need be.

I would still drop everything related to NAPTR and DDDS.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Feb 2015 18:27:07 +0000

> I would still drop everything related to NAPTR and DDDS.

That works for me, and is in reasonable alignment with

	draft-ietf-dane-srv

which ignoring the gory details says essentially the same thing,
but with the choice made dynamically, based on presence of "secure"
SRV and TLSA RRsets, rather than as a static prior dichotomy.

I am also fine with the informational variant.  Either way, perhaps
an informational reference to the DANE SRV draft would be helpful.

As an instigator of the security sub-discussion, I just wanted to
make sure than the document did not claim that introducing indirection
into HTTPS has minor security consequences.  Rather it is a significant
change in the threat analysis for any application that makes the switch.

Likely there are existing applications that have glossed over this
issue (going through the motions) with MX and SRV records, but any
such poor practices are not IMHO sufficient grounds to say that
the current text's security considerations match the scope of the
proposed semantics.

And I still support the proposed semantics, just with eyes wide
open to the security implications.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 Feb 2015 13:50:22 -0600

> That works for me, and is in reasonable alignment with

Good.

> SRV and TLSA RRsets, rather than as a static prior dichotomy.

I did not mean to imply a static choice.  Dynamic is fine.

> an informational reference to the DANE SRV draft would be helpful.

The problem with an FYI that doesn't say these things is that people
will make use of the URI RR type without knowing the trap they're
walking into.  A document with proper text will do.

Alternatively, publish a BCP or Standards-Track RFC about how to use
indirection via DNS securely, then publish this I-D with merely a
reference to the former.  I think just fixing this I-D is the easier way
forward, and it's just one short section of prose.

> change in the threat analysis for any application that makes the switch.

Yes, but given that the RR type has been registered and used, we should
not now hide our heads in the sand.

> the current text's security considerations match the scope of the

Right, SMTP is one thing.  So it's been not secure for ages, but we've
also all understood this (and you're fixing it).  It's different for
*new* uses.

> open to the security implications.

Right.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 Feb 2015 14:37:35 -0600

On Fri, Feb 27, 2015 at 08:07:25AM +0100, Patrik Fältström wrote:
> - In general I am nervous of moving HTTP header attributes into the
>   DNS, as it might create inconsistencies when for example the data in
>   DNS do not match what is in the HTTP header, and we already have a
>   content-negotiation mechanism in HTTP

If anything, it may not provide the optimization that's desired.  (Any
numbers?)

> - Given experience with length of URI / text fields in DNS, I would
>   have had the encoding of RDATA as "flag" "flag" "flag" "uri" (while
>   being nervous over the size restrictions of the URI...which is the
>   reason in URI the uri is all of RDATA except the weight and
>   priority).

+1

> - I am also nervous over the size of the RRSet, i.e. same issue I see
>   with NAPTR, and the reason why I added the prefix (like SRV) to the
>   URI RR

In for a penny, in for a pound.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 Feb 2015 15:00:38 -0600

On Fri, Feb 27, 2015 at 09:45:10PM +0100, Patrik Fältström wrote:
> > On 27 feb 2015, at 21:37, Nico Williams <[email-masked]> wrote:
> Ok, to go back in history, this is why I originally did believe more
> in Gopher than Web... :-)

But I wanted current numbers, as in performance numbers :)

> I though a proper negotiation would be to know already in the source
> of a referral what kind of data the target was. This was how Gopher
> worked, but Web was different. The link was (is) neutral and the
> negotiation happens at the target.

Very large references would have been unwieldy in HTML back then.

Content-addressed storage is still unwieldy for cross-domain
referencing, and always will be.

> That story, early 1990's, gave me the lesson that the "correct"
> solutions do not always win. The "best" solution wins.

That's hardly the only case, and I'm not sure that your approach would
have been more correct.  The more metadata [about a target resource] you
put into the referring entity's content, the better the chances of the
reference going stale.  Content-addressing is an extreme example of
this, though for your approach I guess one would have used some fuzzy
matching (which is not applicable to content-addressing).

> And this is the reason I am nervous over "gopher like features" in
> DNS. Even though I think it is good...I think it will loose...

I don't think that's a good enough reason here.  There may be other
reasons to tread carefully here.

Nico
--

---

From: Mark Andrews <[email-masked]>
Date: Sun, 01 Mar 2015 09:27:32 +1100

In message <[email-masked]>, 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:
> > I wanted to know what is so special about URI that SRV and MX do _not_ =
> have.
> 

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.

> 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

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.