(heads-up to readers -- there are a couple of issues identified
below that are separate from the security ones)
--On Thursday, March 05, 2015 07:56 +0100 Eliot Lear
<lear@xxxxxxxxx> wrote:
> A simple way to address the concern that Sam raised is to note
> that DNSSEC's trust model is largely binary, and not subject
> to alternative trust anchors. That is- parent zone
> administrator's keys may either be trusted or not. On the
> other hand, I don't know that this is the draft to take on
> that issue. It's a fundamental difference between the two
> models and there are pluses and minuses to each, and it's
> perhaps worth exploring, but in this draft?
Eliot's comment above is consistent with my prior remarks on the
subject (including at least one off-list and a few others I was
too fed up to send). I think this issue is a real and
important one. I think some documentation about what DNSSEC
(and, by the way, DANE, etc.) are useful and/or optimal for (and
what their trust model implications and assumptions are) is
definitely needed. But the issues are neither new nor unique to
this spec or RRTYPE. IMO, _at most_, this document should
contain a statement indicating that there are issues and that
applications considering using this RRTYPE should be aware of
them.
If anything, the text now says too much because introductory
statements like "The basic mechanism for successful use of URI
works..." strongly imply that use of, and reliance on, DNSSEC is
the only way to accomplish successful (and safe) use. The
current Security Considerations section could be equated to an
Applicability Statement that said "unless DNSSEC is used, and
used as specified in this document, use of the URI RR is NOT
RECOMMENDED". I don't think that is either intended or
justified.
On a separate topic, I'm not sure that the second paragraph of
the Introduction is correct. Historically (sic) and as far as I
am aware, DDDS has been used heavily only in conjunction with
ENUM. It also takes me three or four readings each time I
encounter it to figure out what "looking up URIs given a
hostname" means (noting that, for some versions of DNS
terminology, a hypothetical domain (owner, node) with only NAPTR
records is _not_ a "hostname"). Perhaps something more like the
following would be both more true and easier to understand:
Historically, uses of the DNS to map a domain name to a
URL have relied on the NAPTR RRTYPEs and then on the
DDDS[RFC3401] application framework with the DNS as a
database as specified in RFC 3404 [RFC3404].
The following sentence isn't clear, which doesn't help.
Probably what is intended more like:
Among the implications of that usage are inability to
select interesting and relevant NAPTR records from those
that match the query.
There are several other editorial issues (e.g., "Querying for
URI resource records is not replacing querying..." later in the
Introduction and "Applications MUST know the specific service to
prepend..." in Section 3 (one cannot prepend "a service", only
an identifier of one)), but I hope we can leave them to the RFC
Editor to identify and sort out.
Otherwise, I believe my concerns have been addressed.
Finally, given these discussions, I believe the Acknowledgements
section probably needs review and updating.
best,
john