From my perspective it didn't seem that query privacy meant only encryption; there may be steps that can be privacy-protective that can be taken independently of or before encryption (ergo QNAME min). That seems a key question for the WG --> is query privacy limited to encryption or are there addition things or alternative things that can be done?
In addition, the notion of addressing potential differences between RSOs, TLDs and SLDs grew from the realization that each of these are usually distinct groups of operators, may have different requirements or operational goals/concerns, and will likely implement on different timeframes. But this is simply a matter of opinion right now - let’s maybe see how it looks as we amend the requirements based on the call & mailing list and see how things shape up. Jason On 10/29/19, 10:20 AM, "dns-privacy on behalf of Paul Hoffman" <[email protected] on behalf of [email protected]> wrote: Here are a few responses to the initial draft. I will try to be on the call unless we lose power again. There are many parts of the "core requirements" that seem out of place. - Resolvers have never had to understand the different between the root zone and TLDs and SLDs and "other", so introducing that here might cause bikeshedding and lack of adoption. A simpler core requirement would be that DoT is required between resolvers and any interested authoritative server. - QNAME minimization is orthogonal to adding cryptographic privacy. If you have a cryptographic tunnel, QNAME minimization adds overhead and the risk of additional round trips. On the other hand, some resolvers are perfectly happy using QNAME minimization all the time, so they shouldn't have to know whether to change settings if DoT is in use. - The aggressive caching requirement mixes up aggressive caching and normal caching in the all-caps bit. Aggressive caching will reduce the number of TLS connections you need to set up, so it is a positive, but it is unclear how requiring it in order to use ADoT could be enforced. - DNSSEC validation is orthogonal to adding cryptographic privacy. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
