Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-01.txt

[Benno Overeinder <[e-mail]>]

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