--On Tuesday, May 21, 2013 08:08 +1200 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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