> On Wed, Feb 25, 2015 at 05:28:35PM +0100, Patrik F?ltstr?m
> wrote:
>
>> > 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.
>>
>> 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.
>...
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