On 6/21/15 8:22 AM, hellekin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 06/20/2015 03:12 PM, internet-dra...@ietf.org wrote:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
*** 2.3 has a repeat "either".
That's a good catch. I'll get the authors to fix up.
2.6 reads correctly, but the more important reason IMO is the risk of
privacy leak for the user. Similarly, the Security Considerations
mention "leak the identity of the service that the user is attempting to
access", which is grammatically correct but does not pinpoint that the
user's privacy is the center of interest. Specifically, in 2.6,
"leaking" the requested .onion to an authoritative DNS server that would
implement NXDOMAIN usurpation could as well leak this information to
third-parties (e.g., through beacons injected in the response).
While I understand why you feel 2.6 should contain information about
user's privacy, it currently seems to meet the requirements for [RFC6761].
I'm still uncertain about 2.1: it's a remark that's already contained in
the Security Considerations, and the technical requirement for humans is
actually mentioned in the introduction: "Such addresses can be used as
other domain names would be (e.g., in URLs [RFC3986])"
In the Security Considerations, another point can be added to the
"compromise list": "The .onion service address the user requests is sent
to the DNS (which is what this document addresses)." It is different
from "The access protocol is implemented or deployed incorrectly": e.g.,
Web browsers using DNS-pre-fetching for non-DNS strings.
I'll let the authors answer that.
Otherwise this draft addresses my previous concerns, except for the fact
it reserves .onion and not .onion AND .exit, which is still debatable.
Thanks. The consensus that came from the interim meeting is that each
name should have their own draft, so they can be debated on their
merits. This was what I sensed, and I may be incorrect.
It's a very nice, consistent update from the previous draft. I'd
appreciate an explicit mention of the user's privacy somewhere.
Thank you for your attention,
tim
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
