Hi Duane,
Thank you for your feedback on the draft.
For the changes we have already made, I'd like to refer you and the WG
to the GitHub version
https://github.com/alex-nicat/ietf-dprive-phase2-requirements/blob/master/draft-ietf-dprive-phase2-requirements.md
On 22/06/2020 21:36, Wessels, Duane wrote:
5. Requirements
The requirements of different interested stakeholders are outlined
below.
Perhaps this is obvious others, but I would like to see a better explanation of
exactly what kind of requirements these are meant to be. Are they
implementation or protocol requirements (versus operational requirements)? Or
requirements of some other type?
Indeed, these were not clearly defined. I think with the current
version on GitHub it is better defined what protocol and implementation
is, and what are the options of an operator to support DNS privacy with
the authoritative.
Also, I'm struggling a little bit with "interested stakeholders" above. I don't think
these are requirements *on* stakeholders. Maybe it would be better to say something like
"[protocol] requirements of different elements are outlined below."?
Thank you for the suggestion.
5.1. Mandatory Requirements
1. Each implementing party should be able to independently take
incremental steps to meet requirements without the need for
close coordination (e.g. loosely coupled)
If that is a requirement then MUST/must instead of "should"?
Correct.
2. Use a secure transport protocol between a recursive resolver and
authoritative servers
3. Use a secure transport protocol between a recursive resolver and
TLD servers
4. Use a secure transport protocol between a recursive resolver and
the root servers
These were worded a differently in an earlier version. The following text is from draft-lmo-dprive-phase2-requirements-01:
2. Implement DoT between a recursive resolver and single level domain
authoritative servers (high risk, high priority)
3. Implement DNS privacy protections between a recursive resolver and
TLD servers (low risk, low priority)
4. Implement DNS privacy protections between a recursive resolver and
the root servers (low risk, low priority)
I get why DoT was changed in #2, but why was "DNS privacy protections" changed to "a
secure transport protocol"? Why were the risk and priority classifications removed?
This was after WG input last year, before the document became a -00 WG
draft. I have to go back to our notes how the comments were phrased
during the WG session. See also commits af63fc4 and 0a9f30e on GitHub
(https://github.com/alex-nicat/ietf-dprive-phase2-requirements/commits/master/draft-ietf-dprive-phase2-requirements.md).
Also, I'm not sure how these are requirements as written (e.g., they lack RFC
2119 key words). And, on whom or what are these requirements placed upon?
5. The secure transport MUST only be established when referential
integrity can be verified, MUST NOT have circular dependencies,
and MUST be easily analyzed for diagnostic purposes.
I think the "MUST NOT have circular dependencies" requirement should be further
explored (i.e., more text). Since item 9 below says that specification of preferences
must occur using DNS only, is that itself a circular dependency?
Also, could more be said about the "easily analyzed" part? "easily" might be
subjective, unless there is to be some way to quantify this requirement?
Correct, I think this text still reflects (too) closely the WG
discussion and should be formulated more strictly.
6. Use a secure transport protocol or other DNS privacy protections
in a manner that enables operators to perform appropriate
performance and security monitoring, conduct relevant research,
etc.
Again, not sure how this is a requirement or for whom it is a requirement. Does it mean
something like "use of secure transport protocols MUST NOT prevent operators [of
xxx] from performing appropriate performance and security monitoring, conducting
research, etc."?
Indeed. Maybe you can look at the current formulation on GitHub. I
will submit a new version before the submission deadline Monday, 2 November.
7. The authoritative domain owner or their administrator MUST have
the option to specify their secure transport preferences (e.g.
what specific protocols are supported). This SHALL include a
method to publish a list of secure transport protocols (e.g.
DoH, DoT and other future protocols not yet developed). In
addition this SHALL include whether a secure transport protocol
MUST always be used (non-downgradable) or whether a secure
transport protocol MAY be used on an opportunistic (not strict)
basis.
8. The authoritative domain owner or their administrator MUST have
the option to vary their preferences on an authoritative
nameserver to nameserver basis, due to the fact that
administration of a particular DNS zone may be delegated to
multiple parties (such as several CDNs), each of which may have
different technical capabilities.
Including that some servers for a domain may use secure transport and others
may not?
It is common for a given name server to be authoritative for multiple zones.
Should this document state that a name server can provide secure transport for
one zone but not another?
Correct, thanks.
9. The specification of secure transport preferences MUST be
performed using the DNS and MUST NOT depend on non-DNS
protocols.
10. For the secure transport, TLS 1.3 (or later versions) MUST be
supported and downgrades from TLS 1.3 to prior versions MUST not
occur.
It seems like #10 should be qualified with something like "For TLS-based
transports..." since there might be some future secure transport that is not based
on TLS?
Correct.
5.2. Optional Requirements
Optional Requirements is perhaps an oxymoron? Maybe "Recommendations" of some
kind?
Changed to Optional Features.
1. QNAME minimisation SHOULD be implemented in all steps of
recursion
2. DNSSEC validation SHOULD be performed
3. If an authoritative domain owner or their administrator indicates
that (1) multiple secure transport protocols are available or
that (2) a secure transport and insecure transport are available,
then per the recommendations in [RFC8305] (aka Happy Eyeballs) a
recursive server SHOULD initiate concurrent connections to
available protocols. Consistent with Section 2 of [RFC8305] this
would be: (1) Initiation of asynchronous DNS queries to determine
what transport protocols are supported, (2) Sorting of resolved
destination transport protocols, (3) Initiation of asynchronous
connection attempts, and (4) Establishment of one connection,
which cancels all other attempts.
To me this item about happy eyeballs feels out of place in this document, and I
worry that we are not fully aware of the amplification effects that can occur
from multiple layers of happy eyeballs.
For example, user clicks on www.example.com URL. Happy eyeballs browser looks up both A and AAAA records (maybe more with new stuff like HTTPS & SVCB). Happy eyeballs recursive sends queries to both IPv4 and IPv6 addresses of name server. That’s 2x2=4 queries for the single click. Now add secure transport happy eyeballs and it becomes 2x2xN for however many secure transports are given. IMO this needs further study and discussion before recommending it.
We changed this section also with feedback/text from others.
Thank you for your valuable feedback.
Best,
-- Benno
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
