--On Tuesday, May 21, 2013 08:08 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
These potential concerns can be mitigated through
restricting access to zones containing EUI48 or EUI64 RRs
or storing such information under a domain name whose
construction requires that the querier already know some
other permanent identifier.
This "can be" seems too weak. Shouldn't we have a MUST here?
Also, I doubt that the second option (a shared secret) is
sufficient.
I'd guess that, in the actual use cases, a MUST would be ignored
and am consequently would be reasonably happy with the existing
text even if it said less, thereby reducing the sensation of
hand waving.
A shared secret or other mechanism for obscuring a name might be
sufficient if the privacy requirement was to prevent casual data
mining and resulting attacks. What is, or is not, sufficient
really depends on the risk analysis and assessment of how
serious a failure might be, an analysis that is missing from the
document. That said, if serious protection were needed,
wouldn't it make sense to incorporate some provision for data
encryption in the RRTYPE itself rather than trying to use an
obscured domain name? I wouldn't really propose that. Instead,
I think the bottom line is closer to "if some data really need
to be secure and private, the public DNS is probably not the
right place to put them".
Comparing this to my earlier comments, I think an IETF Proposed
Standard really needs to discuss and resolve these issues and
that Brian's question is important in that context. If hand
waving is appropriate, it should say why. If an obscured
identifier is sufficient, it should explain why that is the case
or the circumstances under which it is the case. The same
problems could be solved with an Informational document by
clearly describing the RRTYPE and then, if this sort of
information is needed at all, making it clear that it represents
the authors' opinion and how they expect their RRTYPE to be used
rather than, e.g., IETF consensus.
john