On Oct 22, 2014, at 4:34 PM, Paul Hoffman <[email protected]<mailto:[email protected]>> wrote in response to Paul Ferguson.
I am afraid that this efforts gets too far down the path before realizing how some implementation of the "privacy path" before realizing that the scheme breaks things like passive DNS collection. Passive DNS collection is done at recursive and authoritative servers. How would encryption between the stub and its upstream recursive affect the ability to collect passive DNS data? Encryption between the recursive and the authoritative would not prevent collection of passive DNS data at those points either. Fergie, isn’t your point covered in the call to be aware of the “tension” between monitoring and privacy goals in the paragraph below from RFC 7258 (as well as in volumes of discussion beforehand on the perpass list)? While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962<http://tools.ietf.org/html/rfc6962>] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered. Best regards, Allison
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
