Re: [dns-privacy] Paul Wouters' Abstain on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

[Eric Vyncke (evyncke)]

Paul, thank you for reconsidering (and explaining) your ballot position.

Authors, do you intend to submit a revise I-D to take into account the IESG 
comments ?

Thanks to all

-éric

From: dns-privacy  on behalf of Paul Wouters via 
Datatracker 
Date: Thursday, 5 October 2023 at 20:46
To: The IESG 
Cc: draft-ietf-dprive-unilateral-prob...@ietf.org 
, dprive-cha...@ietf.org 
, dns-privacy@ietf.org , 
br...@innovationslab.net , tjw.i...@gmail.com 
, br...@innovationslab.net 
Subject: [dns-privacy] Paul Wouters' Abstain on 
draft-ietf-dprive-unilateral-probing-12: (with COMMENT)
Paul Wouters has entered the following ballot position for
draft-ietf-dprive-unilateral-probing-12: Abstain

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/



--
COMMENT:
--

Based on the authors response to my DISCUSS
(https://mailarchive.ietf.org/arch/msg/dns-privacy/mVGvnh3g0Z9O70XeguVNUx59SYk/),
I have updated by ballot to ABSTAIN.

I do not see any use of this draft. In its regular use, the user is still
sending their queries in the clear initially. The draft assumes that after the
initial leak, queries for the same target will be encrypted opportunistically.
I tried pointing out that on most mobile devices, this is not the case due to
frequent network changes and DNS cache purges. Any Operational or Security
Considerations related to this were deemed out of scope. I can only conclude
that no privacy is gained, and that the additional complexity in code is not
worth the effort of implementing.

Additionally, since the draft requires the DNS servers to generate a
certificate, the difference between generating a self-signed certificate, and
using an ACME based certificate that CAN be validated and wouldn't need
unilateral opportunistic security, I see even less reasons to attempt to deploy
this.

As no indications are given back to the user, the draft does the enduser no
harm (other than possibly introducing bugs due to added complexity on the code)
and I see no reason to further block it with a DISCUSS.



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

Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09

[Eric Vyncke (evyncke)]

Hello Paul,

Thanks for your reply, look below for EV2> but, in short, we are all set 
*except* for the shepherd's write-up .

Regards

-éric

On 05/08/2023, 02:53, "Paul Hoffman" mailto:paul.hoff...@icann.org>> wrote:


On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) 
mailto:40cisco@dmarc.ietf.org>> wrote:
> # Shepherd's write-ip
> 
> 
> The shepherd's write-up states "the WG would like to ensure that this list 
> remains in the document once it is published as an RFC" but the appendix A 
> states "RFC Editor: please remove this section before publication". I.e., the 
> shepherd's write-up and the I-D MUST be coherent ;-)
> 
> EV> we do need the shepherd's write-up and I-D being consistent on this 
> point. *Let me know when either the shepherd's write-up or the I-D is 
> modified.*


You and the shepherd are already discussing this on the mailing list.

EV2> I guess you meant "we" and not "you", but whatever we need a resolution 
for this.

> # Section 1.1
> 
> I am always uneasy with the use of BCP14 normative language outside of a 
> standard track or BCP document.
> 
> EV> I have read Paul's reply, as long as authors are aware, let it be. Expect 
> some non-blocking comments by some ADs during the IESG evaluation.


This is a ripe topic for a statement from the various RFC stream managers so 
that we document authors will know what to expect. I do hope those comments are 
non-blocking.


EV2> of course this is not blocking, sorry if I was not clear.

> # Section 3
> 
> This was probably discussed over the mailing list, but must DoT & DoQ replies 
> be also identical to Do53 replies ? The current text is a little 
> underspecified.
> 
> Paul> The last paragraph of Section 3 says "An authoritative server 
> implementing DoT or DoQ MUST authoritatively serve the same zones over all 
> supported transports." How should we say that differently to be more specfied?
> 
> EV> I still find the text a little unclear about the returned DNS replies 
> (e.g., the answer section must be identical in Do53 and DoT). I am leaving 
> the choice to the authors about whether to add further clarification text.


Got it: "serve the same zones" versus "have the same replies". We'll make that 
change in -10.

EV2> Thanks

> # Section 3.5
> 
> Expect some comments during the IESG review if the SHOULDs do not have some 
> wording about when the SHOULDs does not apply.
> 
> EV> thanks, Paul, for explaining the somehow convoluted/complex clause "this 
> might be limited by e.g. not receiving an EDNS(0) option in the query". You 
> may consider rendering it easier to parse though.


Sure, I'll make a run at that for -10 as well.


> # Section 4.2
> 
> Is there any chance to also use an IPv6 example ? 
> 
> EV> Obviously, there was no chance ;-)


We chose to keep the examples consistent with each other.

EV2> fait enough, though the 2 examples could be IPv6 ;-) (kidding here)

I'll prep a -10, and we'll submit it next week. 


--Paul Hoffman

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

Re: [dns-privacy] AD review of draft-ietf-dprive-unilateral-probing-09

[Eric Vyncke (evyncke)]

Thank you for the -10 revision and its multiple changes.

Alas, it seems that some points below are not fully addressed either by email 
or in the I-D. See the elided text below, looking for EV>

The only critical one is the discrepancy between the shepherd's write up point 
4 and the I-D appendix A. This MUST be resolved before the IETF Last Call.

(and sorry for the Outlook look of my reply ☹ ...)

Regards, I sincerely hope that this thread has improved the quality of the 
document.

-éric

On 17/07/2023, 14:06, "Eric Vyncke (evyncke)" mailto:evyn...@cisco.com>> wrote:

...

# Shepherd's write-ip


The shepherd's write-up states "the WG would like to ensure that this list 
remains in the document once it is published as an RFC" but the appendix A 
states "RFC Editor: please remove this section before publication". I.e., the 
shepherd's write-up and the I-D MUST be coherent ;-)

EV> we do need the shepherd's write-up and I-D being consistent on this point. 
*Let me know when either the shepherd's write-up or the I-D is modified.*

# Section 1.1

I am always uneasy with the use of BCP14 normative language outside of a 
standard track or BCP document.

EV> I have read Paul's reply, as long as authors are aware, let it be. Expect 
some non-blocking comments by some ADs during the IESG evaluation.

# Section 3

This was probably discussed over the mailing list, but must DoT & DoQ replies 
be also identical to Do53 replies ? The current text is a little underspecified.

Paul> The last paragraph of Section 3 says "An authoritative server 
implementing DoT or DoQ MUST authoritatively serve the same zones over all 
supported transports." How should we say that differently to be more specfied?

EV> I still find the text a little unclear about the returned DNS replies 
(e.g., the answer section must be identical in Do53 and DoT). I am leaving the 
choice to the authors about whether to add further clarification text.

# Section 3.5

Expect some comments during the IESG review if the SHOULDs do not have some 
wording about when the SHOULDs does not apply.

EV> thanks, Paul, for explaining the somehow convoluted/complex clause "this 
might be limited by e.g. not receiving an EDNS(0) option in the query". You may 
consider rendering it easier to parse though.

# Section 4.2

Is there any chance to also use an IPv6 example ? 

EV> Obviously, there was no chance ;-)












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

Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09

[Eric Vyncke (evyncke)]

Thank you, Paul, Joey, Daniel, for the -10.

As you can guess, I won't have time to review the -10 and the email thread 
before next week __

Regards

-éric

On 27/07/2023, 08:18, "Paul Hoffman" mailto:paul.hoff...@icann.org>> wrote:


Please see the -10 that was just submitted. Let us know if we need to make more 
changes before you want to move this on to IETF Last Call.


--Paul Hoffman (for dkg and Joey as well)





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

[dns-privacy] AD review of draft-ietf-dprive-unilateral-probing-09

[Eric Vyncke (evyncke)]

Dear authors, dear DPRIVE WG,

Thank you for the hard work done on this document, it was not an easy ride, but 
the WG has reached consensus, and the change of intended status also fits the 
charter.

As usual, I have done an AD review of draft-ietf-dprive-unilateral-probing-09 
before going forward with the publication process (i.e., the IETF Last Call). 
Please find below some points, I expect a reply or an action on all of them 
(except when noted) before the requesting the IETF Last Call.

Regards and even if DPRIVE does not meet in San Francisco for IETF-117, I will 
be there, so feel free to have a chat

-éric

# Shepherd's write-ip

The shepherd's write-up states "the WG would like to ensure that this list 
remains in the document once it is published as an RFC" but the appendix A 
states "RFC Editor: please remove this section before publication". I.e., the 
shepherd's write-up and the I-D MUST be coherent ;-)

# Section 1

Section 1 mentions "Internet ecosystem" while the abstract is about "DNS 
ecosystem", perhaps worth using the same terms ?

Is it about ` provide guidance to implementers` or more about ` provide 
guidance to DNS operators` or both ?

# Section 1.1

I am always uneasy with the use of BCP14 normative language outside of a 
standard track or BCP document.

# Section 1.2

Is 'deployment' required in `capable of opportunistic probing deployment` ?

` DoQ, DoT, and DoH collectively` but section 2.2 states later ` This document 
does not pursue the use of DoH in this context`

# Section 2.1

Should there be a more suitable wording for an experimental draft than ` This 
protocol aims`?

In the same vein, but this time it MUST be reworded ` This protocol specifies 
the use of DoT and DoQ`

# Section 3

This was probably discussed over the mailing list, but must DoT & DoQ replies 
be also identical to Do53 replies ? The current text is a little underspecified.

Please expand ALPN at first use.

# Section 3.1

` within the span of a few seconds` is rather vague. Should this be rephrased 
in "less than 30 seconds" (or whatever) ? Else, I fear some comments during the 
IESG review ;-)

# Section 3.2

In ` The simplest deployment would simply provide a self-issued, 
regularly-updated X.509 certificate` is the intent to use short-lived 
certificates ? Or more to state "valid certificate" ? The text would benefit 
from clarity.

# Sections 3.4, 3.5, and 3.6

Those 3 sections introduce some context explained later in the section 4.6. 
Suggest adding a forward internal reference to those sub-section on 4.6 (else 
it looks like repetition).

# Section 3.5

Expect some comments during the IESG review if the SHOULDs do not have some 
wording about when the SHOULDs does not apply.

# Section 4.1

I am not a native English speaker, but I find ` the recently-good encrypted 
transport` weird... Is it good English ?

` falls back to Do53 for that tuple` but this won't be a tuple anymore as it is 
merely clientIP, serverIP.

# Section 4.2

` or worse, filters the incoming traffic and does not even respond with an ICMP 
port closed message` I would assume that some authoritative servers would apply 
rathe limiting to ICMP to prevent a reflection attack.

Is there any chance to also use an IPv6 example ? 

# Section 4.4

Unsure whether the last paragraph has any value... ` a recursive resolver 
implementing these strategies SHOULD also accept queries from its clients over 
some encrypted transport (current common transports are DoH or DoT).
` Also, is DoH in scope for the communication to its client ?

# Section 4.5

This section is somehow mixing up text where the ClientIP is required in the 
tuple and sometimes not. The section 4.5.1 clarifies the text of course but 
comes a little late for the reader. Should the text in 4.5.1 be moved to the 
beginning of section 4.5 ?

As for section 4.2, an IPv6 example would be more modern.

# Section 4.6

It is a little unclear whether it is the client or server in ` using IP address 
X`.

# Section 4.6.3.3

The reference to ECH should be normative as there is no way to implement the 
RECOMMENDED action of this document w/o the ECH draft. This is of course 
annoying as the ECH I-D seems to be lingering and this would cause a delayed 
cluster.

# Section 4.6.10

Only one prioritization scheme in this section while there were two in section 
3.4

# Appendix B

"DoE" is not expanded (even if guessable)

Are the measurements to be done on the recursive resolver and/or the 
authoritative server ?

# NITS

AFAIK, 'e.g.' is always surrounded by commas. And "instead" and "for example" 
are also followed by a comma.

In US-English, I think it is "signaling" with a single 'el' 

# Section 4.6.12 

s/ RTT (round trip time)/ Round Trip Time (RTT)/








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

Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

[Eric Vyncke (evyncke)]

Daniel, Joey, Paul,

As I am doing my AD review, may I check with the 3 authors whether they are 
aware of any IPR behind the one cited by Brian below ?

Thanks, in advance,

-éric


On 07/07/2023, 15:03, "dns-privacy on behalf of Brian Haberman" 
mailto:dns-privacy-boun...@ietf.org> on behalf 
of br...@innovationslab.net > wrote:


Hi all,
I am in the process of preparing the shepherd writeup for this 
draft as a part of advancing it to the IESG for publication. Part of 
that process involves verifying any/all IPR declarations on the 
document. At this point, there is one IPR declaration.


https://datatracker.ietf.org/ipr/5904/ 


The purpose of this mail is to determine if any WG participant is 
aware of other potential IPR claims. I ask that those declarations be 
made now. Late declarations have caused a number of issues with document 
publication.


Regards,
Brian




On 3/12/23 11:43 AM, Brian Haberman wrote:
> All,
> This starts a 2-week WGLC for 
> draft-ietf-dprive-unilateral-probing-05. This call is to determine if 
> the document is sufficiently complete to facilitate implementations and 
> interoperability testing. Once that determination is made, the chairs 
> will park this document in the datatracker with a state of "Waiting for 
> Implementation" and we will await for the requested implementations and 
> interoperability reports.
> 
> The chairs will note that the document is currently marked as 
> Proposed Standard and that there has been a suggestion to move it to 
> Experimental. If you have an opinion on the status at this time, please 
> include it in your feedback to the WG mailing list. We will revisit the 
> status of the document before it gets advanced to our AD.
> 
> This WGLC will end at midnight UTC on March 26, 2023.
> 
> Regards,
> Brian & Tim



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

Re: [dns-privacy] [Ext] Intended Status for draft-ietf-dprive-unilateral-probing

[Eric Vyncke (evyncke)]

Hello Scott,

If the document is backed by 2 (or more) interoperable implementations, then I 
am sure that the IESG (and myself as the responsible AD) will see no problem in 
the document intended status change. Unusual but this won't be an issue.

Regards

-éric

From: dns-privacy  on behalf of "Hollenbeck, 
Scott" 
Date: Friday, 3 March 2023 at 19:13
To: "tjw.i...@gmail.com" 
Cc: "paul.hoff...@icann.org" , "dpr...@ietf.org" 

Subject: Re: [dns-privacy] [Ext] Intended Status for 
draft-ietf-dprive-unilateral-probing

From: Tim Wicinski 
Sent: Friday, March 3, 2023 12:59 PM
To: Hollenbeck, Scott 
Cc: paul.hoff...@icann.org; dpr...@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Intended Status for 
draft-ietf-dprive-unilateral-probing


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

All

As Brian and I have stated a few times, and Eric our AD has supported, the plan 
with this draft is once the authors
are ready is to take it to WGLC, and then park it while we wait for 
implementations, and some signs of interoperability
testing.  Once we and the working group feel there has been reasonable 
progress, we will un-park the document.

At the time we un-park it to move it to the IESG we can have the discussion 
about Standards Track, Experimental, or
Informational.  To have that discussion now serves no real purpose (in my mind).

The chairs will however hold the document status as something for the WG to 
decide on.
[SAH] Will that include potential revision of the working group charter if the 
working group decides to deviate from Experimental?

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

[dns-privacy] Chairs of DNS directorate

[Eric Vyncke (evyncke)]

Some news about the DNS directorate as Warren and I were finally able to 
synchronize our travels/vacations to work on the DNS directorate.

We have received more than 50 volunteers: thanks to all of them !

The first step was to select the chairs of the directorate to have different 
geo-location and expertise: Geoff Huston and Jim Reid. Thank you very much to 
Geoff and Jim for accepting this important role.

Our goal is to have a small directorate (about 20 members) but with a good 
balance among technical/policy domains, seniority, location, ... You should 
hear more from Warren, the chairs, and I in the coming days.

Best regards

-éric


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

[dns-privacy] FW: [DNSOP] DNS Directorate...

[Eric Vyncke (evyncke)]

Just to keep you aware about DNS directorate.

When Warren and I made the planning for DNS-directorate, we did not check our 
respective travel plans [1]. I.e., now both of us have a (lame ?) excuse to be 
late. As written by Warren below, having 40 directorate members is too many, so 
we need to hand pick among the volunteers to have diverse views on DNS (e.g., 
implementers, deployment, security, RIR, ...)

Hope to get things done for mid-October (as I am going on vacations mode for 
one week...)

Regards and thanks for your patience

-éric

[1] we are never the same week in our home office... and mainly on meetings

From: DNSOP  on behalf of Warren Kumari 

Date: Saturday, 24 September 2022 at 03:54
To: dnsop 
Subject: Re: [DNSOP] DNS Directorate...

Just a very quick followup to this.

Thank you everyone who volunteered — Eric Vynke and I were pleasantly surprised 
by just how many volunteers we got ( > 40!).
Actually, we seem to have a few too many volunteers; at some point a large 
directorate becomes unwieldy, and so he and I are trying to find some time to 
chat and figure out how to narrow down the slate some (this has been made 
slower by travels and such).

Didn't want to leave y'all hanging, and we hope to have this wrapped up soon.

Thank you again,
W



On Tue, Sep 13, 2022 at 3:18 AM, Warren Kumari 
mailto:war...@kumari.net>> wrote:
Hi there all,

At IETF 114 I mentioned that Eric Vynke and I were planning on creating a DNS 
Directorate. Unfortunately  we got a little busy, and so it took a bit longer 
than expected, but we've finally had a chance to write up a "charter" (below).

A number of people have already kindly offered to participate, but we'd like 
some more, so, if you are willing, please fill in this form - 
https://forms.gle/GDffKp2XuT9acK9T6  - this will add your info to a (private) 
spreadsheet so that Eric and I don't accidentally miss an email. If you have 
already volunteered, please fill it in anyway, just to make sure we didn't miss 
your mail…

As usual, we are not looking only for "the" experts on DNS (even if those are 
welcome), but also for volunteers with good understanding of DNS security, 
privacy, operations, implementing, scalability, ... even if 'new' at the IETF. 
If you are willing to dedicate some time to review early drafts for the benefit 
of the IETF community: please step forward !

Thank you,
W

-
# DNS Directorate Charter (draft)

DNS directorate reviewers assist Area Directors, Working Group chairs, and 
document authors with documents containing DNS-related content.
More detailed guidance on DNS directorate process can be found at: 
http://wiki.ietf.org/group/dnsdir

WG chairs or responsible ADs may request a DNS directorate review via the 
draft's Datatracker page. They are encouraged to do so as early in the process 
as possible to ensure that structural concerns are caught early in the document 
development.
The DNS directorate secretaries will assign reviews to reviewers, but they are 
not required to check the list of IETF drafts for DNS-related ones.
The DNS directorate reviews will be sent to the DNS Directorate mailing list 
(dns...@ietf.org), draft authors, WG chairs, and the 
respective AD.
The DNS directorate reviewers and secretary are volunteers, and serve at the 
pleasure of the INT and OPS area ADs.


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

[dns-privacy] DNS-directorate, looking for volunteers

[Eric Vyncke (evyncke)]

Dear all,



At IETF 114, I mentioned that Warren Kumari and I were planning on creating a 
DNS Directorate. Unfortunately, we got a "little" busy (including some holidays 
) , and so it took a bit longer than expected, but we've finally had a chance 
to write up a "charter" (below).



A number of people have already kindly offered to participate, but we'd like 
some more, so, if you are willing, please fill in this form - 
https://forms.gle/GDffKp2XuT9acK9T6  - this will add your info to a (private) 
spreadsheet so that Warren and I don't accidentally miss an email. If you have 
already volunteered, please fill it in anyway, just to make sure we didn't miss 
your mail…



As usual, Warren and I are not looking only for "the" experts on DNS (even if 
those are welcome), but also for volunteers with good understanding of DNS 
security, privacy, operations, implementing, scalability, ... even if 'new' at 
the IETF. If you are willing to dedicate some time to review early drafts for 
the benefit of the IETF community: please step forward ! Warning though, as 
usual at the IETF, the salary is impressive 0 EUR = 0 USD = 0 CAD = ... 



Thank you



-éric

-warren



# DNS Directorate Charter (draft)



DNS directorate reviewers assist Area Directors, Working Group chairs, and 
document authors with documents containing DNS-related content. More detailed 
guidance on DNS directorate process can be found at: 
http://wiki.ietf.org/group/dnsdir



WG chairs or responsible ADs may request a DNS directorate review via the 
draft's Datatracker page. They are encouraged to do so *as early in the process 
as possible* to ensure that structural concerns are caught early in the 
document development.



The DNS directorate secretaries will assign reviews to reviewers, but the 
secretaries are not required to check the list of IETF drafts for DNS-related 
ones.



The DNS directorate reviews will be sent to the DNS Directorate mailing list 
(creation in progress), draft authors, WG chairs, and the respective AD.



The DNS directorate reviewers and secretary are volunteers and serve at the 
pleasure of the INT and OPS area ADs.






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

Re: [dns-privacy] dprive - Cancelling a meeting request for IETF 114

[Eric Vyncke (evyncke)]

Indeed,

Thank you Tim for the added piece of information

-éric


From: dns-privacy  on behalf of Tim Wicinski 

Date: Friday, 1 July 2022 at 23:14
To: DNS Privacy Working Group 
Cc: DPRIVE chairs , Eric Vyncke 
Subject: Re: [dns-privacy] dprive - Cancelling a meeting request for IETF 114


FYI

The DPRIVE session isn't being cancelled, but we're sharing time with the folks 
in ADD.

tim


On Fri, Jul 1, 2022 at 5:00 PM IETF Meeting Session Request Tool 
mailto:session-requ...@ietf.org>> wrote:


A request to cancel a meeting session has just been submitted by Liz Flynn, on 
behalf of the dprive working group.

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

Re: [dns-privacy] RFC 9250 on DNS over Dedicated QUIC Connections

[Eric Vyncke (evyncke)]

Congratulations to the authors, shepherd, chairs, and the whole DPRIVE WG for 
this important milestone.

Regards,

-éric


-Original Message-
From: dns-privacy  on behalf of 
"rfc-edi...@rfc-editor.org" 
Date: Thursday, 12 May 2022 at 01:36
To: "ietf-annou...@ietf.org" , 
"rfc-d...@rfc-editor.org" 
Cc: "rfc-edi...@rfc-editor.org" , 
"drafts-update-...@iana.org" , 
"dns-privacy@ietf.org" 
Subject: [dns-privacy] RFC 9250 on DNS over Dedicated QUIC Connections

A new Request for Comments is now available in online RFC libraries.


RFC 9250

Title:  DNS over Dedicated QUIC Connections 
Author: C. Huitema,
S. Dickinson,
A. Mankin
Status: Standards Track
Stream: IETF
Date:   May 2022
Mailbox:huit...@huitema.net,
s...@sinodun.com,
allison.man...@gmail.com
Pages:  27
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dprive-dnsoquic-12.txt

URL:https://www.rfc-editor.org/info/rfc9250

DOI:10.17487/RFC9250

This document describes the use of QUIC to provide transport
confidentiality for DNS. The encryption provided by QUIC has similar
properties to those provided by TLS, while QUIC transport eliminates
the head-of-line blocking issues inherent with TCP and provides more
efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has
privacy properties similar to DNS over TLS (DoT) specified in RFC
7858, and latency characteristics similar to classic DNS over UDP.
This specification describes the use of DoQ as a general-purpose
transport for DNS and includes the use of DoQ for stub to recursive,
recursive to authoritative, and zone transfer scenarios.

This document is a product of the DNS PRIVate Exchange Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

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

Re: [dns-privacy] [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)

[Eric Vyncke (evyncke)]

Let me loop in the TSV Area Directors as they may share my view that 
DNS-over-DTLS should be kept in the IANA registry

-éric


-Original Message-
From: Sara Dickinson 
Date: Saturday, 9 April 2022 at 17:47
To: "drafts-appro...@iana.org" 
Cc: "tjw.i...@gmail.com" , "huit...@huitema.net" 
, Eric Vyncke , Erik Kline 
, "dns-privacy@ietf.org" , 
"br...@innovationslab.net" , 
"allison.man...@gmail.com" 
Subject: Re: [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC 
Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)

Hi Amanda,

Thank you - all the changes look correct but we have one minor request. 

Given that DNS-over-DTLS has been removed from the port 853 TCP entry 
‘description' field, it seems correct to also remove the reference to RFC8094 
from the ‘reference’ field for consistency. Could that change please be made?

Best regards

Sara. 

>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: tcp
>> Description: DNS query-response protocol run over TLS
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>>   Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094]

> On 8 Apr 2022, at 20:34, Amanda Baber via RT  
wrote:
> 
> Dear Authors,
> 
> This is a reminder that we need a reply to the message below.
> 
> Best regards,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Sat Apr 02 01:06:51 2022, amanda.baber wrote:
>> Dear Authors:
>> 
>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED
>> 
>> We've completed the registry actions for the following RFC-to-be:
>> 
>> draft-ietf-dprive-dnsoquic-11
>> 
>> ACTION 1:
>> 
>> The following entry has been added to the TLS Application-Layer
>> Protocol Negotiation (ALPN) Protocol IDs registry:
>> 
>> DoQ 0x64 0x6F 0x71 ("doq")  [RFC-ietf-dprive-dnsoquic-11]
>> 
>> Please see
>> https://www.iana.org/assignments/tls-extensiontype-values
>> 
>> ACTION 2:
>> 
>> An additional reference and an updated description have been listed
>> for UDP port 853, and the word "DTLS" has been removed from the
>> description of the corresponding TCP port. These two registrations now
>> read as follows:
>> 
>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: tcp
>> Description: DNS query-response protocol run over TLS
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>>   Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094]
>> 
>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: udp
>> Description: DNS query-response protocol run over DTLS or QUIC
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>> Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094][RFC-ietf-dprive-dnsoquic-11]
>> 
>> Please see
>> https://www.iana.org/assignments/service-names-port-numbers
>> 
>> ACTION 3:
>> 
>> The following entry has been added to the Extended DNS Error Codes
>> registry:
>> 
>> 26  Too Early   [RFC-ietf-dprive-dnsoquic-11]
>> 
>> Please see
>> https://www.iana.org/assignments/dns-parameters
>> 
>> ACTION 4:
>> 
>> The following registry has been created under the "Domain Name System
>> (DNS) Parameters" heading:
>> 
>> DNS over QUIC Error Codes
>> Expert(s): Unassigned
>> Reference: [RFC-ietf-dprive-dnsoquic-11]
>> Available Formats
>> 
>> Range   Registration Procedures
>> provisional (greater than 0x3f) Expert Review
>> provisional registration Date field update  First Come First
>> Served
>> permanent, 0x00-0x3fStandards Action or IESG Approval
>> permanent, greater than 0x3fSpecification Required
>> 
>> Value   Error   Description Status  Specification   Date
>> Contact
>> 
>> 0x0 DOQ_NO_ERRORNo errorpermanent   [RFC-ietf-
>> dprive-dnsoquic-11, Section 5.3]  2022-04-01  [DPRIVE_WG]
>> 
>> 0x1 DOQ_INTERNAL_ERROR  Implementation errorpermanent
>> [RFC-ietf-dprive-dnsoquic-11, Section 5.3]  2022-04-01
>> [DPRIVE_WG]
>> 
>> 0x2 DOQ_PROTOCOL_ERROR  Generic protocol violation
>> permanent   [RFC-ietf-dprive-dnsoquic-11, Section 5.3]  2022-
>> 04-01  [DPRIVE_WG]
>> 
>> 0x3 DOQ_REQUEST_CANCELLED   Request cancelled by client
>> permanent   [RFC-ietf-dprive-dnsoquic-11, Section 5.3]  2022-
>> 04-01  [DPRIVE_WG]
>> 
>> 0x4 DOQ_EXCESSIVE_LOAD  Closing a connection for excessive
>> load permanent   [RFC-ietf-dprive-dnsoquic-11, Section 5.3]
>> 2022-04-01  [DPRIVE_WG]
>> 
>> 0x5 

Re: [dns-privacy] [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)

[Eric Vyncke (evyncke)]

Thank you, Sara, for the clarification.

Regards

-éric


-Original Message-
From: Sara Dickinson 
Date: Monday, 11 April 2022 at 15:39
To: Eric Vyncke 
Cc: "drafts-appro...@iana.org" , Martin Duke 
, Zaheduzzaman Sarker 
, "tjw.i...@gmail.com" , 
"huit...@huitema.net" , Erik Kline , 
"dns-privacy@ietf.org" , "br...@innovationslab.net" 
, "allison.man...@gmail.com" 

Subject: Re: [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC 
Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)

Just to clarify the request is remove the RFC8094 reference against the TCP 
port assignment (because the description was modified to remove DTLS from this 
port description). DNS-over-DTLS  would remain listed against the UDP port 
assignment as previously agreed, and as listed below.

Sara. 

> On 11 Apr 2022, at 14:15, Eric Vyncke (evyncke)  wrote:
> 
> Let me loop in the TSV Area Directors as they may share my view that 
DNS-over-DTLS should be kept in the IANA registry
> 
> -éric
> 
> 
> -Original Message-
> From: Sara Dickinson 
> Date: Saturday, 9 April 2022 at 17:47
> To: "drafts-appro...@iana.org" 
> Cc: "tjw.i...@gmail.com" , "huit...@huitema.net" 
, Eric Vyncke , Erik Kline 
, "dns-privacy@ietf.org" , 
"br...@innovationslab.net" , 
"allison.man...@gmail.com" 
> Subject: Re: [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC 
Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)
> 
>Hi Amanda,
> 
>Thank you - all the changes look correct but we have one minor 
request. 
> 
>Given that DNS-over-DTLS has been removed from the port 853 TCP entry 
‘description' field, it seems correct to also remove the reference to RFC8094 
from the ‘reference’ field for consistency. Could that change please be made?
> 
>Best regards
> 
>Sara. 
> 
>>> Service Name: domain-s
>>> Port Number: 853
>>> Transport Protocol: tcp
>>> Description: DNS query-response protocol run over TLS
>>> Assignee: [IESG]
>>> Contact: [IETF Chair]
>>> Registration Date: 2015-10-08
>>>  Modification Date: 2022-04-01
>>> Reference: [RFC7858][RFC8094]
> 
>> On 8 Apr 2022, at 20:34, Amanda Baber via RT  
wrote:
>> 
>> Dear Authors,
>> 
>> This is a reminder that we need a reply to the message below.
>> 
>> Best regards,
>> 
>> Amanda Baber
>> IANA Operations Manager
>> 
>> On Sat Apr 02 01:06:51 2022, amanda.baber wrote:
>>> Dear Authors:
>>> 
>>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED
>>> 
>>> We've completed the registry actions for the following RFC-to-be:
>>> 
>>> draft-ietf-dprive-dnsoquic-11
>>> 
>>> ACTION 1:
>>> 
>>> The following entry has been added to the TLS Application-Layer
>>> Protocol Negotiation (ALPN) Protocol IDs registry:
>>> 
>>> DoQ 0x64 0x6F 0x71 ("doq")  [RFC-ietf-dprive-dnsoquic-11]
>>> 
>>> Please see
>>> https://www.iana.org/assignments/tls-extensiontype-values
>>> 
>>> ACTION 2:
>>> 
>>> An additional reference and an updated description have been listed
>>> for UDP port 853, and the word "DTLS" has been removed from the
>>> description of the corresponding TCP port. These two registrations now
>>> read as follows:
>>> 
>>> Service Name: domain-s
>>> Port Number: 853
>>> Transport Protocol: tcp
>>> Description: DNS query-response protocol run over TLS
>>> Assignee: [IESG]
>>> Contact: [IETF Chair]
>>> Registration Date: 2015-10-08
>>>  Modification Date: 2022-04-01
>>> Reference: [RFC7858][RFC8094]
>>> 
>>> Service Name: domain-s
>>> Port Number: 853
>>> Transport Protocol: udp
>>> Description: DNS query-response protocol run over DTLS or QUIC
>>> Assignee: [IESG]
>>> Contact: [IETF Chair]
>>> Registration Date: 2015-10-08
>>> Modification Date: 2022-04-01
>>> Reference: [RFC7858][RFC8094][RFC-ietf-dprive-dnsoquic-11]
>>> 
>>> Please see
>>> https://www.iana.org/assignments/service

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

[Eric Vyncke (evyncke)]

Dear authors,

The revised I-D should mainly address Francesca Palombini's 2nd COMMENT point 
(which was also raised by Alvaro Retana). Both of them told me that they were 
about to raise a blocking DISCUSS on this specific point, so let's address is. 
It is mainly about either changing a SHOULD into a MUST or explaining when the 
SHOULD can be ignored.

Of course, addressing the other points would improve the quality of the 
documents.

Once a revised I-D addressing Francesca's point, I am approving the document 
and sending it to the RFC Editor.

Regards

-éric


-Original Message-
From: IETF Secretariat 
Date: Thursday, 10 March 2022 at 16:21
To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , "dprive-cha...@ietf.org" 
, "draft-ietf-dprive-dnsoq...@ietf.org" 
, Eric Vyncke 
Subject: Datatracker State Update Notice: 

IESG state changed:

New State: Approved-announcement to be sent::Revised I-D Needed

(The previous state was IESG Evaluation)


Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/



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

Re: [dns-privacy] Last Call Expired:

[Eric Vyncke (evyncke)]

Sara,

Thank you for your reply. This sounds reasonable and I have also read 
Christian's reply about IANA.

As soon as the -10 is published, I will proceed with the IESG evaluation.

Regards

-éric


-Original Message-
From: Sara Dickinson 
Date: Wednesday, 23 February 2022 at 11:17
To: Eric Vyncke 
Cc: "dns-privacy@ietf.org" , 
"draft-ietf-dprive-dnsoq...@ietf.org" , 
"sec...@ietf.org" 
Subject: Re: [dns-privacy] Last Call Expired: 


Hi Eric, 

The authors did ask Phillip directly if he had specific text changes he 
would like to see following his review during the first IETF Last Call:

https://mailarchive.ietf.org/arch/msg/dns-privacy/Iu7lg5AvF9Mx4Tu-gflASArOF8A/

However we did not get a reply and so we attempted to address that review 
in the -09 update (published on 9th February) based on a github issue with 
discussion points and a PR referenced in this email:

https://mailarchive.ietf.org/arch/msg/dns-privacy/oRHkyjhupzQj0HApzLprvE4V7_s/

Since we didn’t get any further feedback on this review during the second 
IETF LC, I’m hoping those updates addressed the points raised.

FYI - we have a pending PR to fix the minor issue noted in the latest IANA 
review, which was the only comment we got during the second IETF LC. So we’ll 
publish the -10 update with this correction shortly.

Regards

Sara. 

    > On 23 Feb 2022, at 09:47, Eric Vyncke (evyncke)  wrote:
> 
> The IETF-wide last call has expired and AFAIK there was only one detailed 
review by Phillip Hallam-Baker for the security directorate (added in cc):
> 
https://mailarchive.ietf.org/arch/msg/last-call/L23bWOxP54NZQPHT7DfRBxZAOCw/
> 
> What is the authors/WG plan to address the "has issues" of this review ? 
You probably know that the cut-off date is Monday 7th of March.
> 
> As a plain engineer (and without any hat), it appears to me that the 
Wi-Fi hotspot issue is not limited to DoQ but is also relevant to DoH. And the 
traffic analysis part is probably addressed already with the padding. 
> 
> With my AD hat, the points about 'outdated' security considerations and 
privacy vs. confidentiality should be addressed in the document (happy to be 
corrected of course). Anyway, it would be nice to answer to PHB.
> 
> Regards
> 
> -éric
> 
> 
> -Original Message-
> From: dns-privacy  on behalf of 
DraftTracker Mail System 
> Date: Wednesday, 23 February 2022 at 09:43
> To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , 
"draft-ietf-dprive-dnsoq...@ietf.org" , 
Eric Vyncke 
> Cc: "iesg-secret...@ietf.org" 
> Subject: [dns-privacy] Last Call Expired: 

> 
> 
>Please DO NOT reply to this email.
> 
>I-D: 
>Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/
> 
>IETF Last Call has ended, and the state has been changed to
>Waiting for AD Go-Ahead.
> 
> 
>___
>dns-privacy mailing list
>dns-privacy@ietf.org
>https://www.ietf.org/mailman/listinfo/dns-privacy
> 


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

Re: [dns-privacy] Last Call Expired:

[Eric Vyncke (evyncke)]

The IETF-wide last call has expired and AFAIK there was only one detailed 
review by Phillip Hallam-Baker for the security directorate (added in cc):
https://mailarchive.ietf.org/arch/msg/last-call/L23bWOxP54NZQPHT7DfRBxZAOCw/

What is the authors/WG plan to address the "has issues" of this review ? You 
probably know that the cut-off date is Monday 7th of March.

As a plain engineer (and without any hat), it appears to me that the Wi-Fi 
hotspot issue is not limited to DoQ but is also relevant to DoH. And the 
traffic analysis part is probably addressed already with the padding. 

With my AD hat, the points about 'outdated' security considerations and privacy 
vs. confidentiality should be addressed in the document (happy to be corrected 
of course). Anyway, it would be nice to answer to PHB.

Regards

-éric


-Original Message-
From: dns-privacy  on behalf of DraftTracker Mail 
System 
Date: Wednesday, 23 February 2022 at 09:43
To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , 
"draft-ietf-dprive-dnsoq...@ietf.org" , 
Eric Vyncke 
Cc: "iesg-secret...@ietf.org" 
Subject: [dns-privacy] Last Call Expired: 


Please DO NOT reply to this email.

I-D: 
Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.


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

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

Re: [dns-privacy] AD review of draft-ietf-dprive-dnsoquic

[Eric Vyncke (evyncke)]

Thank you, Sara.

Looking forward to the revised I-D before proceeding to IETF Last Call ;-)

Regards

-éric

On 07/01/2022, 12:56, "Sara Dickinson"  wrote:


> On 7 Jan 2022, at 07:38, Eric Vyncke (evyncke)  wrote:
> 
> Hi Sara
> 
> Thank you for your reply and the PRs.
> 
> Some more comments below, look for EV>



>> 
>>  Section 6.4: same comment as above and also in other places.
> 
>6.4 is proposed to change to a MUST for the use of padding in PR 
https://github.com/huitema/dnsoquic/pull/132. The main reason I can see for not 
using a QUIC padding API if it existed would be code complexity e.g. the 
implementation may choose to re-use padding logic already implemented in the 
DNS layer for DoT/DoH. I can add text about this if you think it is useful?
> 
> EV> adding some text about this would be helpful IMHO but not mandatory

Fair enough - text added in PR 
https://github.com/huitema/dnsoquic/pull/132/files



> 
>>  Also in " it performs well compared" does it mean "better" or "similar" 
?
> 
>Adguard haven’t published exact data yet but did say in a presentation 
 “it seems that…. it does provide advantage over DoH in cellular data networks, 
as expected” and their user feedback "ranges from very positive to neutral”.  
I’m reluctant to declare it ‘better’ without more raw data….
> 
> EV> in this case "better" would be wrong indeed but doesn't "well" imply 
'good' ? I.e., "similar" could be better ? On this one, you are the native 
English speaker so I let you decide ;-)

I’ve switched to ‘similarly (and possibly better)’ to reflect the 
qualitative nature of Adguards findings.  (I also just noticed this is in the 
‘Implementation Status’ section which will be removed anyway…)

Regards

Sara.

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

Re: [dns-privacy] AD review of draft-ietf-dprive-dnsoquic

[Eric Vyncke (evyncke)]

Hi Sara

Thank you for your reply and the PRs.

Some more comments below, look for EV> 

Regards

-éric


On 06/01/2022, 14:30, "dns-privacy on behalf of Sara Dickinson" 
 wrote:

Hi Eric, 

Many thanks for the review. I’ve created PR 
https://github.com/huitema/dnsoquic/pull/134 with proposed updates from your 
comments.

> On 10 Dec 2021, at 06:42, Eric Vyncke (evyncke) 
 wrote:
> 
> Dear authors,
> 
> In the revised I-D, please also consider Martin Duke (the transport AD)'s 
WGLC comments, see the thread at
> 
https://mailarchive.ietf.org/arch/msg/dns-privacy/F35q1jpUEPPqaq5gYVM8aYFoQUQ/
> 
> Especially around section 10.2 and the demux of DTLS & QUIC if both 
protocols run on the same port. Martin has suggested some text for this part, 
let's use it and remove any potential friction in the publication process.

PR for this approved and merged (thanks Martin!)

> 
> Regards
> 
> -éric
    > 
> 
> 
> On 09/12/2021, 14:40, "Eric Vyncke (evyncke)"  wrote:
> 
>   As usual, when a document is submitted for publication, as the 
responsible AD, I do my own review of the draft before going to the IETF Last 
Call.
> 
>   First, thank you Brian for a detailed doc shepherd write-up. Your 
points about the 'down-ref' are valid and for now I would leave them like they 
are.

Yes - thank you Brian. 

FYI: 
- PR https://github.com/huitema/dnsoquic/pull/135 includes a change to make 
RFC8094 informative and 
- PR https://github.com/huitema/dnsoquic/pull/132 provides updated text 
based on Alex’s review also making RFC8467 informative.

> 
>   Thanks, as well to the WG and the authors Christian, Sara, and Alisson 
for their work. The document is well written and easy to read: congratulations !
> 
>   Please find below my review comments:
> 
>   Abstract: should it state where DoQ could be used (i.e., between which 
DNS functions notably by citing XFR) ?

Yes - good point. I’ve added text.

> 
>   Section 1: s/ this document is intended to specify/ this document 
specifies/ ?
> 
>   Section 2: please use the real template from BCP14 (section 2 of RFC 
8174)

Ack to both. 

> 
>   Section 5: should there be a sentence "this section is normative" to be 
consistent with a similar sentence in section 4 ?

Would it be better to clarify the text in section 4?

“Whilst all other sections in this document are normative, this section is 
informative in nature."

EV> good suggestion, this is better with your text above

> 
>   Section 5.1.2: isn't the 3rd § obvious ? Hence could it be removed ?

Yes - I suppose it is an implementation detail, removed.

> Unsure whether there is value in the last §, especially as it appears to 
contradict the previous ones.

This was added in response to having read *multiple* papers/presentations 
on DoT vs DoH where a statement like ‘DoT must run on port 853 whereas DoH runs 
on port 443’ is made regarding deployment obstacles for DoT. For a wider 
audience it does seem useful to point out that 443 is a possibility for DoQ 
deployments.

EV> fair enough

> 
>   Section 5.3: should DOQ_REQUEST_CANCELLED also be available when the 
server wants to close a transaction (e.g., when there are multiple 
responses/XFR) ?

Well, section 5.3.2 really deals with the server side having issues and 
using a stream reset + DOQ_INTERNAL_ERROR to signal this. I’m not sure when a 
server would choose to send DOQ_REQUEST_CANCELLED as the error here as opposed 
to DOQ_INTERNAL_ERROR since the only reason to not send all the responses would 
be an error of some kind (even for XFR)… or is there another use case I’m 
missing?

EV> you are not missing anything, my bad on my comment :-O

> 
>   Section 6.3: contains two SHOULD, the general expectation is that the 
document describes when it is acceptable not to follow the SHOULD. Or perhaps 
should RECOMMENDED be used ?

The kind of reasons I always assume are behind these kind of SHOULDs are: 
is an API for this exposed, does it increase code complexity too much or does 
it add too much performance overhead, etc. I’m not sure we have a specific case 
for section 6.3 but Christian may be able to point to one.

EV> you and Christian will have the final say on this comment.

> 
>   Section 6.4: same comment as above and also in other places.

6.4 is proposed to change to a MUST for the use of padding in PR 
https://github.com/huitema/dnsoquic/pull/132. The main reason I can see for not 
using a QUIC padding API if it existed would be code complexity e.g. the 
implementation may choose to re-use padding logic already implemented in the 
DNS layer for DoT/DoH. I can add text abo

Re: [dns-privacy] AD review of draft-ietf-dprive-dnsoquic

[Eric Vyncke (evyncke)]

Dear authors,

In the revised I-D, please also consider Martin Duke (the transport AD)'s WGLC 
comments, see the thread at
https://mailarchive.ietf.org/arch/msg/dns-privacy/F35q1jpUEPPqaq5gYVM8aYFoQUQ/

Especially around section 10.2 and the demux of DTLS & QUIC if both protocols 
run on the same port. Martin has suggested some text for this part, let's use 
it and remove any potential friction in the publication process.
 
Regards

-éric


On 09/12/2021, 14:40, "Eric Vyncke (evyncke)"  wrote:

As usual, when a document is submitted for publication, as the responsible 
AD, I do my own review of the draft before going to the IETF Last Call.

First, thank you Brian for a detailed doc shepherd write-up. Your points 
about the 'down-ref' are valid and for now I would leave them like they are.

Thanks, as well to the WG and the authors Christian, Sara, and Alisson for 
their work. The document is well written and easy to read: congratulations !

Please find below my review comments:

Abstract: should it state where DoQ could be used (i.e., between which DNS 
functions notably by citing XFR) ?

Section 1: s/ this document is intended to specify/ this document 
specifies/ ?

Section 2: please use the real template from BCP14 (section 2 of RFC 8174)

Section 5: should there be a sentence "this section is normative" to be 
consistent with a similar sentence in section 4 ?

Section 5.1.2: isn't the 3rd § obvious ? Hence could it be removed ? Unsure 
whether there is value in the last §, especially as it appears to contradict 
the previous ones.

Section 5.3: should DOQ_REQUEST_CANCELLED also be available when the server 
wants to close a transaction (e.g., when there are multiple responses/XFR) ?

Section 6.3: contains two SHOULD, the general expectation is that the 
document describes when it is acceptable not to follow the SHOULD. Or perhaps 
should RECOMMENDED be used ?

Section 6.4: same comment as above and also in other places.

Section 6.7: should this document formally update RFC 1995, 5936, 7766 ? I 
think so as it is similar to RFC 9103, which updates those 3 RFCs.

Section 7.1: s/ To our knowledge/To the authors' knowledge/ ?
Also in " it performs well compared" does it mean "better" or "similar" ?

Section 9.3: " due to the prevalence of NAT" is not the only cause as IPv6 
nodes often change their IPv6 addresses. Please extend the text here as the DoQ 
may not have an API to check whether the IPv6 address has changed.

Finally, while I am not a native English speaker (but I relied on the 
Microsoft Word spell-checker on the attached document), I think that there are 
some nits in the text:
- Missing a lot of '-' in some constructions: "general purpose transport", 
"server initiated transactions", "long term state ", ...
- "however" should be followed by a comma
- No "n" in "an" in " an unidirectional QUIC stream"
- "acknowledgeemnts"
- "Provisonal"

If the above review points are agreed, then please upload a revised version 
so that I can continue the publication process.

Regards

-éric



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

[dns-privacy] AD review of draft-ietf-dprive-dnsoquic

[Eric Vyncke (evyncke)]

As usual, when a document is submitted for publication, as the responsible AD, 
I do my own review of the draft before going to the IETF Last Call.

First, thank you Brian for a detailed doc shepherd write-up. Your points about 
the 'down-ref' are valid and for now I would leave them like they are.

Thanks, as well to the WG and the authors Christian, Sara, and Alisson for 
their work. The document is well written and easy to read: congratulations !

Please find below my review comments:

Abstract: should it state where DoQ could be used (i.e., between which DNS 
functions notably by citing XFR) ?

Section 1: s/ this document is intended to specify/ this document specifies/ ?

Section 2: please use the real template from BCP14 (section 2 of RFC 8174)

Section 5: should there be a sentence "this section is normative" to be 
consistent with a similar sentence in section 4 ?

Section 5.1.2: isn't the 3rd § obvious ? Hence could it be removed ? Unsure 
whether there is value in the last §, especially as it appears to contradict 
the previous ones.

Section 5.3: should DOQ_REQUEST_CANCELLED also be available when the server 
wants to close a transaction (e.g., when there are multiple responses/XFR) ?

Section 6.3: contains two SHOULD, the general expectation is that the document 
describes when it is acceptable not to follow the SHOULD. Or perhaps should 
RECOMMENDED be used ?

Section 6.4: same comment as above and also in other places.

Section 6.7: should this document formally update RFC 1995, 5936, 7766 ? I 
think so as it is similar to RFC 9103, which updates those 3 RFCs.

Section 7.1: s/ To our knowledge/To the authors' knowledge/ ?
Also in " it performs well compared" does it mean "better" or "similar" ?

Section 9.3: " due to the prevalence of NAT" is not the only cause as IPv6 
nodes often change their IPv6 addresses. Please extend the text here as the DoQ 
may not have an API to check whether the IPv6 address has changed.

Finally, while I am not a native English speaker (but I relied on the Microsoft 
Word spell-checker on the attached document), I think that there are some nits 
in the text:
- Missing a lot of '-' in some constructions: "general purpose transport", 
"server initiated transactions", "long term state ", ...
- "however" should be followed by a comma
- No "n" in "an" in " an unidirectional QUIC stream"
- "acknowledgeemnts"
- "Provisonal"

If the above review points are agreed, then please upload a revised version so 
that I can continue the publication process.

Regards

-éric




draft-ietf-dprive-dnsoquic-07.docx
Description: draft-ietf-dprive-dnsoquic-07.docx
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] UDP/853 port allocation request for draft-ietf-dprive-dnsoquic

[Eric Vyncke (evyncke)]

Just a heads-up to the DPRIVE WG and for the DoQ authors[1]: after some 
discussions within IESG/IAB, I am afraid that UDP/853 won't be allocated to 
DoQ. Nothing definitive yet of course but IAB/IESG have raised the following 
concerns:



  *   Lack of real technical motivation (except for 'symmetry' or for 
operational reasons).
  *   Moving DoDTLS to historic will not help, as it will simply return udp/853 
to the pool to be re-used later.
  *   The *currently* possible demux between QUIC & DTLS is not something 
carved in stone forever. Hence, a future problem can happen if DTLS v23 cannot 
be demuxed from QUIC v19. This would put a heavy constraint on the evolution of 
both QUIC & DTLS, i.e., ossifying both protocols. Not to mention that both QUIC 
& DTLS want to expose as little as possible to observers, making demux of 
future versions quite improbable...



Personally, I do not think that it is critical to re-use udp/853 but happy to 
work with the authors and the WG to attempt to re-use it.



Comments are welcome, as usual ;-)



Regards,



-éric



[1] I already have exchanged some email messages with authors and chairs last 
week, but it is time to extend the discussion to the WG


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

[dns-privacy] ANRW on DNS privacy

[Eric Vyncke (evyncke)]

For information, the Applied Networking Research Workshop (ANRW) has a session 
dedicated to DNS privacy next week, see the program for the 28th of July at 
https://irtf.org/anrw/2021/program.html with

  *   Encryption without Centralization: Distributing DNS Queries Across 
Recursive Resolvers
  *   Institutional Privacy Risks in Sharing DNS Data
  *   DNS over TCP Considered Vulnerable

Hope it helps,

-éric

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

[dns-privacy] Addressing the DISCUSS points raised by the IESG on draft-ietf-dprive-xfr-over-tls-11

[Eric Vyncke (evyncke)]

[Message sent to authors, WG, and the DISCUSS-holding area directors]

As you have seen by now[1], this document has raised at least two blocking 
DISCUSS points and those points will be discussed during Thursday 6th of May 
telechat (i.e., tomorrow in my timezone).

My own reading of those DISCUSS ballots (perhaps more ballots to come):
- not using ALPN code
- text about the comparison between IP ACL and crypto authentications

If possible, then I would appreciate some replies before the telechat by the 
authors on the recent Ben Kaduk’s points as Allison Mankin’s reply [2] (as well 
as Sara Dickinson’s ones) has already addressed Martin Duke’s concern about 
ALPN.

The WG view on using ALPN is also important to move forward as it is an 
important technical change.

As usual, everyone is welcome to join the telechat [3] as observer, it should 
be a short one.

Thank you in advance for your replies (again if possible),

Regards

-éric

[1] https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ballot/
[2] 
https://mailarchive.ietf.org/arch/msg/dns-privacy/HaQ7SO8Ma9TW3v0Wrh18LD6BNy8/
[3] 
https://mailarchive.ietf.org/arch/msg/ietf-announce/X7t76SwcK1fjMQsGb2Wy11R-cnw/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Vyncke (evyncke)]

Martin,

The IETF Last Call on this document has completed on the 20th of April 2021 but 
it is never too late of course.

I just added our security Area Directors in the loop so that know your question 
for their ballot due for next week.

Regards

-éric



-Original Message-
From: dns-privacy  on behalf of Sara Dickinson 

Date: Thursday, 29 April 2021 at 14:52
To: Martin Thomson 
Cc: DNS Privacy Working Group , "t...@ietf.org" 

Subject: Re: [dns-privacy] Martin Duke's No Objection on 
draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)



> On 29 Apr 2021, at 01:09, Martin Thomson  wrote:
> 
> On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote:
>> An early version of this specification proposed a XoT specific ALPN in 
>> order to distinguish this from a connection intended to perform 
>> recursive to authoritative DoT (often called ADoT). ADoT is not yet 
>> specified, but is the subject of ongoing discussions in DPRIVE. The 
>> working group rejected this idea for XoT and switched to the current 
>> spec which does not use an ALPN at all. 
> 
> No new protocol should use TLS without ALPN.  It only opens space for 
cross-protocol attacks.  Did the working group consider this possibility in 
their discussions?

What the working group asked for following the ALPN discussion was that the 
document contain a description of the options an authoritative nameserver that 
supports XoT can use to manage TLS connections and the queries received on 
those connections  - that is provided in Appendix A: 
https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A

As more context, the document also covers various existing mechanisms that 
can be used to manage zone transfers (including IP ACLs and TSIG) and how they 
combine with Strict and Mutual TLS authentication. The document specifies that 
the server MUST use either an IP ACL or mTLS to authenticate the XoT client. 

Regards

Sara. 

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

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

Re: [dns-privacy] AD review of draft-ietf-dprive-xfr-over-tls-08

[Eric Vyncke (evyncke)]

Sara

Sorry for belated reply, I took a couple of days off.

Thank you for your detailed reply and actions. I am happy with all proposed 
changes; for a couple of remaining points, please look below for EV>

As soon as a revised I-D is uploaded, then I am initiating the IETF Last Call.

Regards

-éric

-Original Message-
From: Sara Dickinson 
Date: Monday, 29 March 2021 at 15:08
To: Eric Vyncke 
Cc: "draft-ietf-dprive-xfr-over-...@ietf.org" 
, "dns-privacy@ietf.org" 

Subject: Re: AD review of draft-ietf-dprive-xfr-over-tls-08



> On 18 Mar 2021, at 15:33, Eric Vyncke (evyncke)  wrote:
> 
> Dear authors,
> 
> Thank you (and extended thanks to the WG) for this document.
> 
> Please find below my AD review of -08 revision of the document. Before 
proceeding with the publication process, I will appreciate replies about the 
points below (and possibly a revised I-D).

Many thanks for the review!

> 
> - Section 1: please replace the reference to RFC7626 with the 7626bis 
document, which is already in the RFC editor queue

Done. 

> - Section 1: does the use of legacy RFC 7626 rather than the bis impact 
the rest of the section ?

Not in terms of XFR - the bis makes no updates to the discussion of XFR 
handling.

But your comment on this paragraph prompted me to remove the reference to 
the draft-vandijk-dprive-ds-dot-signal-and-pin as the discussion in DPRIVE has 
moved on significantly from when that was first published. I suggest changing 
the text to:

“and some suggestions for how signaling of DoT support by authoritatives 
might work."

> - Section 1: “Some operators use SSH tunneling or IPSec to encrypt the  
transfer data” is this assertation backed by some public references ?

I can’t find any good references for specific deployments even though it is 
a know technique, but the NIST guide referenced in the next paragraph does also 
mention it as an option. I propose to remove that specific sentence and update 
the following paragraph:

“Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Deployment'
[@nist-guide] discusses restricting access for zone transfers using ACLs and
TSIG in more detail. It also discusses the possibility that specific 
deployments
might choose to use a lower level network layer to protect zone transfers, 
e.g., IPSec."

> - Section 1: did you consider adding something about reconnaissance ? 
I.e., network scanning of an IPv6 prefix is basically impossible but having 
access to a DNS zone and its  RR makes the reconnaissance trivial

Not really, as I think the main concern with zone enumeration has largely 
been the exposure of the names rather than the IP addresses, but it is a good 
point. We could add the following text after the bullet points.

“Additionally, the full zone contents expose all the IP addresses of 
endpoints held in the DNS records which can make reconnaissance trivial, 
particularly for IPv6 addresses."


> - Section 4.1: from a logical flow perspective, I would have started with 
the threat model first, then the confidentiality/authentication/ parts

Thanks - that makes more sense. I have changed section 4.1 into section 4 
(threat model) and changed the use cases to be section 5 (but also see next 
answer). 


> - Section 4: I find the logic of the ‘performance’ point weird because it 
is not really generated by the document but rather by an upgrade. I suggest to 
rewrite this part.

I think a better title for that section would be something like ‘Design 
considerations for XoT’ which might better describe what is being listed there? 

EV> good suggestion

> - Some nits usually ‘e.g.’ is surrounded by commas

Fixed

> - BTW, while I appreciate the trend to replace master by primary, may I 
suggest to clarify in the terminology section that ‘primary’ means ‘master’ and 
‘secondary’ means ‘slave’ ? Up to you as it is a touchy topic but making the 
linked with the legacy document seems important to me. Really up to the authors.

Suggest moving the text on this to be a sub note to the RFC8499 reference 
which already deals with the legacy terms:

“DNS terminology is as described in [@!RFC8499]. Note that as in 
[@!RFC8499], the
terms 'primary' and 'secondary' are used for two servers engaged in zone 
transfers."

> - Section 5.2 last § missing a closing ‘)’
> - Section 5.3.2 please qualify “lag” (I guess serial numbers)
> - Section 6, unsure whether “(probably unintentional)" add any value, 
consider to remove ?

All fixed.

> - Section 6.4, "one DoH connection" even with the "could hypothetically 
include" appears a little weird to me

The full list of multiple transports was added after a discussion in the WG 
to clarify the issue. We did think

Re: [dns-privacy] WG Call for Adoption: draft-pp-recursive-authoritative-opportunistic

[Eric Vyncke (evyncke)]

Belated reply from the DPRIVE AD after he read the whole thread (but not yet 
the other one) even if replying on this first email.

It is clear that the adoption call was not overwhelmingly in favor of adoption. 
But, there were supporters for adoption.

The level of rough consensus for adoption should be lower than for a last call 
as the WG goal is to improve it. Moreover, let's not forget that there are many 
adopted documents that were never published...

In short, I fully support the chairs' decision to adopt this document.

Let's all work on this document, and improve it.

Regards

-éric


-Original Message-
From: dns-privacy  on behalf of Brian Haberman 

Date: Saturday, 13 February 2021 at 15:27
To: "dns-privacy@ietf.org" 
Subject: Re: [dns-privacy] WG Call for Adoption: 
draft-pp-recursive-authoritative-opportunistic

All,
 The WGLC for adoption for this draft has completed. The chairs have
determined that there is consensus to adopt this document as a DPRIVE
working group document.

 The authors should publish the next version of the document as
draft-ietf-dprive-recursive-authoritative-opportunistic-00. The intended
status of the document will be a part of the WG discussion on this draft.

Regards,
Brian & Tim

On 1/29/21 8:24 AM, Brian Haberman wrote:
> All,
>  This starts a DPRIVE WG call for adoption for
> draft-pp-recursive-authoritative-opportunistic
> 
(https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/).
> The focus of the call is the protocol defined in the draft. Please reply
> to the mailing list with your views on the WG adopting the document and
> your supporting arguments.
> 
>  This call will end on February 12, 2021 at 11:59pm UTC.
> 
> Regards,
> Brian & Tim
> 

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

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

Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Thank you all for the review (catching a good point) and even more for the 
quick resolution

-éric

-Original Message-
From: iesg  on behalf of Warren Kumari 

Date: Thursday, 8 October 2020 at 14:59
To: Tim Wicinski 
Cc: The IESG , Brian Haberman , 
"draft-ietf-dprive-rfc7626-...@ietf.org" 
, DNS Privacy Working Group 
, "dprive-cha...@ietf.org" 
Subject: Re: [dns-privacy] Warren Kumari's Discuss on 
draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

On Thu, Oct 8, 2020 at 8:51 AM Tim Wicinski  wrote:
>
> Warren
>
>There are many ways in which supposed "private"
>resources currently leak. A few  examples are  DNSSEC NSEC zone 
walking;
>passive-DNS services; etc.
>
> with the references added in. and changing the section title

Thank you very much, that will work for me.
I really do think that this was an important point, and thank you (and
the WG!) for addressing it.

I've just changed my ballot from DISCUSS to YES; it's an important
foundational document, and useful for level-setting.


Thanks again,
W


>
> tim
>
>
> On Wed, Oct 7, 2020 at 8:16 PM Warren Kumari  wrote:
>>
>> On Wed, Oct 7, 2020 at 5:16 PM Peter Koch  wrote:
>> >
>> > Hi Warren,
>> >
>> > On Wed, Oct 07, 2020 at 04:39:54PM -0400, Warren Kumari wrote:
>> >
>> > > 4.1.  The Public Nature of DNS Data
>> > >
>> > >It is often stated that "the data in the DNS is public".  This 
sentence
>> > >makes sense for an Internet-wide lookup system,  and there
>> > >are multiple facets to the data and metadata involved that 
deserve a
>> > >more detailed look.  First, access control lists (ACLs) and 
private
>> > >namespaces notwithstanding, the DNS operates under the assumption
>> > >that public-facing authoritative name servers will respond to 
"usual"
>> > >DNS queries for any zone they are authoritative for without 
further
>> > >authentication or authorization of the client (resolver).  Due to 
the
>> > >lack of search capabilities, only a given QNAME will reveal the
>> > >resource records associated with that name (or that name's non-
>> > >existence).  In other words: one needs to know what to ask for, in
>> > >order to receive a response. However, there are many ways in
>> > >in which supposed "private" resources leak, including DNSSEC
>> > >   NSEC zone walking [REF]; passive-DNS services [ref]; employees
>> > >   taking their laptops home (where they may use a different 
resolver),
>> > >   and refreshing names which should only exist in their enterprise
>> > > environment, etc.
>> >
>> > I think this text is mixing too many aspects that are (or should 
eventually be)
>> > covered in other parts of the document.
>>
>> The document is in IESG eval -- there is no more "eventually".
>>
>>
>> > The antipodes are _not_ 'public'
>> > and 'secret'.  The purpose of that section was to exactly counter the
>> > too narrow perception that 'all data in the DNS is public' (which by 
the
>> > way, was a usual counter argument to NSEC3) to help motivate the need
>> > for further dealing with DNS privacy.
>>
>> I fully agree that we need to explain the need for DNS privacy -- but
>> to my mind the original text does the opposite - it provides the
>> illusion that you can put private info in the DNS and (realistically)
>> expect it to stay that way. I fully agree with your below that things
>> like passive dns is not a feature of the DNS, but it *is* a way that
>> records that people might assume to be private leak.
>>
>> Yes, I do fully understand that the primary purpose of this is to
>> discuss the privacy needs / implications of leaking in *transactions*,
>> but this section seems to pooh-pooh the risks of exposing "private"
>> names...
>>
>>
>> Tim's suggestion (coupled with changing the section title) would be
>> fine with me...
>>
>> W
>>
>> > It does not suggest to store secrets
>> > in the DNS.  The original text, I believe - biased as might be - did 
and does clearly
>> > differentiate betweeen residual data and transactions.  'passive DNS'
>> > is not a feature of the DNS - it is a by-product and, from the 
perspective
>> > of privacy, to be addressed under 'risks'.
>> >
>> > -Peter
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like 

Re: [dns-privacy] Status of draft-ietf-dprive-rfc7626-bis?

[Eric Vyncke (evyncke)]

[top posting...]

Thank you Brian for explaining the situation.

Special thanks to Sara and Stéphane the previous editors and also to Tim (the 
new one __ )

I will proceed with the publication process before the end of this week.

Regards

-éric

-Original Message-
From: dns-privacy  on behalf of Brian Haberman 

Date: Wednesday, 23 September 2020 at 14:17
To: "dns-privacy@ietf.org" 
Subject: Re: [dns-privacy] Status of draft-ietf-dprive-rfc7626-bis?

Hi Paul,

On 9/17/20 10:36 AM, Paul Hoffman wrote:
> Greetings again. A document on which I am a co-author refers to 
draft-ietf-dprive-rfc7626-bis. As I was updating references in that draft, I 
thought that maybe draft-ietf-dprive-rfc7626-bis was done. However, according 
to https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/, this 
draft's state has be "AD followup" for many months now.
> 

After the IETF Last Call, there were some concerns raised by several
people. As I mentioned earlier, the editor, chairs, and AD discussed
those issues and potential resolutions.

Several of the concerns raised revolved around changes made due to last
call comments. The chairs and the AD determined that there was not
consensus to make those changes, so part of the delay has been in
determining what changes had consensus and backing out the other
changes. We now believe we have a version which represents WG consensus
and addresses consensus supported comments made during IETF last call.

> Is there something that the draft authors or the DPRIVE WG need to do to 
help move this forward?

Another aspect of the delay was that the original draft authors have
decided to step down as editors. I personally want to thank the authors,
especially Sara, for pushing this document forward to this point. She
should be commended for the diligence and effort she put forth.

In order to keep the document moving, Tim has agreed to take up the
editor's pen at this point. We should be publishing a new version today.
I will remain as the responsible chair for the document.

If anyone has any questions on the above, please get in touch with
either me, Éric, or Tim.

Regards,
Brian



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

[dns-privacy] Interesting talk at IRTFOPEN "An End-to-End, Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?"

[Eric Vyncke (evyncke)]

For information, there is a possibly interesting talk at IRTFOPEN on Tuesday by 
Chaoyi Lu (the ANRP prize-winner AFAIK) about “An End-to-End, Large-Scale 
Measurement of DNS-over-Encryption: How Far Have We Come?”

See also https://faculty.sites.uci.edu/zhouli/files/2019/09/imc19.pdf

-éric
___
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-bcp-op-13.txt

[Eric Vyncke (evyncke)]

Stéphane,

This is a little late in the process as the BCP has been approved last Thursday 
after IESG review ;-)

OTOH, this is editorial changes and do not change the core of the document.

So, I suggest to upload quickly a new revision before it goes in the RFC Editor 
queue (where those changes could still happen in AUTH48 state). You, Sara, and 
I are in European time zone, so, let's act quickly this Monday morning

-éric

-Original Message-
From: Stephane Bortzmeyer 
Organization: NIC France
Date: Saturday, 11 July 2020 at 09:48
To: Sara Dickinson 
Cc: DNS Privacy Working Group , Eric Vyncke 

Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-13.txt

On Fri, Jul 10, 2020 at 09:41:07AM +0100,
 Sara Dickinson  wrote 
 a message of 61 lines which said:

> This version should address the final comments from the IESG review.

Some very small editorial details:

Abstract "to assist writers of a Recursive operator Privacy statement"
Capital S, for the acronym.

Section 1 "These open resolvers have tended" Rather "public resolvers"
to be consistent with the rest of the paragraph and with RFC 8499.

Section 5.3.1 "Run a copy of the root zone on loopback [RFC7706]"
should now be written "Run a local copy of the root zone [RFC8806]".

Appendix D.2 "Both POST and GET are supported" Can probably be deleted
since RFC 8484 says "DoH servers MUST implement both the POST and GET
methods."



___
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-bcp-op-13.txt

[Eric Vyncke (evyncke)]

Bob,

It looks like there is a bug in the datatracker

Please use https://tools.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-13.txt


-éric

From: Bob Harold 
Date: Friday, 10 July 2020 at 16:26
To: Sara Dickinson 
Cc: DNS Privacy Working Group , Eric Vyncke 

Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-13.txt

On Fri, Jul 10, 2020 at 4:41 AM Sara Dickinson 
mailto:s...@sinodun.com>> wrote:
Hi,

This version should address the final comments from the IESG review.

Sara.

> On 10 Jul 2020, at 09:38, 
> internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
>
>Title   : Recommendations for DNS Privacy Service Operators
>Authors : Sara Dickinson
>  Benno J. Overeinder
>  Roland M. van Rijswijk-Deij
>  Allison Mankin
>   Filename: draft-ietf-dprive-bcp-op-13.txt
>   Pages   : 44
>   Date: 2020-07-10
>
> Abstract:
>   This document presents operational, policy, and security
>   considerations for DNS recursive resolver operators who choose to
>   offer DNS Privacy services.  With these recommendations, the operator
>   can make deliberate decisions regarding which services to provide,
>   and how the decisions and alternatives impact the privacy of users.
>
>   This document also presents a non-normative framework to assist
>   writers of a Recursive operator Privacy statement (analogous to DNS
>   Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
>   described in RFC6841).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-13
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-13

When I try to view the diff, I get the error:

"Couldn't retrieve file 2 
(https://www.ietf.org/archive/id/draft-ietf-dprive-bcp-op-13.txt) - got a 
redirect to 'https://www.ietf.org/archive/id/draft-ietf-dprive-bcp-op-12.txt'.."

--
Bob Harold

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

Re: [dns-privacy] IESG review of draft-ietf-dprive-bcp-op

[Eric Vyncke (evyncke)]

Alissa and Ben,

Is there any chance that you may quickly check whether the new version 
addresses your previous DISCUSS ?

The plan is to put the document back on an IESG telechat

Thank you

-éric


-Original Message-
From: Sara Dickinson 
Date: Thursday, 18 June 2020 at 17:28
To: IESG , Eric Vyncke , 
"dprive-cha...@ietf.org" , DNS Privacy Working Group 
, Benjamin Kaduk , Alissa Cooper 

Cc: "draft-ietf-dprive-bcp...@ietf.org" 
Subject: IESG review of draft-ietf-dprive-bcp-op

All, 

We’ve just published a -10 version of draft-ietf-dprive-bcp-op which we 
hope addresses the outstanding DISCUSS’s for this document (in addition to 
responses provided in the emails of March 4th) and the other comments from the 
IESG review. 

Ben/Alissa - since you both hold a DISCUSS on this document could you 
please re-read the emails and review the document to see if these 
changes/responses address your concerns?

The main changes are:

1) In earlier versions of the BCP document there were references to some 
new sections that appeared only in draft-ietf-dprive-rfc7626-bis but that is no 
longer the case so this version of draft-ietf-dprive-bcp-op does the following:

  * converts the reference in Section 3 (Scope) from 
draft-ietf-dprive-rfc7626-bis to the original RFC7626
  * converts the reference to RFC7626 to an Informative reference
  * removes the three direct reference to draft-ietf-dprive-rfc7626-bis in 
the text. They are very generic threats (passive surveillance, attacks on 
client resolver configuration and privacy of client IP addresses) and are all 
covered in RFC7626.

2) Clarify that the DROP statement outline is non-normative and add some 
further qualifications about content as requested.

3) Update the wording on data sharing to remove explicit discussion of 
consent in the Introduction and Section 5.3.3

4) Move table in section 5.2.3 to an appendix

5) Move section 6.2 to an appendix

We are aware that the membership of the IESG has changed since the original 
review and so would like to request that the AD clarify what is now required in 
terms of further review to move this draft forward.

Best regards

Sara



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

[dns-privacy] Msg from the AD Re: I-D Action: draft-ietf-dprive-rfc7626-bis-04.txt

[Eric Vyncke (evyncke)]

Dear dprive WG members,

As you have noticed, there are a lot of messages and discussions about this 
specific draft revision issued after the 2nd (!) IETF-wide Last Call. 
Discussions are always good (and I really appreciate the respectful tone of 
those discussions) but are not always helping to progress this WG document 
towards publication (if this is still deemed useful by the WG and the IETF, we 
could also have a "rough consensus" rather than a unanimous approval).

For your information, as the responsible AD, I will have a chat with the chairs 
on Friday 15th of May to clarify what stage this draft is at given the recent 
comments. Brian, Tim, and myself will come back to the WG shortly after the 
call and share with you the plan to move forward (looking for the WG feedback).

Again, thank you for having kept the discussion respectful

-éric


-Original Message-
From: dns-privacy  on behalf of Sara Dickinson 

Date: Thursday, 16 January 2020 at 13:23
To: DNS Privacy Working Group 
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-rfc7626-bis-04.txt

Hi All, 

So the -04 update attempts to address as many of the comments as possible 
that arose during IETF LC along the lines Eric suggested. The change log is:

* Tsvart review: Add reference to DNS-over-QUIC, fix typo.
* Secdir review: Add text in Section 3 on devices using many networks. 
Update bullet in 3.4.1 on cellular encryption.
* Section 3.5.1.1 - re-work the section to try to address multiple 
comments. 
* Section 3.5.1.4 - remove this section as now covered by 3.5.1.1.
* Section 3.5.1.5.2 - Remove several paragraphs and more directly reference
  RFC8484 by including bullet points quoting text from Section 8.2 of 
RFC8484.
  Retain the last 2 paragraphs as they are information for users, not
  implementors.
* Section 3.4.2 - some minor updates made based on specific comments.

If there are still concerns about the content then I would be very grateful 
at this stage if folks could propose specific text to address issues so we can 
more quickly move forward. 

Regards

Sara. 


> On 16 Jan 2020, at 12:15, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
> 
>Title   : DNS Privacy Considerations
>Authors : Stephane Bortzmeyer
>  Sara Dickinson
>   Filename: draft-ietf-dprive-rfc7626-bis-04.txt
>   Pages   : 28
>   Date: 2020-01-16
> 
> Abstract:
>   This document describes the privacy issues associated with the use of
>   the DNS by Internet users.  It is intended to be an analysis of the
>   present situation and does not prescribe solutions.  This document
>   obsoletes RFC 7626.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dprive-rfc7626-bis-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-rfc7626-bis-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-rfc7626-bis-04
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

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

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

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

[Eric Vyncke (evyncke)]

Eric / Ekr,

Sara has posted a revised I-D, does it address the point in your email dated 
9th of April ?

She also replied end of April with:

“I see the confusion now, the sentence beginning ‘If not,’ was meant to refer 
to whether (if they didn’t support using the system resolver) individual 
applications offered per-application settings to inspect/manage the DNS queries 
e.g. export session keys. To try to rework the text in context:

"An increasing number of applications are offering application-specific 
encrypted DNS resolution settings, rather than defaulting to using only the 
system resolver.  A variety of heuristics and resolvers are available in 
different applications including hard-coded lists of recognized DoH/DoT servers.

For users to have the ability to manage the DNS resolver settings for each 
individual application in a similar fashion to the OS DNS settings, each 
application would need to expose the default settings to the user, provide a 
configuration interface to change them, and support configuration of user 
specified resolvers.

The system resolver resolution path is sometimes used to configure additional 
DNS controls e.g. query logging, domain based query re-direction or filtering.
If all of the applications used on a given device can be configured to use the 
system resolver, such controls need only be configured on the system resolver 
resolution path. However if applications offer neither the option to use the 
system resolver nor equivalent application-specific DNS controls then users 
should take note that for queries generated by such an application they may not 
be able to
* directly inspect the DNS queries (e.g. if they are encrypted), or
* manage them to set DNS controls across the device which are consistent with 
the system resolver controls.

Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and controls of 
its own choosing. »


Thank you for your prompt reply

-éric V (the other one)

From: Eric Rescorla 
Date: Thursday, 9 April 2020 at 16:35
To: Sara Dickinson 
Cc: Eric Orth , "dns-privacy@ietf.org" 
, Vittorio Bertola , 
"dprive-cha...@ietf.org" , Eric Vyncke 
, "draft-ietf-dprive-rfc7626-...@ietf.org" 

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




On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson 
mailto:s...@sinodun.com>> wrote:



On 9 Apr 2020, at 14:24, Eric Rescorla mailto:e...@rtfm.com>> 
wrote:






How about making the last sentence a little more specific instead:

If not, then (depending on the application and transport used for DNS queries) 
users should take note that they may not be able to inspect the DNS queries 
generated by such applications, or manage them to set consistent 
application-level controls across the device for e.g. domain based query 
re-direction or filtering. “

If the feeling is that it is really needed then I would suggest text that is 
consistent with that used in section 3.5.2.1, for example:

“ In addition, if a client device is compromised by a malicious application, 
the attacker can
  use application-specific DNS resolvers, transport and settings of its own 
choosing.”

Sort of. This seems like it still buries the lede.

"Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and settings of 
its own choosing and thus will not be affected by these controls.”

By 'these controls’ do you mean any controls that the malicious application 
appears to offer to the user? If so, then does this capture your point:

"Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and settings of 
its own choosing regardless of what DNS configuration the malicious application 
may appear to offer the user (if any).”

No. My point is that the platform level DNS controls that you are trying to use 
don't work in this case.

-Ekr


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

[dns-privacy] Status of draft-ietf-dprive-rfc7626-bis ?

[Eric Vyncke (evyncke)]

Sara, Stéphane,

First, I hope that you and your relatives are safe in those days...

I may have lost track and would be happy to stand corrected, but, AFAIK, a 
revised-ID of the document is still due based in our discussion early March 
2020.

Unless I hear something about a new I-D before end of today UTC, then I am 
removing the I-D from the April 9th telechat. Just a small delay ;-)

Thank you in advance for your reply as well as your revised I-D

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

Re: [dns-privacy] dprive - New Interim Meeting Request

[Eric Vyncke (evyncke)]

As there is not conflict or even overlap with other interims on that day, I 
just approved the meeting.

Thank you Brian and Tim for the organization,

-éric

-Original Message-
From: IETF Meeting Session Request Tool 
Date: Friday, 27 March 2020 at 15:03
To: "session-requ...@ietf.org" 
Cc: "dprive-cha...@ietf.org" , 
"br...@innovationslab.net" , Eric Vyncke 
, "dns-privacy@ietf.org" 
Subject: dprive - New Interim Meeting Request


A new interim meeting request has just been submitted by Brian Haberman.

This request requires approval by the Area Director of the Internet Area

The meeting can be approved here: 
https://datatracker.ietf.org/meeting/interim/request/interim-2020-dprive-01



-
Working Group Name: DNS PRIVate Exchange
Area Name: Internet Area
Session Requester: Brian Haberman

Meeting Type: Virtual Meeting

Session 1:

Date: 2020-04-08
Start Time: 16:00 UTC
Duration: 01:30
Remote Participation Information: Webex
Agenda Note: 

-




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

Re: [dns-privacy] Intdir telechat review of draft-ietf-dprive-rfc7626-bis-04

[Eric Vyncke (evyncke)]

Merci very much Jean-Michel, I am sure that the authors will take this into 
account before submitting a revised I-D before the evaluation by the IESG

-éric

-Original Message-
From: Jean-Michel Combes via Datatracker 
Reply-To: Jean-Michel Combes 
Date: Monday, 9 March 2020 at 21:30
To: "int-...@ietf.org" 
Cc: "last-c...@ietf.org" , "dns-privacy@ietf.org" 
, "draft-ietf-dprive-rfc7626-bis@ietf.org" 

Subject: Intdir telechat review of draft-ietf-dprive-rfc7626-bis-04
Resent-From: 
Resent-To: , , 
, , Eric Vyncke 
, Suresh Krishnan , , 
Brian Haberman , 
Resent-Date: Monday, 9 March 2020 at 21:29

Reviewer: Jean-Michel Combes
Review result: Ready with Issues

Hi,

Please find my review, as member of the INT Area Directorate, of the 
following
document:

dprive S. Bortzmeyer
Internet-Draft AFNIC
Obsoletes: 7626 (if approved)   S. Dickinson
Intended status: InformationalSinodun IT
Expires: July 19, 2020  January 16, 2020

   DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-04



1.  Introduction



   Let us begin with a simplified reminder of how the DNS works (See
   also [RFC8499]).  A client, the stub resolver, issues a DNS query to
   a server, called the recursive resolver (also called caching resolver
   or full resolver or recursive name server).  Let's use the query
   "What are the  records for www.example.com?" as an example.  
   is the QTYPE (Query Type), and www.example.com is the QNAME (Query
   Name).  (The description that follows assumes a cold cache, for
   instance, because the server just started.)  The recursive resolver
   will first query the root name servers.  In most cases, the root name
   servers will send a referral.  In this example, the referral will be
   to the .com name servers.  The resolver repeats the query to one of
   the .com name servers.  The .com name servers, in turn, will refer to
   the example.com name servers.  The example.com name server will then
   return the answer.  The root name servers, the name servers of .com,
   and the name servers of example.com are called authoritative name
   servers.  It is important, when analyzing the privacy issues, to
   remember that the question asked to all these name servers is always
   the original question, not a derived question.  The question sent to
   the root name servers is "What are the  records for
   www.example.com?", not "What are the name servers of .com?".  By
   repeating the full question, instead of just the relevant part of the
   question to the next in line, the DNS provides more information than
   necessary to the name server.  In this simplified description,
   recursive resolvers do not implement QNAME minimization as described
   in [RFC7816], which will only send the relevant part of the question
   to the upstream name server.


IMHO, that would be clearer to split the previous paragraph into 2 
paragraphs:
- one explaining the general DNS process
- one showing the privacy issue related to the fact the question is not 
derived
BTW, the construction of the end of the previous paragraph suggests that
question derivation and QNAME minimization are two different things. 



   At the time of writing, almost all this DNS traffic is currently sent
   in clear (i.e., unencrypted).  However there is increasing deployment
   of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
   particularly in mobile devices, browsers, and by providers of anycast
   recursive DNS resolution services.  There are a few cases where there
   is some alternative channel encryption, for instance, in an IPsec VPN
   tunnel, at least between the stub resolver and the resolver.


IPsec: a reference is missing.




   o  Tertiary requests: these are the additional requests performed by
  the DNS system itself.  For instance, if the answer to a query is
  a referral to a set of name servers, and the glue records are not
  returned, the resolver will have to do additional requests to turn
  the name servers' names into IP addresses.  Similarly, even if
  glue records are returned, a careful recursive server will do
  tertiary requests to verify the IP addresses of those records.


“glue records”: IMHO, either a reference or a definition is needed.




2.  Scope

   This document focuses mostly on the study of privacy risks for the
   end user (the one performing DNS 

Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS)

[Eric Vyncke (evyncke)]

Hello Ben,

At least your original DISCUSS will be easy to fix as section 2.5.3 of the 
7626bis document " “rogue servers”  is currently the section 3.5.1.2 and has 
been renamed into “Active attack on resolvers configuration”.

Of course, your new and 2nd DISCUSS is still open



-éric

On 04/02/2020, 00:20, "iesg on behalf of Benjamin Kaduk via Datatracker" 
 wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dprive-bcp-op-08: Discuss

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/



--
DISCUSS:
--

This document is trying to make normative references to sections of
draft-ietf-dprive-rfc7626-bis that have not existed since the -00 of that
document, with the content having been removed for being too controversial.
Do we need to delay processing this document until 7626bis has settled down
and it is clear what content we can refer to in that vs. needing to 
incorporate
into this document?  (It's unclear that such content would be less 
controversial
in this document than in that one.)
Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of 
that document
("Rogue Servers").






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

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

[Eric Vyncke (evyncke)]

[- WG mailing list - secretariat]

Dear authors [Sara no need for urgent reply],

There were little reactions during the Last Call. Do you want to issue an 
revised ID or simply go ahead with the current revision ? With Rob Sayre's 45 
points, a revised I-D is really required (and Sara has already replied to all 
points, so, just need to issue the text).

Hence, I am changing the state to 'revised I-D needed', then the last mile run 
with IESG ballot __

-éric

On 03/02/2020, 20:17, "IETF Secretariat"  
wrote:

IESG state changed:

New State: Waiting for AD Go-Ahead::AD Followup

(The previous state was Waiting for AD Go-Ahead)


Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/



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

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

[Eric Vyncke (evyncke)]

Thanks to Sara and Stéphane for the -04 revised I-D. 

After reading the -04, I think that most of the IETF Last Call comments are 
addressed (and consensus needs to be balanced -- even for informational 
document) and that the document sticks to facts.

But, as section 3.5.1 ("in the recursive resolvers") raised a lot of 
discussions during the first IETF Last Call, and as the authors reacted to 
those comments by deep changes in the text, let's have a new IETF Last Call 
before proceeding with IESG evaluation.

Again, thank you to the reviewers and the authors

Regards,

-éric


On 20/01/2020, 22:34, "IETF Secretariat"  
wrote:

IESG state changed:

New State: Last Call Requested

(The previous state was Waiting for AD Go-Ahead::AD Followup)

The previous last call raised several points. The authors have worked on 
those points and this new informational IETF draft has substantive changes; 
enough to go trigger a new IETF Last Call.

-éric

Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/



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

[dns-privacy] Moving forward with draft-ietf-dprive-rfc7626-bis

[Eric Vyncke (evyncke)]

With my AD hat on

There have been a lot of emails following the IETF last call (that expired 2nd 
of December 2019). Up to the point that now the discussion is about commenting 
comments that were comments on a previous comment. To be honest, I have lost 
the thread here.

By this email, I am asking Sara and Stéphane to propose a revised ID trying to 
integrate the maximum feedback that are based on facts/data rather than 
opinions. Once it is done, then we can continue the discussion in a more useful 
way. If the document is heavily updated, then I am requesting another IETF last 
call.

I sincerely believe that this will be the best use of the time of this 
community.

Thank you very much Sara and Stéphane in advance for considering this request.
Thank you all for all the comments on this version of the document.

Regards,

-éric

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