[dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

[Christian Huitema]

We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
for the feedback!

-- Christian Huitema



 Forwarded Message 
Subject:New Version Notification for 
draft-huitema-dprive-dnsoquic-00.txt
Date:   Thu, 05 Mar 2020 20:46:29 -0800
From:   internet-dra...@ietf.org
To: Christian Huitema , Sara Dickinson
, Allison Mankin 




A new version of I-D, draft-huitema-dprive-dnsoquic-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dprive-dnsoquic
Revision: 00
Title: Specification of DNS over Dedicated QUIC Connections
Document date: 2020-03-05
Group: Individual Submission
Pages: 19
URL:
https://www.ietf.org/internet-drafts/draft-huitema-dprive-dnsoquic-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/
Htmlized: https://tools.ietf.org/html/draft-huitema-dprive-dnsoquic-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huitema-dprive-dnsoquic


Abstract:
This document describes the use of QUIC to provide transport privacy
for DNS. The encryption provided by QUIC has similar properties to
that provided by TLS, while QUIC transport eliminates the head-of-
line blocking issues inherent with TCP and provides more efficient
error corrections than UDP. DNS over QUIC (DoQ) has privacy
properties similar to DNS over TLS (DoT) specified in RFC7858, and
performance characteristics similar to classic DNS over UDP.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Alexey Melnikov's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Sara Dickinson]

> On 4 Mar 2020, at 18:44, Ben Schwartz  wrote:

> On Wed, Mar 4, 2020 at 8:32 AM Sara Dickinson  wrote:
> 
>> 
>> 
>> On 6 Feb 2020, at 16:52, Alexey Melnikov via Datatracker 
>> wrote:
>> 
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-dprive-bcp-op-08: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> I think this is a very useful document and I am looking forward to it
>> getting
>> published.
>> 
>> I support updated Ben’s DISCUSS.
>> 
>> **
>> * Note, that I am conducting an experiment when people aspiring to be*
>> * Area Directors get exposed to AD work ("AD shadowing experiment"). *
>> * As a part of this experiment they get to review documents on IESG  *
>> * telechats according to IESG Discuss criteria document and their*
>> * comments get relayed pretty much verbatim to relevant editors/WGs. *
>> * As an AD I retain responsibility in defending their position when  *
>> * I agree with it.   *
>> * Recipients of these reviews are encouraged to reply to me directly *
>> * about perceived successes or failures of this experiment.  *
>> **
>> 
>> The following comments were provided by Benjamin Schwartz <
>> bem...@google.com>:
>> 
>> Benjamin would have balloted *DISCUSS* on this document. He wrote:
>> 
>> This draft is close to ready, but it contains some elements that are not
>> appropriate for IETF publication or lack IETF consensus.
>> 
>> ## Section 1
>> 
>> Typo: “For example the user has a clear expectation of which resolvers have
>> visibility of their query data however this...” -> Add a period before
>> “however”.
>> 
>> 
>> Barry suggested this and additional grammatical improvements which I will
>> make.
>> 
>> 
>> Inappropriate subject matter:
>> 
>>It is an untested area that simply using a DNS
>>resolution service constitutes consent from the user for the operator
>>to process their query data.
>> 
>> This is legal speculation, not appropriate for IETF.  Strike this sentence.
>> 
>> 
>> I think this is an important point to make and no-one has contested this
>> at any point in the development of the draft (I suspect DPRIVE is a good
>> audience for anyone who would know any different).
>> 
>> RFC7626 already includes this text:
>> “To our knowledge, there are no specific privacy laws for DNS data, in any
>> country.  Interpreting general privacy laws like
>> [data-protection-directive] (European Union) in the context of DNS traffic
>> data is not an easy task, and we do not know a court precedent here.  See
>> an interesting analysis in [sidn-entrada].”
>> 
>> I’m more than happy to qualify the text in this document with a ’To our
>> knowledge, '…
>> 
> 
> I don't especially like the text in RFC 7626 either (do we really have IETF
> consensus on the ease or difficulty of reading particular laws?). However,
> I do think it's better than the text here.  "We do not know of a court
> precedent" is appropriately qualified, and the implied claim ("there is no
> court precedent") is close to factual in nature.  In contrast, "it is an
> untested area" sounds less like a fact, and more like a legal opinion or
> analysis offered by the IETF.

How about:

“We do not know of a court precedent relating to the question of whether simply 
using a DNS resolution service constitutes consent from the user for the 
operator to process their query data"

> 
>> 
>> Clarity:
>> 
>>Privacy considerations specifically
>>from the perspective of an end user ... are out of scope.
>> 
>> This seems confusing as written: surely it is the privacy of end users
>> (and not
>> of resolver operators) that this draft seeks to protect.  Please rephrase
>> or
>> omit this disclaimer.
>> 
>> 
>> I think this is trying to capture the point that there are additional
>> general considerations for an end user that an operator cannot control.
>> 
>> Suggest:
>> “Privacy considerations specifically from the perspective of an end user
>> (for example, choice of client software or resolver selection policies)"
>> 
> 
> I still don't understand.  Perhaps "Choices that are made exclusively by
> the end user ... are out of scope”?

WFM.

> 
> 
>> 
>> 
>> ## Section 5.1

Re: [dns-privacy] Barry Leiba's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Sara Dickinson]

> On 4 Mar 2020, at 21:32, Barry Leiba  wrote:
> 
> Hi, Sara, and thanks for the response.
> 
>>> — Section 5.1.1 —
>>> 
>>>  o  DNS-over-TLS [RFC7858] and [RFC8310].
>>>  o  DoH [RFC8484].
>>> 
>>> There’s no reason to hyphenate the former, and the latter should also be
>>> expanded here:
>>> 
>>> NEW
>>>  o  DNS over TLS [RFC7858] and [RFC8310].
>>>  o  DNS over HTTPS [RFC8484].
>>> END
>>> 
>>> Similarly, take the hyphens out of “DNS over DTLS” in the next paragraph, 
>>> and
>>> out of “DNS over TLS” throughout the document.
>> 
>> Depends which draft you look at :-(
>> RFC7858 uses DNS-over-TLS, RFC8484 uses DNS over HTTPS, other drafts also 
>> hyphenate….
>> 
>> I happen to find the hyphenated form improves readability but can live with 
>> removing it (or using
>> only the acronyms throughout) for consistency…..
> 
> OK... While I see no justification for hyphens (they're not compound
> modifiers or anything like that), it's just a comment, and if you like
> the hyphens then please leave them in.  The RPC will weigh in when
> they do their edits, and we can let them make the final decision.  :-)

Ack. 

> 
>>> — Section 8 —
>>> For a document such as this, the Security Considerations sectiin seems very
>>> meagre.  As the Sec ADs have not called this out, I’ll presume they think 
>>> it’s
>>> OK, and I won’t press the issue.  Perhaps all relevant information is 
>>> already
>>> elsewhere in the document.
>> 
>> Since this draft is really collecting together a set of existing techniques 
>> I think the feeling was that
>> the reference for each technique should cover the security issues… If there 
>> were any new issues
>> from combining specific techniques then they should be called out here but I 
>> don’t remember any
>> being raised.
> 
> OK, and that fits in with the Sec ADs thinking it's OK.  All good, and
> nothing to see here.

Thank you!

Sara. 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Suresh Krishnan's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Sara Dickinson]

> On 4 Mar 2020, at 13:54, Suresh Krishnan  wrote:
> 
> 
> 
>> On Mar 4, 2020, at 8:31 AM, Sara Dickinson  wrote:
>> 
>> 
>> 
>>> On 6 Feb 2020, at 05:33, Suresh Krishnan via Datatracker  
>>> wrote:
>>> 
>>> Suresh Krishnan has entered the following ballot position for
>>> draft-ietf-dprive-bcp-op-08: No Objection
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>>> 
>>> 
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> * Section 5.2.3.
>>> 
>>> I found Table 1 to be extremely confusing. It is not clear from the table
>>> whether all of the properties are concurrently applicable to a certain
>>> technique when an "X" appears there. e.g. TC has marks for Format 
>>> preserving,
>>> Prefix preserving, Reordering/Shuffling, and Random substitution. Some of 
>>> these
>>> seem to be mutually exclusive. It would be good if you can clarify.
>> 
>> That was the intention of the table. TC (TCPdpriv - described in detail in 
>> Appendix B.3) preserves both the format and the longest prefix match but 
>> uses a random replacement for the remainder of the address.
>> 
>> Alissa suggested moving the table to Appendix B so it is in the context of 
>> the more detailed definitions of the categories and the individual 
>> techniques. I think that is a good idea - do you think that would address 
>> your concern?
> 
> Thanks Sara. That would work.

Great - thank you!

Sara. ___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Mirja Kühlewind's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Sara Dickinson]

> On 4 Mar 2020, at 13:37, Mirja Kuehlewind  wrote:
> 
> Hi Sara,
> 
> Thanks for you replies. See below.
> 
> 
>> On 4. Mar 2020, at 14:30, Sara Dickinson  wrote:
>> 
>> 
>> 
>>> On 31 Jan 2020, at 10:45, Mirja Kühlewind via Datatracker 
>>>  wrote:
>>> 
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-dprive-bcp-op-08: No Objection
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>>> 
>>> 
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> A couple of small comments/questions:
>>> 
>>> 1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does 
>>> seem to
>>> be the case that normative language is used. I would recommend to actually 
>>> use
>>> normative language in this doc!
>>> 
>> 
>> There is one key instance of a SHOULD in section 5 which ripples through the 
>> entire document because it covers the requirement for the various 
>> mitigations. 
>> 
>> “This document does not specify policy - only best practice, however
>>  for DNS Privacy services to be considered compliant with these best
>>  practice guidelines they SHOULD implement (where appropriate) all:"
>> 
>> It is easy to miss though……
> 
> Ah, okay! Actually maybe something that can be stated more explicitly in the 
> intro to make sure people do miss that there are actually normative 
> requirements. (Didn’t re-read the intro, so it might well be that it is clear 
> already and I didn’t get it…)

Given this is the second or third time this has been raised I think that makes 
sense… How about adding this text immediately after the use of SHOULD in 
section 5”

“In other words these requirements are specified here as all being normative 
requirements, and are only classified by different levels of compliance in the 
rest of the document."

>> 
>>> 
>>> 2) Can you actually provide references for the techniques listed in Table 1?
>> 
>> Do you mean the Categorization/Properties or the actual techniques listed? 
>> The latter are described in detail in Appendix B.
> 
> Ah, I didn’t match that on my read. Maybe just add a reference go Appendix B 
> then?

In fact based on other comments the whole table is going to be moved to 
Appendix B and updated slightly which should make it much clearer I hope!

> 
>> 
>>> 
>>> 3) Sec 5.1.3.1:
>>> “A DNS-over-TLS privacy service on both port 853 and 443.  This
>>>practice may not be possible if e.g. the operator deploys DoH on
>>>the same IP address.”
>>> Isn’t 443 basically DoH?
>> 
>> No, this means using the DNS-over-TLS protocol, just on port 443 by prior 
>> agreement between client and server (RFC7858 describes this). No HTTPS 
>> involved.
> 
> I there is no http, I don’t think this document should recommend use fo 443. 
> See further below. 
>> 
>>> Why would you deploy DoT over 853?
> 
> Sorry I meant 443...
> 
> 
>>> Is that a common practice? Sorry if I miss something…
>> 
>> Port 853 is the IANA assigned port for DoT. Before DoH was a thing, it was 
>> suggested that running DoT on 443 would prevent issues where port 853 might 
>> be blocked - several early DoT services did this. 
> 
> I was guessing that, but I’m not connivence we should support that in an RFC 
> (given we have DoH on 443 now as well).

There was actually quite some discussion on the DPRIVE list back in December 
about using port 443 because RFC7858 allowed it and there are use cases for it. 
The result was registering an ALPN for DoT:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
 

A separate IESG comment suggested adding the reference to that registration 
here which I agree with and that case it seems reasonable to leave this in the 
document?

Best regards

Sara. 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 3 Mar 2020, at 11:34, Vittorio Bertola  
> wrote:
> 
> 
>> Il 02/03/2020 16:16 Sara Dickinson  ha scritto:
>> 
>> Suggest: 
>> 
>> "For users to have the ability to inspect and control the 
>> application-specific DNS settings in a similar fashion to the OS DNS 
>> settings, each application also needs to: 
>> 
>>o  expose the default settings to the user 
>> 
>>o  provide configuration options to manually override the default 
>> settings so that resolution is performed via
>>   * user specified resolvers
>>   * the resolvers configured into the system settings
>>   * the system resolver via conventional API calls
>> 
>> If all such applications are updated to use the system resolver, as 
>> described in the last bullet point, the device reverts to a single point of 
>> control for all DNS queries."
> I don't want to nitpick, but I'd point out that from the policy/privacy 
> viewpoint what is important is which resolver is used, not (as long as it 
> does not add any specific new privacy risk) the interface used to contact it 
> - so the second and third "*" bullets are functionally equivalent and it 
> would be fine if an application provided only either one of the two. 

You are broadly correct,  but there are some small differences in that for the 
second bullet point not all applications may offer the preferred transport 
(e.g. most browsers don’t support DoT but my preferred resolver might only 
support DoT) or config options e.g. to omit the User-agent HTTP header. It will 
also mean X different applications making X different connections to the 
resolver (which could reveal the set of applications the user has installed). 
Whereas if everything goes through the system resolver the device appears to 
the resolver as a single source of queries using a set of connections managed 
only from the system resolver. 

> 
> In theory, one could say that the two interfaces are not completely 
> privacy-equivalent, since the use of the system API introduces one more party 
> that gets access to data, i.e. the operating system - so one could argue that 
> applications should bypass the OS to prevent it from spying over the user's 
> DNS traffic, exactly like they do with the network. If this is what we want 
> to argue, then we should remove the last "*" bullet. However, exactly as the 
> network, the OS might want to exert some general policy over the user's DNS 
> traffic, such as monitoring infections or filtering specific destinations, so 
> I don't know if such a recommendation would be beneficial in the end. 


This is an interesting point! Note that a user may want to use the system 
resolver as a point to monitor their own traffic. For example, having multiple 
sources of DNS queries doesn’t necessarily provide the same ability to 
troubleshoot issues as a single component does, or (more importantly) to 
inspect the encrypted traffic leaving the machine. Firefox nicely allows users 
to export session keys so the traffic can be decrypted locally (and also 
provides an interface to look at the DNS results), but if an application 
doesn’t offer this then the user may have no ability to easily see their own 
DNS traffic. I’ve thought in the past of proposing this as an additional option 
for the applications (and in future on any OS that implements an encrypted 
transport) but didn’t follow up.

Sara. 


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Sun, Dec 15, 2019 at 07:33:04AM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 35 lines which said:

> Title   : DNS Privacy Requirements for Exchanges between 
> Recursive Resolvers and Authoritative Servers
> Authors : Jason Livingood
>   Alexander Mayrhofer
>   Benno Overeinder
>   Filename: draft-ietf-dprive-phase2-requirements-00.txt

>  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

It is not clear why there is a specific requirment for root and TLD
auth. servers. Why not just "Use a secure transport protocol between a
recursive resolver and the authoritative nameservers"? Is it because
it is not expected that example.com or other SLD won't have secure
transport soon?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy