Re: [dns-privacy] Key metrics

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Tuesday, June 27, 2023 9:40 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] Key metrics
>
> 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.
>
> On Jun 26, 2023, at 8:20 AM, Brian Haberman 
> wrote:
> > 2. The authors capture the key metrics submitted to the mailing list for
> assessing the experiment in a new appendix. The chairs believe that the below
> metrics proposed by Scott Hollenbeck are a good starting point but other WG
> participants may have other proposed metrics:
> >
> > A. Measurement of CPU and memory use between Do53 and DoT or DoQ.
> > B. Measurement of query response rates between Do53 and DoT or DoQ.
> > C. Measurement of server authentication successes and failures.
> > D. Measurement and descriptions of observed attack traffic, if any.
> >
>
> Are there additional key metrics we should add to the document?

[SAH] Another possibility: Comparison of transactional bandwidth 
(ingress/egress, PPS and BPS) used between Do53 and DoT or DoQ.

Scott

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

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

[Hollenbeck, Scott]

From: Tim Wicinski 
Sent: Friday, June 9, 2023 9:44 PM
To: Hollenbeck, Scott 
Cc: paul.hoff...@icann.org; dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
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.

Scott



On Fri, Jun 9, 2023 at 1:42 PM Hollenbeck, Scott 
mailto:40verisign@dmarc.ietf.org> > wrote:



[SAH] We might be disagreeing on the nature of experimentation, but I most
definitely provided examples of specific, measurable metrics that could be
used to evaluate an experiment:

https://mailarchive.ietf.org/arch/msg/dns-privacy/tA7Wo_cllWhWqjwaQTs50Ses-KI/ 
<https://secure-web.cisco.com/1rqB_3Wjy4E9-TRoAKzvMoQEKW0JvsNYYOhZ-0tm5cRnZFGoDRTR18vQ0zGASp68NiV85QiHyV-0-455x9gN9gqn7lzlpDlhh0B_uqky1QiwnOD7IBvzDf-lfoEk0i5V3zp7LRPGKUnEkN8xNBXZEKN7HBhIb60ugl5T5CIwKmMscyn2QTmiRv14lHcigy9x1PIvfxAtYmvnc_O7P8UfuKP6AFCz-dc02miE8k9k97LDoCSZQGhv1rV-gHjjDkbPhWSou8yDY9Eb1hzqxXPB4GoCDsQvjrBy_kRDJHcMtD4oy_101l9riAh4YoMY80f92/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdns-privacy%2FtA7Wo_cllWhWqjwaQTs50Ses-KI%2F>

WRT observations, we do have a WG wiki we could use:

https://wiki.ietf.org/group/dprive 
<https://secure-web.cisco.com/1swQEBenLfIYyHQGjOabvyt5UKR2YL-XlrbeTlAk5mvQwU1G9AQMDFYiZqLOE5P2J08xcxYnyXXLGun1EQLputcHErJXa48X3MHFUta2xDRaWwnX_go_bVHKK3yl-JQAx5uQXU7EpjT4Qn6QOhoBf3YlX7VP4AJJ6_DPcmStquK530QFGZdBdMpik3WiG0Tdj3OgCN8p6UoEa3EQlso5TeEq7Ksv8e51Pm2BAprbuuXdHHVgQnjoq0WvxtT76rlBxSWyOXjIY2DYg4lGeaPITkv1KxDMZpcOv0Y-sp-tXIc0g3fc4Vs3ed4RBD1VbwG7k/https%3A%2F%2Fwiki.ietf.org%2Fgroup%2Fdprive>



Would you be able to produce some of these measurements based on experiments 
you run?

That would be super useful.



tim



[SAH] I’m looking into what I can and cannot do.



Scott

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Friday, June 9, 2023 10:52 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
> 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.
>
> I'm hearing a bit of support for the proposal of changing the WG charter, 
> but
> more support for not changing the charter and issuing the protocol as
> experimental. There have been no proposals for specific metrics for how to
> judge the experiment, so it is likely to be "two years, add some operational
> observations, and move it to standards track".

[SAH] We might be disagreeing on the nature of experimentation, but I most 
definitely provided examples of specific, measurable metrics that could be 
used to evaluate an experiment:

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

WRT observations, we do have a WG wiki we could use:

https://wiki.ietf.org/group/dprive

Scott

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

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

[Hollenbeck, Scott]

From: Rob Sayre 
Sent: Thursday, June 8, 2023 6:11 PM
To: Hollenbeck, Scott 
Cc: paul.hoff...@icann.org; dns-privacy@ietf.org
Subject: [EXTERNAL] Re: Re: [dns-privacy] [Ext] WGLC : 
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.

On Wed, Jun 7, 2023 at 2:05 PM Hollenbeck, Scott mailto:shollenb...@verisign.com> > wrote:



On Jun 6, 2023, at 8:42 PM, Rob Sayre mailto:say...@gmail.com> > wrote

On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott 
mailto:40verisign@dmarc.ietf.org> > wrote:

Measurement of CPU and memory use between Do53 and DoT or DoQ.
Measurement of query response rates between Do53 and DoT or DoQ.
Measurement of server authentication successes and failures.
Measurement and descriptions of observed attack traffic, if any.

...

[SAH] It would be unreasonable if we were discussing a proposal that had no 
impact on root and TLD name servers. Under some conditions, this proposal can 
affect their ability to perform their primary function of responding to DNS 
queries. Those conditions need to be understood.



I think the measurements you suggest make perfect sense. I don't think there 
is anything in the IETF process that leads to the conclusion that this draft 
must be Experimental as a result, though. So, my objection is about the ad-hoc 
process created for this draft. I also don't get the impression that this 
draft would enjoy instant adoption, so there would be time to slowly ramp it 
up. For example, 23 years separate RFC 2616 from RFC 9112, but they are both 
on the standards track.

[SAH] The IESG deliberately chartered this working group to “Investigate 
potential solutions for adding confidentiality to DNS exchanges involving 
authoritative servers” in an Experimental manner. As Brian noted, that’s a 
binding agreement with the IESG. We can either do that or attempt to 
re-charter the working group. I’m under the impression that Brian’s last note 
to the group was a request to discuss those two options, which could include 
discussion of how to conduct the experiment. It’s not an ad-hoc process at 
all.



Additionally, some of the operators of those services are subject to 
regulators who commonly require them to implement, deploy, and operate IETF 
standards. That’s another good reason to do our best to understand the 
operational impact before this becomes a proposed standard.



I never like to read stuff like this. Each of us probably has a regulator that 
annoys us in their treatment of some issue. But we can't really make decisions 
based on guesses about the future actions of unnamed regulators. I'm also sure 
you know the document ladder quite well, but you've used imprecise terms here. 
In the first sentence, you say "IETF standards". But the last sentence says 
"proposed standard".



[SAH] I used those terms deliberately. My employer has contractual obligations 
to implement a mix of IETF-developed Proposed Standard and Standard 
specifications – that is, “IETF standards”. In the last sentence, “proposed 
standard” specifically refers to one possible status for this draft.



Scott

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

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

[Hollenbeck, Scott]

On Jun 6, 2023, at 8:42 PM, Rob Sayre  wrote:



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.


On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott 
mailto:40verisign@dmarc.ietf.org>>
 wrote:
Measurement of CPU and memory use between Do53 and DoT or DoQ.
Measurement of query response rates between Do53 and DoT or DoQ.
Measurement of server authentication successes and failures.
Measurement and descriptions of observed attack traffic, if any.

Hi,

I don't think this kind of argument is reasonable. Just let them propose a 
standard. There is nothing requiring anyone to implement it, as the IETF has no 
enforcement function.

[SAH] It would be unreasonable if we were discussing a proposal that had no 
impact on root and TLD name servers. Under some conditions, this proposal can 
affect their ability to perform their primary function of responding to DNS 
queries. Those conditions need to be understood. Additionally, some of the 
operators of those services are subject to regulators who commonly require them 
to implement, deploy, and operate IETF standards. That’s another good reason to 
do our best to understand the operational impact before this becomes a proposed 
standard.

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Tuesday, June 6, 2023 11:05 AM
> To: Hollenbeck, Scott 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC :
> 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.
>
> On Jun 6, 2023, at 7:49 AM, Hollenbeck, Scott 
> wrote:
> > [SAH] The criteria to conduct the experiment and measure the outcome
> > could be documented in the current draft.
>
> Please propose such criteria. I ask because I feel that the likely criteria
> (at least
> one resolver implementation, one server implementation, and interop testing
> between the two of them) has already been met.

[SAH] I'm thinking about experimentation more in the context of measuring 
operational impact and not so much as a pass/fail thing. For example:

Measurement of CPU and memory use between Do53 and DoT or DoQ.
Measurement of query response rates between Do53 and DoT or DoQ.
Measurement of server authentication successes and failures.
Measurement and descriptions of observed attack traffic, if any.

Even if these measurements are operator dependent, this is the kind of 
experimentation that every name server operator will find invaluable in terms 
of understanding if/how they can implement and deploy the protocol,.

> Or are you saying that, if we include the criteria in the current draft, and
> show
> that they are met, that we can proceed on standards track without changing
> the charter?

[SAH] No, because the current intended status is inconsistent with the current 
charter. That needs to be resolved.

> > From there:
> >
> > Publish experimental RFC.
> > Conduct experiment.
> > Publish RFCbis I-D to document the results of the experiment with
> > informational status for failure or standards track for success.
>
> See above.

[SAH] Noted. If we take a measurement approach, and not a pass/fail approach, 
we can eliminate the "fail" possibility.

> > Assuming success, recharter to publish RFCbis I-D on the standards track.
> > Adopt RFCbis I-D as a working group document.
> > Working group works to publish RFCbis on the standards track.
> >
> > Paul is correct in noting that there's more IETF effort associated
> > with the above. It's worth making that effort to ensure that the risks
> > to critical internet infrastructure are minimized.
>
> How would you put that (legitimate!) concern into a criterion for the
> experiment?

[SAH] I'd like to see the experiment described more in terms of measurement as 
I've described above. It doesn't have to be categorized as pass/fail.

Scott

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Tuesday, June 6, 2023 9:44 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
> 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.
>
> On Jun 5, 2023, at 8:12 PM, Brian Haberman 
> wrote:
> >
> > Tim & I checked in with our AD on this. Given that the charter text calls 
> > out
> Experimental, that is a binding agreement with the IESG.
> >
> > Our choices are simple:
> >
> > 1) publish as Experimental
> > 2) re-charter
> >
> > If the intended status had just been in the milestones, we would have more
> flexibility.
> >
> > Let’s constructively discuss the above options.
>
> One large problem with publishing a protocol as "experimental" is there is 
> not
> objective way to exit that status. There are no criteria that say "this 
> experiment
> succeeded" or "this experiment failed".
>
> It will take much less IETF effort to fix the charter now than it will to 
> move the
> already-deployed protocol to standards track. We might as well bit the
> bureaucratic bullet now and just fix the charter. If most folks agree, I can 
> do
> that work.

[SAH] The criteria to conduct the experiment and measure the outcome could be 
documented in the current draft. From there:

Publish experimental RFC.
Conduct experiment.
Publish RFCbis I-D to document the results of the experiment with 
informational status for failure or standards track for success.
Assuming success, recharter to publish RFCbis I-D on the standards track.
Adopt RFCbis I-D as a working group document.
Working group works to publish RFCbis on the standards track.

Paul is correct in noting that there's more IETF effort associated with the 
above. It's worth making that effort to ensure that the risks to critical 
internet infrastructure are minimized.

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Monday, June 5, 2023 4:02 PM
> To: Tim Wicinski 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
> 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.
> 
> On Jun 5, 2023, at 12:45 PM, Tim Wicinski  wrote:
> > The Chairs and Eric are working on the asumption that the document will be
> parked waiting for another implementation or two and some interopt testing
> >
> > However, we are usinfg this time for Early area reviews which will feel will
> bei invaluable moving forward.
> > We focused on the Security area, Int Area, and those pesky DNS folks to
> review the documennt
> >
> > I believe at IETF 117 there was some discussion of some interopt testing
> during the hackathon?
> > I may have made that up also.
> >
> > The authors have been working diligently updating their work, and Paul is 
> > just
> letting the WG know they've done their part.
> 
> Er, no, we really do believe that all the interop testing done at IETF 116, 
> which
> is reported in the draft, is sufficient. It is certainly more than the amount 
> that
> many other protocols get before they are published as RFCs.
> 
> How much more interop testing is needed before the document can proceed?
> There will be parties like Verisign that will never want this to be on 
> standards
> track, which is fine, but that has never been an acceptable reason to block
> progress when there are others who have already implemented it.

[SAH] To be clear: Verisign, an authoritative name server operator, is not 
opposed to this draft being on the standards track. I support publication in a 
manner that's consistent with the WG charter. I *am* opposed to the draft being 
a candidate for standards track publication as long as the charter says 
"experimental".

Scott

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Monday, June 5, 2023 3:32 PM
> To: Tim Wicinski 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
> 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.
>
> We have turned in -07, which covers Yorgos' issues (thanks!) and the int-dir
> review (thanks!). We believe it is ready to move to IETF Review.

[SAH] Please help me understand the process we're following here. I thought 
that Brian said the document would be parked for a period of experimentation 
time before asking for an IETF last call that commonly precedes IESG review.

Scott

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul Hoffman
> Sent: Friday, May 26, 2023 2:01 PM
> To: dns-privacy@ietf.org
> Cc: George Thessalonikefs 
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : 
> 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.
>
> On Apr 14, 2023, at 11:14 AM, Brian Haberman 
> wrote:
> >
> > All,
> > An update on the status of this draft. I have asked the authors to 
> > review all
> the feedback, provide the mailing list with responses to the comments, and
> then publish a new version.
>
> We believe that -06 deals with all of the WG Last Call issues raised, except 
> one.
> We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could 
> you
> reformulate that concern based on the -06 draft?

[SAH] I'd like to thank the editors for the work they put into addressing the 
feedback received during the last call. There is, however, one other issue I 
identified that remains open: the intended status of the draft (Standards 
Track) and the chartered work item associated with the draft ("Investigate 
potential solutions for adding confidentiality to DNS exchanges involving 
authoritative servers (Experimental)") remain inconsistent. Brian said that 
"We will revisit the status of the document before it gets advanced to our AD" 
when he announced the start of the last call on 12 March. In the absence of an 
issue tracker for the draft, I'd like to ensure that this isn't forgotten.

Scott

___
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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Sunday, March 12, 2023 11:43 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] WGLC : 
> draft-ietf-dprive-unilateral-probing
>
> 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.

[SAH] The operational practices described in the draft are, I believe, 
complete. They are, however, based on two normative references that are 
incomplete, or potentially incomplete, for the purpose of 
recursive-to-authoritative encryption. As I noted on-list previously, RFC 7858 
(DoT) explicitly notes that it "focuses on securing stub-to-recursive traffic, 
as per the charter of the DPRIVE Working Group.  It does not prevent future 
applications of the protocol to recursive-to-authoritative traffic" and that 
"It might work equally between recursive clients and authoritative servers". 
Section 5.1 of RFC 9250 (DoQ) explicitly notes that "For the recursive to 
authoritative scenario, authentication requirements are unspecified at the 
time of writing and are the subject of ongoing work in the DPRIVE WG". 
Implementations of this draft could help identify the unknowns in RFC 7858 and 
RFC 9250. I support the research and experimentation effort needed to address 
those unknowns, and I will suggest again that the draft should include text to 
explicitly acknowledge the limitations that are plainly described in both 
RFCs. The draft could note these limitations in Section 2.2 by changing the 
first paragraph from this:

"Although this document focuses specifically on strategies used by DNS 
servers, it does not go into detail on the specific protocols used because 
those protocols, in particular DoT and DoQ, are described in other documents."

To this, or something similar:

"Although this document focuses specifically on strategies used by DNS 
servers, it does not go into detail on the specific protocols used because 
those protocols, in particular DoT and DoQ, are described in other documents.
DoT explicitly notes that it "focuses on securing stub-to-recursive traffic, 
as per the charter of the DPRIVE Working Group.  It does not prevent future 
applications of the protocol to recursive-to-authoritative traffic" and that 
"It might work equally between recursive clients and authoritative servers".
Section 5.1 of DoQ explicitly notes that "For the recursive to authoritative 
scenario, authentication requirements are unspecified at the time of writing 
and are the subject of ongoing work in the DPRIVE WG". Additional 
specification work might be required to ensure that DoT and DoQ work reliably 
in this context."

I do not support the draft without text that addresses these limitations in 
its normative references.

It would also be helpful to include text that explains the goals behind it 
being parked. An "Implementation Status" section as described by RFC 7942 
could serve that purpose, and it could be expanded as implementations are 
identified.

>   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.

[SAH] The suggestion was made to align the status of this document with the 
working group's charter:

"Investigate potential solutions for adding confidentiality to DNS exchanges 
involving authoritative servers (Experimental)."

This working group is not currently chartered to develop a standards track 
specification for "adding confidentiality to DNS exchanges involving 
authoritative servers". As such, I support alignment of the draft's intended 
status with the working group's charter (moving it to Experimental) while it's 
parked in the "Waiting for Implementation" state.

Scott
___
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

[Hollenbeck, Scott]

Brian,

I've just confirmed that xml2rfc will not accept an input file that's missing 
the "category" attribute from the  element, so the Intended Status field 
can't be omitted. Given that the charter says that the working group's effort 
in this area is Experimental, I'd be more comfortable with "Experimental" as 
the intended status until a determination is made to change that status.

Yes, I am concerned that the intended status will influence comments and other 
contributions. For example, I am much less concerned about an experimental 
document saying "An authoritative server SHOULD implement and deploy 
DNS-over-TLS (DoT) on TCP port 853" and "An authoritative server SHOULD 
implement and deploy DNS-over-QUIC (DoQ) on UDP port 853" than I am about a 
standards track document saying the same thing. Context is significant.

Additionally, Verisign has disclosed intellectual property associated with the 
draft; license terms have not yet been declared. The intended status is a 
factor in the development of those license terms.

> Does the fact that we will not request publication until there are 2 or more
> interoperable implementations affect your thought process?

It does, and yes, descriptive text would help. I'd like to see text in the 
draft itself because readers may not know what was said during the last call 
announcement. There's no chance for confusion if the draft itself describes 
the process being followed for its development.

Scott

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Monday, March 6, 2023 8:09 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Intended Status for draft-ietf-
> dprive-unilateral-probing
>
> Scott,
>   The intended status field only allows for a few fixed values.
> There isn't a way, that I know of, to add free form text with the type of
> description you are requesting.
>
>   Is the concern that the intended status will influence WGLC comments?
> Does the fact that we will not request publication until there are 2 or more
> interoperable implementations affect your thought process?
>
>   Would descriptive text in the text starting WGLC that points out the 
> process
> suffice?
>
> Regards,
> Brian
>
> On 3/6/23 8:02 AM, Hollenbeck, Scott wrote:
> > Thanks, Eric. Given what you and Tim have said, I’m still concerned that 
> > the
> document has a header that says “Intended status: Standards Track”. If the
> status of the document is to be determined later, that header should be
> removed for now and text should be added to explain the process being
> followed here.
> >
> >
> >
> > Scott
> >
> >
> >
> > From: dns-privacy  On Behalf Of Eric
> > Vyncke (evyncke)
> > Sent: Monday, March 6, 2023 1:48 AM
> > To: Hollenbeck, Scott ;
> > tjw.i...@gmail.com
> > 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.
> >
> > 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
> > mailto:dns-privacy-boun...@ietf.org>> on
> > behalf of "Hollenbeck, Scott"
> > mailto:shollenbeck=40verisi
> > gn@dmarc.ietf.org>>
> > Date: Friday, 3 March 2023 at 19:13
> > To: "tjw.i...@gmail.com<mailto:tjw.i...@gmail.com>"
> > mailto:tjw.i...@gmail.com>>
> > Cc: "paul.hoff...@icann.org<mailto:paul.hoff...@icann.org>"
> > mailto:paul.hoff...@icann.org>>,
> > "dpr...@ietf.org<mailto:dpr...@ietf.org>"
> > mailto:dpr...@ietf.org>>
> > Subject: Re: [dns-privacy] [Ext] Intended Status for
> > draft-ietf-dprive-unilateral-probing
> >
> >
> >
> > From: Tim Wicinski mailto:tjw.i...@gmail.com>>
> > Sent: Friday, March 3, 2023 12:59 PM
> > To: Hollenbeck, Scott
> > mailto:shollenb...@verisign.com>>
> > Cc: paul.hoff...@icann.org<mailto:paul.hoff...@icann.org>;
> > dpr...@ietf.org<mailto:dpr...@ietf.org>
> > Subject: [EXTERNAL] Re

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

[Hollenbeck, Scott]

Thanks, Eric. Given what you and Tim have said, I’m still concerned that the 
document has a header that says “Intended status: Standards Track”. If the 
status of the document is to be determined later, that header should be removed 
for now and text should be added to explain the process being followed here.



Scott



From: dns-privacy  On Behalf Of Eric Vyncke 
(evyncke)
Sent: Monday, March 6, 2023 1:48 AM
To: Hollenbeck, Scott ; 
tjw.i...@gmail.com
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.

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 
mailto:dns-privacy-boun...@ietf.org>> on behalf 
of "Hollenbeck, Scott" 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
Date: Friday, 3 March 2023 at 19:13
To: "tjw.i...@gmail.com<mailto:tjw.i...@gmail.com>" 
mailto:tjw.i...@gmail.com>>
Cc: "paul.hoff...@icann.org<mailto:paul.hoff...@icann.org>" 
mailto:paul.hoff...@icann.org>>, 
"dpr...@ietf.org<mailto:dpr...@ietf.org>" 
mailto:dpr...@ietf.org>>
Subject: Re: [dns-privacy] [Ext] Intended Status for 
draft-ietf-dprive-unilateral-probing



From: Tim Wicinski mailto:tjw.i...@gmail.com>>
Sent: Friday, March 3, 2023 12:59 PM
To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>
Cc: paul.hoff...@icann.org<mailto:paul.hoff...@icann.org>; 
dpr...@ietf.org<mailto: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

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

[Hollenbeck, Scott]

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

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

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Thursday, March 2, 2023 1:48 PM
> To: Hollenbeck, Scott 
> Cc: 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.
>
> On Mar 2, 2023, at 10:11 AM, Hollenbeck, Scott
>  wrote:
> >
> >> -Original Message-
> >> From: Paul Hoffman 
> >> Sent: Wednesday, March 1, 2023 2:51 PM
> >> To: Hollenbeck, Scott 
> >> Cc: dpr...@ietf.org
> >> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] 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.
> >>
> >> On Mar 1, 2023, at 10:46 AM, Hollenbeck, Scott
> >>  wrote:
> >>> After a recent-re-read of draft-ietf-dprive-unilateral-probing and
> >>> its
> >> normative dependencies, I have a strong belief that the draft
> >> describes
> > more of
> >> an experiment than a Proposed Standard.
> >>
> >> All protocols before they are deployed are experiments.
> >>
> >>> The reason we need "opportunistic" and "unilateral" actions is
> >>> because
> > there
> >> are gaps in specification, implementation, and deployment of services
> >> for recursive-authoritative encryption.
> >>
> >> That is not what the WG decided. It decided that opportunistic was
> > sufficient for
> >> some threat models. Other threat models have the gaps you discuss.
> >
> > [SAH] WG decisions aren't immutable. I posted this as a proposal for
> > reconsideration.
> >
> >>> Experimental status worked for QNAME minimization.
> >>
> >> That's irrelevant.
> >>
> >>> It can work here, too.
> >>
> >> So could Informational; that is also irrelevant.
> >
> > [SAH] It's hardly irrelevant given the successful approach taken with
> > QNAME minimization. It's a valid example of how Experimental status could
> work.
>
> The experimental status of the original QNAME minimisation document was
> due to there being protocol options that the WG thought could not be chosen
> between without data from deployments. That is not the case with draft-ietf-
> dprive-unilateral-probing. In fact, the opposite is the case: because the 
> probing
> is unilateral, the resolver gets to make its own choices about what is working
> and what is not. That's the whole point of the decision ladders in the 
> document.

[SAH] Perhaps, but this is what the working group's charter says about this 
topic:

"Investigate potential solutions for adding confidentiality to DNS exchanges 
involving authoritative servers (Experimental)."

Experimental. Not Proposed Standard.

Scott

___
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

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Wednesday, March 1, 2023 2:51 PM
> To: Hollenbeck, Scott 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] 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.
>
> On Mar 1, 2023, at 10:46 AM, Hollenbeck, Scott
>  wrote:
> > After a recent-re-read of draft-ietf-dprive-unilateral-probing and its
> normative dependencies, I have a strong belief that the draft describes
more of
> an experiment than a Proposed Standard.
>
> All protocols before they are deployed are experiments.
>
> > The reason we need "opportunistic" and "unilateral" actions is because
there
> are gaps in specification, implementation, and deployment of services for
> recursive-authoritative encryption.
>
> That is not what the WG decided. It decided that opportunistic was
sufficient for
> some threat models. Other threat models have the gaps you discuss.

[SAH] WG decisions aren't immutable. I posted this as a proposal for 
reconsideration.

> > Experimental status worked for QNAME minimization.
>
> That's irrelevant.
>
> > It can work here, too.
>
> So could Informational; that is also irrelevant.

[SAH] It's hardly irrelevant given the successful approach taken with QNAME 
minimization. It's a valid example of how Experimental status could work.

Informational could also work. It's not as accurate, but it is another option.

> The definition for the Experimental maturity level, taken from RFC 2026,
is:
>
> 4.2.1  Experimental
>
>The "Experimental" designation typically denotes a specification that
>is part of some research or development effort.  Such a specification
>is published for the general information of the Internet technical
>community and as an archival record of the work, subject only to
>editorial considerations and to verification that there has been
>adequate coordination with the standards process (see below).  An
>Experimental specification may be the output of an organized Internet
>research effort (e.g., a Research Group of the IRTF), an IETF Working
>Group, or it may be an individual contribution.
>
> This draft is not a research effort, nor is it a development effort. It is
a protocol
> that can be used (and, to a limited extent, is already being used) on the
Internet
> today.

[SAH] I am suggesting that it SHOULD be described as a research effort because 
of the specification gaps. Is it really a great idea to publish a Proposed 
Standard that includes a normative reference that explicitly says that it 
wasn't designed for this specific purpose?

One "already being used" example that I've recently seen 
(https://ant.isi.edu/events/dinr2023/S/s43.pdf) describes itself as "research" 
and an "experiment". Not as a prototype, or a proof of concept, but as 
research and an experiment. That description aligns much more closely with 
Experimental status than Proposed Standard status. I've asked Wes privately if 
he could provide his own perspective.

Scott

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

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

[Hollenbeck, Scott]

After a recent-re-read of draft-ietf-dprive-unilateral-probing and its 
normative dependencies, I have a strong belief that the draft describes more of 
an experiment than a Proposed Standard. The reason we need "opportunistic" and 
"unilateral" actions is because there are gaps in specification, 
implementation, and deployment of services for recursive-authoritative 
encryption. Experimentation will help identify solutions to fill those gaps. 
Some examples:

We don't yet have a published standards track RFC that describes how an 
authoritative name server should publish capability information 
(draft-ietf-add-svcb-dns is still in the RFC Editor queue). It's not widely 
implemented or deployed. draft-ietf-dprive-unilateral-probing addresses this 
gap, describing how a recursive resolver can probe opportunistically to see if 
an authoritative name server will accept a connection on port 853 in the 
absence of server-published information.

RFC 7858 explicitly notes that it "focuses on securing stub-to-recursive 
traffic, as per the charter of the DPRIVE Working Group.  It does not prevent 
future applications of the protocol to recursive-to-authoritative traffic" and 
that "It might work equally between recursive clients and authoritative 
servers". This is a specification gap, and work is required to ensure that DoT 
works reliably in this context. Experimentation would help determine if/how RFC 
7858 needs to be updated. The draft should note this limitation in Section 2.2. 
I'd like to suggest changing the first paragraph from this:

"Although this document focuses specifically on strategies used by DNS servers, 
it does not go into detail on the specific protocols used because those 
protocols, in particular DoT and DoQ, are described in other documents."

To this:

"Although this document focuses specifically on strategies used by DNS servers, 
it does not go into detail on the specific protocols used because those 
protocols, in particular DoT and DoQ, are described in other documents. DoT 
explicitly notes that it "focuses on securing stub-to-recursive traffic, as per 
the charter of the DPRIVE Working Group.  It does not prevent future 
applications of the protocol to recursive-to-authoritative traffic" and that 
"It might work equally between recursive clients and authoritative servers". 
Additional specification work might be required to ensure that DoT works 
reliably in this context."

RFC 9250 is more definitive about support for recursive-authoritative 
encryption, but it has a gap, too. Section 5.1 explicitly notes that "For the 
recursive to authoritative scenario, authentication requirements are 
unspecified at the time of writing and are the subject of ongoing work in the 
DPRIVE WG". This is a specification gap, and experimentation would help 
determine if/how RFC 9250 needs to be updated.

Experimental status worked for QNAME minimization. It can work here, too. If 
the working group agrees, it could be helpful to add text to the draft to 
describe the nature of the experiment. Section 2 would be a good place for 
that. I'm willing to contribute text.

I also noticed that RFCs 7858 and 9250 are identified as informative 
references. Section 3 says that an authoritative name server "MUST implement at 
least one of DoT or DoQ on port 853". That's a normative requirement. Both RFCs 
should be identified as normative references.

Scott

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

[dns-privacy] Operator Positions on Recursive-to-Authoritative Encryption

[Hollenbeck, Scott]

During yesterday's working group meeting, there was some discussion of 
authoritative name server operator positions on support for encryption. I 
mentioned Verisign's position back in 2019:

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

Verisign also supports the statement of the root server operators on DNS 
encryption:

https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf

Scott

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

Re: [dns-privacy] [Ext] Security Considerations: Traffic Analysis

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Wouters 
> Sent: Monday, August 16, 2021 1:05 PM
> To: Hollenbeck, Scott 
> Cc: paul.hoff...@icann.org; dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Security Considerations: Traffic
> Analysis
>
> 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.
>
> On Aug 16, 2021, at 12:43, Hollenbeck, Scott
>  wrote:
> >
> >> Neither of the proposed protocols have any way for an end user to
> >> know what part of the recursive-to-authoritative traffic used to
> >> answer their query (if any) was encrypted.
> >
> > [SAH] It's not just about end users. Operators who implement and
> > deploy this technology need to understand its limitations
>
> What would a recursive DNS server do different if the encrypted connection
> might be reduced to plaintext ? It’s only options are “keep using it” or
> “fallback to clear text”

[SAH] They can employ data minimization techniques to reduce the amount of 
information sent to the authoritative server. They can pad the payloads.

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

Re: [dns-privacy] [Ext] Security Considerations: Traffic Analysis

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Monday, August 16, 2021 11:28 AM
> To: Hollenbeck, Scott 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Security Considerations: Traffic
> Analysis
>
> On Aug 16, 2021, at 7:51 AM, Hollenbeck, Scott
>  wrote:
> >
> > [SAH] The act of encrypting may mislead someone into thinking that their
> confidentiality concerns have been completely addressed.
>
> Neither of the proposed protocols have any way for an end user to know
> what part of the recursive-to-authoritative traffic used to answer their query
> (if any) was encrypted.

[SAH] It's not just about end users. Operators who implement and deploy this 
technology need to understand its limitations.

> > In lieu of the text I proposed, yes, references to RFCs such as 8932 and 
> > 9076
> could help make it clear that privacy considerations remain even if encryption
> is used.
>
> We'll do that.

[SAH] Thanks!

Scott

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

Re: [dns-privacy] [Ext] Security Considerations: Traffic Analysis

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Monday, August 16, 2021 10:19 AM
> To: Hollenbeck, Scott 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Security Considerations: Traffic
> Analysis
> 
> On Aug 16, 2021, at 5:14 AM, Hollenbeck, Scott
>  wrote:
> >
> > The iterative nature of recursive resolution gives an on-path monitor
> multiple opportunities to observe query traffic between a recursive resolver
> and an authoritative name server. Even with encryption, the name server IP
> addresses can be used to draw accurate conclusions about qnames by
> matching IP addresses to name servers identified in publicly available zones.
> This is something that needs to be addressed in the Security Considerations
> section of any draft that describes a recursive-to-authoritative encryption
> solution.
> >
> > draft-ietf-dprive-dnsoquic addresses traffic analysis, but 
> > draft-ietf-dprive-
> unauth-to-authoritative does not. draft-rescorla-dprive-adox-latest
> addresses it somewhat. I'd like to suggest that text like this (or something
> similar) be added to draft-ietf-dprive-unauth-to-authoritative and draft-
> rescorla-dprive-adox-latest:
> >
> >
> > BEGIN
> > Encryption is one of several controls that can reduce the risk of
> > disclosure of sensitive information. Resolver-to-authoritative DNS
> encryption will protect the DNS traffic exchanged between the resolver and
> the authoritative name server from being directly observed and/or modified
> by an adversary. However, as in other systems where encryption is
> deployed, implementers should also consider other ways in which the same
> or related information may also be exposed, and how to mitigate those risks.
> For example, encryption provides confidentiality protection for DNS query
> and response payloads between recursive resolvers and authoritative name
> servers, but iterative resolution makes it possible to perform traffic 
> analysis
> using other, non-encrypted information that can be observed in subsequent
> iteration steps. The names and IP addresses of the name servers for most
> DNS zones are publicly available, so an attacker that can monitor traffic
> exchanged between a resolver and an authoritative n ame server will often
> be able to identify the zone of interest based on the IP address of the
> authoritative name server. Iterative resolution using destination IP addresses
> that were encrypted in a previous query makes it possible to identify the set
> of domains that might be associated with a query by observing the
> destination IP address and comparing that to the addresses and names
> found in publicly-available zone files. This risk can be reduced by limiting 
> the
> number of queries sent to authoritative name servers using techniques such
> as hyperlocal root processing [RFC7706], NXDOMAIN cut processing
> [RFC8020], and aggressive DNSSEC caching [RFC8198].
> >
> > The size of encrypted query and response packets can also be used to
> detect query patterns. The set of name servers and IP addresses returned in
> a response to a query changes infrequently, so the size of the DNS response
> for a specific set of name servers tends to stay the same during a given time
> period. The size of responses can be monitored to observe patterns
> associated with responses from specific name servers, and this information
> can be used to identify queries for specific domain names. This risk can be
> reduced by padding the record payload of TLS-protected responses to
> eliminate response size variability.
> >
> > Additional traffic analysis considerations are described in a paper titled
> "Encrypted DNS =⇒ Privacy? A Traffic Analysis Perspective" [1].
> >
> > [1]
> > https://secure-
> web.cisco.com/1BnLOTztjAEEKsTmNTQ12s7CJTbafBHe2ULMhaC1Z
> > pPluwYnbvLJZjTfUJiuCogPIu-
> CmzqUwtazRCiChJfxqCkIQJjG9KIcwFnFC89CHAAB-7w
> > KRGczojrlT43PRxGTtxnmneycEX6VYcQ4afNDxMmSl0aVh-
> a30oKKtS3pXXyKT_NlmS5Ul
> > S483kVZJq_cAUtePhPFHfy8fGP7NZun64UE-
> yAI8E1BcuhX7O89L28xy1jIB0eRBTv-1e1
> > yIsZgo/https%3A%2F%2Fwww.ndss-symposium.org%2Fwp-
> content%2Fuploads%2F2
> > 020%2F02%2F24301-paper.pdf
> > END
> 
> This seems misplaced. The act of encrypting recursive to authoritative does
> not add any more considerations for "other ways in which the same or
> related information may also be exposed, and how to mitigate those risks".
> Instead of listing just a few privacy considerations, wouldn't it be better to
> have the reader go to the more complete list in RFC 8932 and RFC 9076?

[SAH] The act of encrypting may mislead someone into thinking that their 
confidentiality concerns have been completely addressed. In lieu of the text I 
proposed, yes, references to RFCs such as 8932 and 9076 could help make it 
clear that privacy considerations remain even if encryption is used.

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

Re: [dns-privacy] Security Considerations: Traffic Analysis

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Wouters
> Sent: Monday, August 16, 2021 8:38 AM
> To: Hollenbeck, Scott 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] Security Considerations: Traffic
> Analysis
> 
> 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.
> 
> On Mon, 16 Aug 2021, Hollenbeck, Scott wrote:
> 
> > The iterative nature of recursive resolution gives an on-path monitor
> multiple opportunities to observe query traffic between a recursive resolver
> and an authoritative name server. Even with encryption, the name server IP
> addresses can be used to draw accurate conclusions about qnames by
> matching IP addresses to name servers identified in publicly available zones.
> This is something that needs to be addressed in the Security Considerations
> section of any draft that describes a recursive-to-authoritative encryption
> solution.
> 
> It can be pointed out, would I would not say it can be "addressed".

[SAH] Perhaps, but that's why I included potential mitigations. There are 
things that can be done to reduce the risk.

> > BEGIN
> > Encryption is one of several controls that can reduce the risk of
> > disclosure of sensitive information. Resolver-to-authoritative DNS
> > encryption will protect the DNS traffic exchanged between the resolver
> > and the authoritative name server from being directly observed and/or
> > modified by an adversary. However, as in other systems where
> > encryption is deployed, implementers should also consider other ways
> > in which the same or related information may also be exposed, and how
> > to mitigate those risks. For example, encryption provides
> > confidentiality protection for DNS query and response payloads between
> > recursive resolvers and authoritative name servers, but iterative
> > resolution makes it possible to perform traffic analysis using other,
> > non-encrypted information that can be observed in subsequent iteration
> > steps. The names and IP addresses of the name servers for most DNS
> > zones are publicly available, so an attacker that can monitor traffic
> > exchanged between a resolver and an authoritative
>   n
> 
> DNS padding (RFC 7830) could be mentioned to hide the exact packet size of
> DNS queries/responses.

[SAH] Agreed.

> > ame server will often be able to identify the zone of interest based on the
> IP address of the authoritative name server. Iterative resolution using
> destination IP addresses that were encrypted in a previous query makes it
> possible to identify the set of domains that might be associated with a query
> by observing the destination IP address and comparing that to the addresses
> and names found in publicly-available zone files. This risk can be reduced by
> limiting the number of queries sent to authoritative name servers using
> techniques such as hyperlocal root processing [RFC7706], NXDOMAIN cut
> processing [RFC8020], and aggressive DNSSEC caching [RFC8198].
> 
> I'm not sure I agree with "often" and "make it possible". That really depends
> on the number of zones hosted by the particular nameserver and the
> particular service contacted after the lookup. If the nameserver hosts 1M
> domains, and the target webserver hosts 1K domains, it might still be
> possible to somewhat hide what you were talking to.

[SAH] Somewhat hide, yes.

> > The size of encrypted query and response packets can also be used to
> detect query patterns. The set of name servers and IP addresses returned in
> a response to a query changes infrequently, so the size of the DNS response
> for a specific set of name servers tends to stay the same during a given time
> period. The size of responses can be monitored to observe patterns
> associated with responses from specific name servers, and this information
> can be used to identify queries for specific domain names. This risk can be
> reduced by padding the record payload of TLS-protected responses to
> eliminate response size variability.
> 
> As I said, DNS padding can be used for that.
> 
> But in general, a little bit of this discussion is suitable in the Security
> Considerations. But clearly, we can't add a multitude of research papers in
> this section. Perhaps the goals can be stated more realistically, eg "use
> encryption to not make it trivially easy for any on-path attaker to see your
> DNS" and ensure there is no expectation of "total anonymity".

[SAH] Thanks for confirming the need for the discussion. I mentioned the 
research paper fully expecting that it won't be included, but I hope people 
read it and accept that traffic analysis is a real risk that needs to be 
described in the Security Considerations section.

Scott

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

[dns-privacy] Security Considerations: Traffic Analysis

[Hollenbeck, Scott]

The iterative nature of recursive resolution gives an on-path monitor multiple 
opportunities to observe query traffic between a recursive resolver and an 
authoritative name server. Even with encryption, the name server IP addresses 
can be used to draw accurate conclusions about qnames by matching IP addresses 
to name servers identified in publicly available zones. This is something that 
needs to be addressed in the Security Considerations section of any draft that 
describes a recursive-to-authoritative encryption solution.

draft-ietf-dprive-dnsoquic addresses traffic analysis, but 
draft-ietf-dprive-unauth-to-authoritative does not. 
draft-rescorla-dprive-adox-latest addresses it somewhat. I'd like to suggest 
that text like this (or something similar) be added to 
draft-ietf-dprive-unauth-to-authoritative and draft-rescorla-dprive-adox-latest:


BEGIN
Encryption is one of several controls that can reduce the risk of disclosure of 
sensitive information. Resolver-to-authoritative DNS encryption will protect 
the DNS traffic exchanged between the resolver and the authoritative name 
server from being directly observed and/or modified by an adversary. However, 
as in other systems where encryption is deployed, implementers should also 
consider other ways in which the same or related information may also be 
exposed, and how to mitigate those risks. For example, encryption provides 
confidentiality protection for DNS query and response payloads between 
recursive resolvers and authoritative name servers, but iterative resolution 
makes it possible to perform traffic analysis using other, non-encrypted 
information that can be observed in subsequent iteration steps. The names and 
IP addresses of the name servers for most DNS zones are publicly available, so 
an attacker that can monitor traffic exchanged between a resolver and an 
authoritative n
 ame server will often be able to identify the zone of interest based on the IP 
address of the authoritative name server. Iterative resolution using 
destination IP addresses that were encrypted in a previous query makes it 
possible to identify the set of domains that might be associated with a query 
by observing the destination IP address and comparing that to the addresses and 
names found in publicly-available zone files. This risk can be reduced by 
limiting the number of queries sent to authoritative name servers using 
techniques such as hyperlocal root processing [RFC7706], NXDOMAIN cut 
processing [RFC8020], and aggressive DNSSEC caching [RFC8198].

The size of encrypted query and response packets can also be used to detect 
query patterns. The set of name servers and IP addresses returned in a response 
to a query changes infrequently, so the size of the DNS response for a specific 
set of name servers tends to stay the same during a given time period. The size 
of responses can be monitored to observe patterns associated with responses 
from specific name servers, and this information can be used to identify 
queries for specific domain names. This risk can be reduced by padding the 
record payload of TLS-protected responses to eliminate response size 
variability.

Additional traffic analysis considerations are described in a paper titled 
"Encrypted DNS =⇒ Privacy? A Traffic Analysis Perspective" [1].

[1] https://www.ndss-symposium.org/wp-content/uploads/2020/02/24301-paper.pdf
END

Scott

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

Re: [dns-privacy] [Ext] WG strategy on opportunistic vs authenticated moving forward

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Hoffman 
> Sent: Tuesday, July 13, 2021 12:18 PM
> To: Hollenbeck, Scott 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WG strategy on opportunistic vs
> authenticated moving forward
> 
> On Jul 13, 2021, at 8:56 AM, Hollenbeck, Scott
>  wrote:
> > If a solution can be developed that works for all levels of the DNS 
> > hierarchy,
> fine
> 
> Are you saying that the current WG draft, draft-ietf-dprive-unauth-to-
> authoritative-03, doesn't work at all levels of the DNS hierarchy? If so, the
> specifics of that would be important for the WG to work on.

No, I'm responding to Tim's request for input: "We feel like the WG will not be 
able to make additional progress on any of the proposed solutions until we can 
reach consensus on whether the solution should be homogeneous from the root 
down or that the real focus is on SLDs and down."

SLD isn't quite right given that there are second-level domains that act like 
top-level domains, so I tried to be more precise by using "delegation-centric" 
instead. The service discovery part of any draft that requires publication of 
records in the parent could be an issue (as Tim noted), but beyond that I'm not 
specifically commenting on either of the proposed solution drafts.

Scott

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

Re: [dns-privacy] [Ext] WG strategy on opportunistic vs authenticated moving forward

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Tuesday, July 13, 2021 11:34 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WG strategy on opportunistic vs
> authenticated moving forward
> 
> On Jul 13, 2021, at 8:08 AM, Hollenbeck, Scott
>  wrote:
> > . . .my preference would be for the WG to focus on solutions for
> authoritative name servers serving zones that aren’t delegation-centric.
> 
> This has come up before, and I'm trying to figure out why. If this WG comes
> up with a protocol that any zone operator can choose to implement, why
> differentiate between delegation-centric and anything else? It feels short-
> sighted to look at current zone contents and try to optimize a solution for
> them, instead of just making all DNS extensions optional.

Delegation-centric zones return name server IP addresses that are exposed in 
subsequent recursive queries. The value proposition of encrypting those 
addresses in a DNS response has to be weighed against the server resource 
overhead of adding support for encryption, especially when there are data 
minimization techniques available that can reduce the amount of information 
disclosed without putting an operational burden on the authoritative name 
server. If a solution can be developed that works for all levels of the DNS 
hierarchy, fine, but I believe there's more value in a solution (or solutions) 
where the data can't be protected using minimization techniques and there's a 
greater likelihood of near-term experimentation.

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

Re: [dns-privacy] WG strategy on opportunistic vs authenticated moving forward

[Hollenbeck, Scott]

From: dns-privacy  On Behalf Of Tim Wicinski
Sent: Monday, July 12, 2021 1:12 PM
To: DNS Privacy Working Group 
Cc: dprive-cha...@ietf.org
Subject: [EXTERNAL] [dns-privacy] WG strategy on opportunistic vs authenticated 
moving forward



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,



The chairs have been watching the working group while we prepare for the 
upcoming meeting, and working through the proposals and arguments that keep 
coming up. We feel there is strong consensus to work on opportunistic 
encryption and that it may be beneficial to discuss possible experimental 
deployments with a version of the currently documented approach 
(draft-ietf-dprive-unauth-to-authoritative).



The concern with lumping the root, TLDs, and SLDs into one solution is that 
there are contractual issues with what can be in a zone above an SLD. These 
limitations are potentially an issue with some solutions that need/want new 
records in the parent’s zone. We feel like the WG will not be able to make 
additional progress on any of the proposed solutions until we can reach 
consensus on whether the solution should be homogeneous from the root down or 
that the real focus is on SLDs and down.



We've asked Paul and Petr to not focus on the common-features document and move 
that content  back into their draft.  The authors of 
draft-rescorla-dprive-adox-latest will be incorporating concepts from 
draft-schwartz-dprive-name-signal as a next step for the authenticated 
encryption proposal. This should provide a more concrete proposal that can be 
considered for WG adoption.



The chairs would like to solicit any input/feedback on the above as we prepare 
for our session during IETF 111.



[SAH] Knowing that there are concerns from the root server operators and 
operators of some top-level domains about both the server resource overhead of 
adding support for encryption and the value proposition in doing so, my 
preference would be for the WG to focus on solutions for authoritative name 
servers serving zones that aren’t delegation-centric. The 
recursive-to-authoritative resolution environment is already heterogeneous, and 
data minimization techniques (such as QNAME minimization) are available to 
reduce information disclosure during exchanges at the delegation-centric 
levels. There may be more interest in experimentation using 
non-delegation-centric zones and name servers where the data minimization 
techniques aren’t available, and those experiments can help guide the 
“increased deployment in other parts of the DNS hierarchy” mentioned in the 
statement from the root server operators [1].



[1] https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf



Scott

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

Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Alexander
> Mayrhofer
> Sent: Wednesday, July 7, 2021 8:36 AM
> To: Andrew Campling 
> Cc: Brian Haberman ; dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] How do we want to use draft-ietf-
> dprive-phase2-requirements?
> 
> 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.
> 
> Picking up on this (speaking as an editor of the draft). I don't have any 
> issues
> with option #4 (dropping the draft), and it has expired some time ago
> anyways. However, if we need a space to document operational concerns
> around any specific solution (for example, to avoid repeating the same
> concerns for each new solution space document), then i think the document
> could provide a useful contribution to the WG. Also, i do remember that we
> initially mulled never progressing the draft to an RFC anyways, so it seems 
> its
> current fate pretty much fits that original intent.
> 
> If we do want a space to collect "concerns", a document with "requirements"
> in its name would be slightly misleading, though - "design considerations" or
> similar would probably fit that purpose much better. We could also use a wiki
> page somewhere for that, but i think even an expired draft is a more stable
> resource, compared to a WG wiki page.
> 
> Some of these "design considerations" i've heard / can think of over the last
> years would be:
> 
> - Protocol should not require any probing by recursive servers
> - Protocol should require as little state as possible
> - Recursives would have a much larger set of open "upstream"
> connections than a stub resolver (obviously), so footprint of these sessions 
> is
> critical
> - Auth servers would see a similar amount of open "downstream"
> connections, though that end is probably similar to what recursives see
> downstream - are there differences?
> - Quality / Level of authentication ("better than nothing" principle?)
> 
> So, if we go for option #4, would it make sense to collect those (and
> similar) considerations somewhere?

[SAH] I'd certainly like to see both design _and operational_ considerations 
captured somewhere, and it makes sense to do it in one place.

There's another expired draft that attempted to capture operational 
considerations:

https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/

It would be worth exploring it, too, if we see value in capturing this 
information.

Scott

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

Re: [dns-privacy] [Ext] Common Features for Encrypted Recursive to Authoritative DNS

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Thursday, May 6, 2021 11:21 PM
> To: Ben Schwartz 
> Cc: DNS Privacy Working Group 
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted
> Recursive to Authoritative DNS
> 
> On May 3, 2021, at 2:06 PM, Ben Schwartz
>  wrote:
> > Thanks for this draft; I think it's clear and could be a helpful 
> > introduction.
> >
> > >If the cache has no positive or negative answers for any DNS SVCB
> >record for any of a zone's authoritative servers, the resolver needs
> >to send queries for the DNS SVCB records for some or all of the
> >zone's authoritative servers.
> >
> > I think it would be worth rephrasing the words "needs to" here.  To me,
> this sounds like a normative requirement to perform these queries, but I
> suspect that's not what you mean.
> 
> Good catch. In retrospect, this topic is actually not common between the two
> use cases, so we'll take it out of the "common" document and expect each
> protocol document to deal with what to do if the cache has no positive or
> negative answers for any DNS SVCB record for any of a zone's authoritative
> servers.
> 
> > >Because some authoritative servers or middleboxes are misconfigured,
> >requests for unknown RRtypes might be ignored by them.  Resolvers
> >should be ready to deal with timeouts or other bad responses to their
> >SVCB queries.
> >
> > This sounds a bit pessimistic.  Ralf Weber recently published some figures
> showing a ~0.03% failure rate.  For security (in the authenticated case), any
> mitigations here are very delicate, and I'm a bit concerned about the brief
> treatment here.  (The SVCB draft has an extensive discussion:
> https://secure-web.cisco.com/15G9BV5N6Ayfy89k3tshwvv0Hj-
> zjPlc6kJw1CJqi6AgP3dFYb3rxKKH8mi4aa9YeME86836s0ekEY1nApKWIFnccrAv
> IZEd6FCFj83J5RDOpPrUmu05qr8Q9AdovzfGTj7OCaECH7_kA7XdSfC_LW1Ldh
> T68yxlKSrCBbonEKberR2w0XZ3FpPvQCuROK63spcmNV-
> n3kzVu8JE663OkGbqoSrNiKazCnaj6b6to34xrxtNvrtC5Gk2vycrcfE4S-
> IKD5bXC2IYoYt563cbwaibm-
> zEtpU_H5WIMSebB9l0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtm
> l%2Fdraft-ietf-dnsop-svcb-https%23section-3.1.)
> 
> This was a leftover from earlier drafts, and you are right that this is
> adequately covered in the SVCB draft itself. We'll remove it.
> 
> > >DNS SVCB records act as advisory information for resolvers about the
> >encrypted protocols that are supported.  They can be thought of as
> >similar to NS records on the parent side of a zone cut: advisory
> >enough to act on, but not authoritative.  Given this, authoritative
> >servers that know the DNS SCVB records associated with NS records for
> >any child zones MAY include those DNS SCVB records in the Additional
> >section of responses to queries to a parent authoritative server.
> >
> > This sounds like a restatement of the definition of "glue".  Can we simply
> declare that these records are "glue"?
> 
> We do not get to redefine a 30-year-old concept just because we have a new
> shiny thang. We tried to say "treat similar to glue", and that wording could
> maybe be improved.
> 
> On May 4, 2021, at 5:28 AM, Hollenbeck, Scott
>  wrote:
> >
> > [SAH] …and does this imply that we need to extend EPP to populate these
> records?
> 
> Wrong working group, Scott. :-) My personal opinion is that there are
> mechanisms defined by DNSOP for child-to-parent communication that
> would probably work much better than yet another REGEXT WG document.

[SAH] Asking the question here doesn't make this the wrong venue. If these 
records need to be treated like glue records, publication needs to be addressed 
_somewhere_. Once a preference is established, the specification work can be 
handed off to the appropriate WG.

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

Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

[Hollenbeck, Scott]

From: dns-privacy  On Behalf Of Ben Schwartz
Sent: Monday, May 3, 2021 5:07 PM
To: Peter van Dijk 
Cc: DNS Privacy Working Group 
Subject: [EXTERNAL] Re: [dns-privacy] Common Features for Encrypted Recursive 
to Authoritative DNS



Thanks for this draft; I think it's clear and could be a helpful introduction.



>If the cache has no positive or negative answers for any DNS SVCB

   record for any of a zone's authoritative servers, the resolver needs
   to send queries for the DNS SVCB records for some or all of the
   zone's authoritative servers.



I think it would be worth rephrasing the words "needs to" here.  To me, this 
sounds like a normative requirement to perform these queries, but I suspect 
that's not what you mean.



>Because some authoritative servers or middleboxes are misconfigured,
   requests for unknown RRtypes might be ignored by them.  Resolvers
   should be ready to deal with timeouts or other bad responses to their
   SVCB queries.



This sounds a bit pessimistic.  Ralf Weber recently published some figures 
showing a ~0.03% failure rate.  For security (in the authenticated case), any 
mitigations here are very delicate, and I'm a bit concerned about the brief 
treatment here.  (The SVCB draft has an extensive discussion: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1.)



>DNS SVCB records act as advisory information for resolvers about the

   encrypted protocols that are supported.  They can be thought of as
   similar to NS records on the parent side of a zone cut: advisory
   enough to act on, but not authoritative.  Given this, authoritative
   servers that know the DNS SCVB records associated with NS records for
   any child zones MAY include those DNS SCVB records in the Additional
   section of responses to queries to a parent authoritative server.



This sounds like a restatement of the definition of "glue".  Can we simply 
declare that these records are "glue"?



[SAH] …and does this imply that we need to extend EPP to populate these records?



Scott

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

Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Monday, April 19, 2021 5:13 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] How do we want to use draft-ietf-dprive-
> phase2-requirements?
> 
> All,
>  As was raised on the thread discussing suggestions for the requirements
> draft, there is some question on how the WG wants to use draft-ietf-dprive-
> phase2-requirements in progressing our recursive-to-authoritative privacy
> work item. The draft currently has one sub-section that describes
> requirements (5.1) and another section that describes optional features
> (5.2), albeit with 2119 SHOULDs.
> 
>  My question to the WG is how do we want to use this draft? I see four
> possible approaches, but I am sure someone will point out others.
> 
> 1. Strictly requirements - these would be MUST-level functions that the WG
> determines have to be supported by any solutions draft.
> 
> 2. Strictly design considerations - these would be functional areas that the
> WG determines need to be considered, but not necessarily included, by any
> solutions draft.
> 
> 3. Requirements & design considerations - This is generally where the current
> draft sits IMO.
> 
> 4. Drop the draft and let the solutions flow.
> 
> Let's discuss the focus of the draft and then we can determine what updates
> are needed/necessary.

I prefer option #3, but with a change in order such that we describe design 
considerations first, followed by requirements that are derived from those 
considerations.

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

Re: [dns-privacy] [Ext] A Few More Suggestions for the Requirements Draft

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Monday, April 19, 2021 1:15 PM
> To: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] A Few More Suggestions for the
> Requirements Draft
>
> On Apr 19, 2021, at 8:08 AM, Hollenbeck, Scott
>  wrote:
> > I have a few more suggestions for draft-ietf-dprive-phase2-requirements.
>
> Before we start making point-level suggestions for the draft, it would be
> useful to know whether the draft is still being worked on, and what its
> expected status will be. The draft has not been updated in nearly six months,
> even though the authors said they would after the IETF meeting five months
> ago. My feeling from that is that the authors have lost interest, and maybe
> the WG has as well.
>
> The purpose of the draft has shifted significantly. The -02 draft changed from
> "requirements" to "requirements and considerations". The meat of the draft
> (Section 5) is no longer requirements, but "features"; however, there are 
> still
> MUST and SHOULDs among those features.
>
> If the WG continues to work on this document, it would be good to first say
> what it's new purpose is (such as requirements on solutions documents), and
> whether it should be expected to be published as an RFC or just kept as a
> checklist before the WG moves other documents forward.

That would be a good discussion to have. The WG charter currently says this:

"Develop requirements for adding confidentiality to DNS exchanges between 
recursive resolvers and authoritative servers (unpublished document)."

Does that need to change?

Scott

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

[dns-privacy] A Few More Suggestions for the Requirements Draft

[Hollenbeck, Scott]

I have a few more suggestions for draft-ietf-dprive-phase2-requirements. In 
Section 5.1:

After the current requirement #7, I'd like to suggest adding a requirement like 
this to make it clear that the authoritative name server determines if server 
authentication is required, or not:

"The authoritative domain owner or their administrator MUST have the option to 
specify whether server authentication is required for all secure connections to 
the server."

After the current requirement #9, I'd like to suggest a requirement like this 
to help make it clear that it's possible to the different name servers hosting 
a zone to have different secure connection requirements, and a recursor needs 
to be able to adapt appropriately:

The recursor MUST have the option to vary its connection behavior on an 
authoritative name server to name server basis. This SHALL include whether a 
secure transport protocol MUST always be used (non-downgradable) or whether a 
secure transport protocol MAY be used on an opportunistic (not strict) basis in 
recognition that some servers for a domain might use a secure transport 
protocol and others might not.

I'd like to propose a slight modification to number 10. An implementation may 
have an internal specification of preferences for its own purpose. For 
instance, a transport preferences cache. Access to that cache wouldn't require 
use of the DNS, so I think it makes sense to note that the requirement for DNS 
use is for access by others:

OLD
10. The specification of secure transport preferences MUST be performed using 
the DNS and MUST NOT depend on non-DNS protocols.

NEW:
10. The specification of secure transport preferences, when published for 
access by other parties, MUST be performed using the DNS and MUST NOT depend on 
non-DNS protocols.

I think we need to add a normative reference to RFC 8446 in the current #11:

OLD:
For secure transports using TLS, TLS 1.3 (or later versions) MUST be supported 
and downgrades from TLS 1.3 to prior versions MUST not occur.

NEW:
For secure transports using TLS, TLS 1.3 ([RFC8446] or later versions) MUST be 
supported and downgrades from TLS 1.3 to prior versions MUST not occur.

Do these seem reasonable? I'll close with a question: we've talked about server 
authentication, but not about client authentication. We should say something in 
the requirements draft about client authentication, but right now I'm not sure 
of what makes the most sense. OPTIONAL, REQUIRED, something else?

Scott

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Stephen
> Farrell
> Sent: Wednesday, March 31, 2021 8:58 AM
> To: Jim Reid ; Brian Haberman
> 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
> DNS Encryption
>
>
> Hiya,
>
> On 31/03/2021 13:52, Jim Reid wrote:
>
> > We all want better privacy of course. For some definition of privacy.
> > But what does that actually mean in the context of queries to
> > authoritative servers at the root or TLDs?
>
> Workable answers for the root and TLDs are likely very different, as the scale
> of risk is very different.
>
> I think it doesn't really help to try discuss both root servers and TLDs at 
> the
> same time.
>
> > And is TLS the*only*  game
> > in town?
> When encrypting DNS based on some standard protocol? It is, though of
> course you can have that DoT or DoH or DoQ or maybe even opaquely
> flavoured;-(

[SAH] Why assume that encryption is required to provide confidentiality?

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

[dns-privacy] Root Server Operators Statement on DNS Encryption

[Hollenbeck, Scott]

This is worth reading:

https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf

Scott

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

Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Stephen
> Farrell
> Sent: Friday, March 26, 2021 10:02 PM
> To: Eric Rescorla ; Jim Reid 
> Cc: DNS Privacy Working Group ; Bill Woodcock
> 
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] next steps for draft-
> opportunistic-adotq
>
>
> Hiya,
>
> Not asking anyone in particular but...
>
> On 27/03/2021 00:24, Eric Rescorla wrote:
> > WRT the operational risk (slide 3), it's likely true that it's
> > somewhat harder to run a DoX server than a Do53 server. However, given
> > that we have plenty of worked examples of TLS servers of comparable if
> > not greater scale being operated with high reliability (e.g., Google,
> > Fastly, Cloudflare, etc.), I think there's pretty strong evidence that
> > this is an operational issue that can be addressed.
>
> That's been said a number of times, and I think has a fairly clear ring of 
> truth
> to it, but yet it somehow doesn't seem to sway those who operate larger
> scale Do53 services today.
>
> Can anyone help me understand that?
>
> I could understand if the justifications were down to stability or cost, 
> either
> of which could be valid engineering reasons why someone might prefer the
> status-quo, but I don't think I've seen the argument made explicit in either 
> of
> those ways.
>
> I don't have first-hand knowledge of this, so it'd help me at least if it the
> reasons why DoH or DoT are hard for (especially the likes of .com/.net) could
> be further clarified.

[SAH] I'm working on a more detailed response, but in the meantime it might 
help to read this expired Internet-Draft:

https://www.ietf.org/archive/id/draft-hal-adot-operational-considerations-02.txt

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

Re: [dns-privacy] draft-ietf-dprive-phase2-requirements: The User Perspective and Use Cases

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Wednesday, March 24, 2021 7:20 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] draft-ietf-dprive-phase2-
> requirements: The User Perspective and Use Cases
>
> 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.
>
> Hi Scott,
>
> On 3/23/21 11:26 AM, Hollenbeck, Scott wrote:
>
> >> >From the pure user perspective, do they even know that their "DNS
> >> server" is an intermediary?
> >
> > [SAH] For most people, probably not.
> >
> >> What phase 2 requirement can be derived from the above?
> >
> > [SAH] There isn't one. This text appears in the Appendix, which (I believe)
> helps set the context for the requirements that appear in the sections that
> precede it without including additional requirements. If there's an intention
> to include requirements in Section 9, it might help to call it something other
> than "Appendix", to move it up higher in the document, and to think about
> where normative language is needed. My preference is to leave it where it
> is, use it to provide background information, and not include normative
> language.
>
> Sorry, I didn't word my question clearly enough. I agree that there shouldn't
> be requirements in the appendix. It does serve the purpose of providing
> context, but does not appear to have a direct link to any requirements that
> have been documented. So, my question is does this context lead to any
> specific requirement that should be captured in this document?

[SAH] I don't think it does, and that's just as important to recognize as the 
other perspectives that appear in the appendix that might lead to a specific 
requirement. Right now, the draft leaves the question about requirements 
derived from the user's perspective open. I'm suggesting that we modify that 
text and note that the user's perspective does not introduce requirements.

Scott

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

Re: [dns-privacy] draft-ietf-dprive-phase2-requirements: The User Perspective and Use Cases

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Tuesday, March 23, 2021 10:11 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] draft-ietf-dprive-phase2-
> requirements: The User Perspective and Use Cases
> 
> 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.
> 
> Hi Scott,
>  Thanks for kicking this discussion off. A question (or two) inline for 
> us to
> consider...
> 
> On 3/19/21 7:10 AM, Hollenbeck, Scott wrote:
> > Section 9.1 of draft-ietf-dprive-phase2-requirements currently contains
> this text:
> >
> > "As recursors typically forwards queries received from the user to
> authoritative servers.  This creates a transitive trust between the user and
> the recursor, as well as the authoritative server, since information created 
> by
> the user is exposed to the authoritative server.  However, the user never has
> a chance to identify what data was exposed to which authoritative party (via
> which path).
> >
> > Also, Users would want to be informed about the status of the
> > connections which were made on their behalf, which adds a fourth point
> >
> > Encryption/privacy status signaling
> >
> > *TODO*: Actual requirements - what do users "want"?  Start below:"
> >
> > I'm not sure there's much to be added here since users currently have no
> ability to pick and choose services that a recursive resolver negotiates with 
> an
> authoritative name server. The user can pick a recursive resolver based on
> the set of services it provides, and that's about it. I'd like to suggest 
> that we
> replace the above text with something like the following:
> >
> > "Recursive resolvers typically act as intermediaries.  They forward
> > queries received from users to authoritative servers without any
> configurable and/or measurable interaction between the user and the
> authoritative name servers. As when making requests through other
> intermediaries, users do not necessarily have the ability to identify
> information that is disclosed by the intermediary to other service provider,
> i.e., an authoritative server in this case. As such, users should simply 
> choose a
> recursor that provides a set of services that best meets the user's need for
> information protection, along with other considerations."
> >
> 
> >From the pure user perspective, do they even know that their "DNS
> server" is an intermediary?

[SAH] For most people, probably not.

> What phase 2 requirement can be derived from the above?

[SAH] There isn't one. This text appears in the Appendix, which (I believe) 
helps set the context for the requirements that appear in the sections that 
precede it without including additional requirements. If there's an intention 
to include requirements in Section 9, it might help to call it something other 
than "Appendix", to move it up higher in the document, and to think about where 
normative language is needed. My preference is to leave it where it is, use it 
to provide background information, and not include normative language.

Scott

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

[dns-privacy] draft-ietf-dprive-phase2-requirements: The User Perspective and Use Cases

[Hollenbeck, Scott]

Section 9.1 of draft-ietf-dprive-phase2-requirements currently contains this 
text:

"As recursors typically forwards queries received from the user to 
authoritative servers.  This creates a transitive trust between the user and 
the recursor, as well as the authoritative server, since information created by 
the user is exposed to the authoritative server.  However, the user never has a 
chance to identify what data was exposed to which authoritative party (via 
which path).

Also, Users would want to be informed about the status of the connections which 
were made on their behalf, which adds a fourth point

Encryption/privacy status signaling

*TODO*: Actual requirements - what do users "want"?  Start below:"

I'm not sure there's much to be added here since users currently have no 
ability to pick and choose services that a recursive resolver negotiates with 
an authoritative name server. The user can pick a recursive resolver based on 
the set of services it provides, and that's about it. I'd like to suggest that 
we replace the above text with something like the following:

"Recursive resolvers typically act as intermediaries.  They forward queries 
received from users to authoritative servers without any configurable and/or 
measurable interaction between the user and the authoritative name servers. As 
when making requests through other intermediaries, users do not necessarily 
have the ability to identify information that is disclosed by the intermediary 
to other service provider, i.e., an authoritative server in this case. As such,
users should simply choose a recursor that provides a set of services that best 
meets the user's need for information protection, along with other 
considerations."

Scott

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

Re: [dns-privacy] Complete changes to the (no longer just) opportunistic ADoT draft

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Monday, February 22, 2021 4:28 PM
> To: dpr...@ietf.org
> Subject: [EXTERNAL] [dns-privacy] Complete changes to the (no longer just)
> opportunistic ADoT draft
>
> Greetings again. You probably just saw the announcement of draft-ietf-
> dprive-opportunistic-adotq-01. After the discussion on the list about us
> having to make the opportunistic draft track the (unpublished) fully-
> authenticated draft, Peter and I decided it would be easier for the WG to
> keep both ideas in their heads by making a single draft that covers both
> opportunistic and fully-authenticated ADoT.

[SAH] Very basic first question: we do not yet have a finished requirements 
document for exchanges between recursive resolvers and authoritative servers. I 
understand the enthusiasm for an opportunistic ADoT draft, but how does the 
group intend to make sure that it remains in synch with the requirements draft?

Scott

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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Hollenbeck, Scott]

From: dns-privacy  On Behalf Of Ben Schwartz
Sent: Tuesday, February 16, 2021 12:01 PM
To: Paul Wouters 
Cc: Paul Hoffman ; dpr...@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Authentication in 
draft-ietf-dprive-opportunistic-adotq







   [SAH] [snip]



   I think the scary part is that an authenticated TLS failure (due to 
misconfiguration, bug, overload, or rollback) results in an outage.  
draft-ietf-dprive-opportunistic-adotq never results in an outage; you just fall 
back to cleartext and pay a small latency penalty.



   [SAH] It’s more than that. TLS adds complexity, complexity adds fragility, 
and fragility leads to outages or compromises. NIST‘s National Vulnerability 
Database (https://nvd.nist.gov/) lists 950 TLS vulnerabilities since 1999, and 
347 in the past three years. Authoritative name servers that don’t implement 
TLS don’t have to worry about any of them. Add TLS, and now we do. I do agree 
with what you said above about just falling back to cleartext in case TLS 
doesn’t “work” for some reason. A TLS failure MUST NOT have an impact on 
availability.



   Scott

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

Re: [dns-privacy] how can we ADoT?

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Tony Finch
> Sent: Wednesday, November 11, 2020 2:07 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] how can we ADoT?
>
> 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.
>
> I haven't seen anything written down that explains why it is difficult to do
> DoT to authoritative servers. There was a good discussion earlier this year
> about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some of the
> issues. I have done a braindump that attempts to cover all the angles
> reasonably systematically. I expect I haven't quite reached that goal 
> though,
> so I hope this will provoke some informative comments :-) Since draft
> submission is closed, I'll paste it here for your delectation.
>
>
> ## Explicit encryption support signal
>
> How can a resolver know an authoritative server supports encryption?
> There are three basic alternatives:
>
>  1. No explicit signal: the resolver tries to make an encrypted
> connection, and falls back to cleartext if it gets an ICMP
> unreachable error or connection timeout.
>
> This is problematic because connection timeouts can be very slow,
> especially if the resolver tries multiple encrypted transports.
> This is also is vulnerable to downgrade attacks.
>
> The working group consensus is that an explicit signal is
> required.
>
>  2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
> resolver starts by connecting in the clear, and upgrades to an
> encrypted connection if the authoritative server supports it.
>
> This is vulnerable to downgrade attacks. The initial cleartext
> connection adds latency, and would need to be specified carefully
> to avoid privacy leaks.
>
>  3. Signal in DNS records: the resolver makes extra queries during
> iterative resolution to find out whether an authoritative server
> supports encryption, before the resolver connects to it.
>
> The extra queries add latency, though that can be mitigated by
> querying concurrently, and by placing the new records on the
> existing resolution path.
>
> DNSSEC can provide authentication and downgrade protection.
>
> This specification takes the last option, since it is best for security and 
> not too
> bad for performance.
>
>
> ## Where can nameserver encryption records go?
>
> Where can we put the new DNS records to signal that a nameserver supports
> encryption? There are a number of issues to consider:
>
>   1. Performance: we don't want the extra queries to slow down
>  resolution too much;
>
>   2. Scalability: is encryption configured per nameserver? per zone?
>
>   3. Authentication: DNSSEC does not protect delegation NS records or
>  glue address records;
>
>   4. DNS data model: we ought to re-use existing RRtypes according to
>  their intended purpose;
>
>   5. DNS extensibility: make use of well-oiled upgrade points and
>  avoid changes that have a track record of very slow deployment;
>
>   6. EPP compatibility: a zone's delegation is usually managed via the
>  Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731]
>  [@?RFC5732] so any changes need to work with EPP.
>
> The following subsections discuss the possible locations, and explain why
> most of them have been rejected.
>
>
> ## In the reverse DNS?
>
> Given a nameserver's IP address, a resolver might make a query like
>
> _853._tcp.1.2.0.192.in-addr.arpa.TLSA?
>
> This possibility is rejected because:
>
>   * It would be very slow: after receiving a referral, a resolver
> would have to iterate down the reverse DNS, instead of immediately
> following the referral.
>
>   * At the moment the reverse DNS refers to the forward DNS for NS
> records; this would also make the forward DNS refer to the reverse
> DNS for TLSA records. Dependency loops are best avoided.
>
>   * It's often difficult to put arbitrary records in the reverse DNS.
>
>   * Encryption would apply to the server as a whole, whereas the
> working group consensus is that it should be possible for
> different zones on the same server to use encrypted and
> unencrypted transports.
>
>
> ## A new kind of delegation?
>
> In theory, DNSSEC provides a way to update the DNS data model, along the
> lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea is to
> introduce new DNSSEC algorithm types which indicate that a zone can include
> new types of records that need special validation logic.
> Existing validators will be able to resolve names in the zone, but will 
> treat it as
> insecure.
>
> We might use this upgrade strategy to introduce new delegation records that
> indicate support for transport encryption. However, it would require a very
> long deployment timeline. It would also require a corresponding upgrade 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Friday, October 30, 2020 4:46 PM
> To: Eric Rescorla 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Revised opportunistic encryption
> draft
>
> On Oct 30, 2020, at 12:32 PM, Eric Rescorla  wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman 
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
> >> > I still believe the cost of authenticating a DNS(SEC) server is so
> >> > low these days (with ACME available at no cost and with full
> >> > automation) that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost that is
> being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to authentication
> mistakes made by the authoritative servers (not renewing certificates, errors
> in TLSA records, upstream validation problems that cause TLSA records not to
> validate, ...) or resolvers (dropping trust anchors that are in use, bad
> validation logic for TLSA, ...).
> >>
> > How is this different from the transition of the Web to HTTPS?
>
> The DNS data is already authenticated if they are using DNSSEC. Also,
> because the DNS is hierarchical, even a short-lived authentication failure at 
> a
> particular server will take out the ability to get data for all zones beneath 
> that
> one; this is not an issue in the web.
>
> > Sure, there can be misconfigurations of various kinds, but good operational
> practices can minimize these, and in return you get strong security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the
> DNS.

This is an important point. Privacy can't increase the risk of a loss of 
availability, especially as we move closer to the DNS root.

Scott

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

Re: [dns-privacy] Logistics for IETF 109

[Hollenbeck, Scott]

> -Original Message-
> From: Benno Overeinder 
> Sent: Monday, October 26, 2020 6:30 PM
> To: Hollenbeck, Scott ; dns-privacy@ietf.org
> Cc: br...@innovationslab.net
> Subject: [EXTERNAL] Re: [dns-privacy] Logistics for IETF 109
>
> Hi Scott,
>
> > On 26 Oct 2020, at 14:26, Hollenbeck, Scott
>  wrote:
> >
> > Can we expect an update of ietf-dprive-phase2-requirements prior to the
> meeting? I submitted a pull request on 1 September that hasn't been acted
> on. It would be nice to know if that request is acceptable and will be 
> included
> in the document prior to the discussion, or if I should be prepared to talk to
> the request during the meeting.
> >
>
> Thanks again for the pull request, your input is very valuable.  The 
> co-authors
> of ietf-dprive-phase2-requirements have synced via email and the inclusion
> of your feedback is on my calendar for this week.
>
> We are looking forward to discuss the document with you and the DPRIVE
> WG in the next weeks up to the IETF 109 meeting.

Thanks, Benno. I'll be ready to discuss any of the suggestions during the 
meeting.

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

Re: [dns-privacy] Logistics for IETF 109

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Monday, October 26, 2020 7:56 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] Logistics for IETF 109
>
> Hi all,
>  As you may have seen, we have a 2-hour session allocated to us for IETF
> 109. The chairs are going to split the session into two primary pieces. The 
> first
> part (30-40 minutes) will be dedicated to updates on DPRIVE drafts. We are
> working with the authors of the DoQ and xfr-over-tls drafts for this part. The
> second part (75+ minutes) will be a working session for the phase 2
> requirements draft. The goal will be to identify and discuss edits to the 
> draft
> in order to make it representative of the requirements for encrypting
> exchanges between recursive resolvers and authoritative servers.

Can we expect an update of ietf-dprive-phase2-requirements prior to the 
meeting? I submitted a pull request on 1 September that hasn't been acted on. 
It would be nice to know if that request is acceptable and will be included in 
the document prior to the discussion, or if I should be prepared to talk to the 
request during the meeting.

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

Re: [dns-privacy] [Ext] Re: ADoT requirements for signalling?

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of John Levine
> Sent: Thursday, October 31, 2019 3:39 PM
> To: dns-privacy@ietf.org
> Cc: brian.peter.dick...@gmail.com
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Re: ADoT requirements for
> signalling?
>
> In article
>  ail.com> you write:
> >I think there will be both interest and deployment, sufficient to
> >justify the effort.
>
> I hope so, but some actual comments from large DNS operators would be
> welcome.

It might be worth looking at this draft for one operator's perspective:

https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/

Scott

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

Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

[Hollenbeck, Scott]

From: Sara Dickinson 
Sent: Friday, August 23, 2019 12:57 PM
To: Hollenbeck, Scott 
Cc: vladimir.cunat+i...@nic.cz; dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for 
draft-ietf-dprive-rfc7626-bis









   On 21 Aug 2019, at 19:21, Hollenbeck, Scott 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 wrote:



  -Original Message-
  From: dns-privacy 
mailto:dns-privacy-boun...@ietf.org>> On Behalf 
Of Vladimír
  Cunát
  Sent: Monday, August 19, 2019 8:58 AM
  To: dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
  Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for 
draft-ietf-
  dprive-rfc7626-bis

  Hello,

  I now read through the whole document, and I see one thing that might be a
  little bit confusing - the beginning of page three reads like QNAME
  minimization is not possible or at least never done, and contrary to
  rfc7626 itself it isn't even mentioned in the whole document.  I would
  suggest to at least reduce the strength of the wording ("always"), and/or
  mention rfc7816.  I don't have much data at hand, but I believe that some
  reduction of QNAMEs isn't as exotic as it used to be.


   Agreed, and I'll suggest a sentence (enclosed by **) for the end of the 
third paragraph of the Introduction:

   "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<http://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 RFC 7816 [RFC7816], which will only send the relevant part of the 
question to the upstream name server.**”



   Thanks very much for this text. I’m wondering about also referencing this 
study:

   
https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation

   which attempts to asses the deployment of QNAME minimisation to show it is 
actually being deployed in the wild?


   [SAH] That seems reasonable.


   It may be more desirable to reference 7816bis, but that would add an 
Internet-Draft reference dependency that folks might not want to add.



   Good point. I’d prefer to just reference RFC7816 unless anyone objects…



   [SAH] A reference to 7816 is reasonable assuming that there’s little risk of 
significant specification deviation between it and 7816bis. That’s probably a 
reasonable assumption.



   Scott

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

Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Vladimír
> Cunát
> Sent: Monday, August 19, 2019 8:58 AM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-
> dprive-rfc7626-bis
>
> Hello,
>
> I now read through the whole document, and I see one thing that might be a
> little bit confusing - the beginning of page three reads like QNAME
> minimization is not possible or at least never done, and contrary to
> rfc7626 itself it isn't even mentioned in the whole document.  I would
> suggest to at least reduce the strength of the wording ("always"), and/or
> mention rfc7816.  I don't have much data at hand, but I believe that some
> reduction of QNAMEs isn't as exotic as it used to be.

Agreed, and I'll suggest a sentence (enclosed by **) for the end of the third 
paragraph of the Introduction:

"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 RFC 7816 [RFC7816], which will 
only send the relevant part of the question to the upstream name server.**"

It may be more desirable to reference 7816bis, but that would add an 
Internet-Draft reference dependency that folks might not want to add.

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

Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Brian
> Haberman
> Sent: Wednesday, August 14, 2019 4:40 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] Call for Adoption: draft-hal-adot-
> operational-considerations
>
> This starts a Call for Adoption for
> draft-hal-adot-operational-considerations
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/
>
> Please review this draft to see if you think it is suitable for adoption by
> DPRIVE, and comment to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.

I support adoption of this document, have been helping with reviews, and will 
continue to do so.

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

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Hollenbeck, Scott]

> -Original Message-
> From: Paul Wouters 
> Sent: Friday, November 30, 2018 11:15 AM
> To: Hollenbeck, Scott 
> Cc: 'wo...@pch.net' ; 'dns-privacy@ietf.org'  priv...@ietf.org>; 'KHenderson=40verisign@dmarc.ietf.org'
> 
> Subject: [EXTERNAL] RE: [dns-privacy] DNS PRIVate Exchange (dprive) WG
> Virtual Meeting: 2018-12-10
>
> On Fri, 30 Nov 2018, Hollenbeck, Scott wrote:
>
> >> Why wait ? Let's hear what he has to say on the list beforehand, so
> >> we can discuss on the list and if needed during the interim. It would
> >> be a better use of our voice-to-voice time.
> >
> > Here's what's been shared with the list already:
> >
> > https://mailarchive.ietf.org/arch/msg/dns-privacy/YHAa2kLGcKHMPEjkJQpQ
> > J_Amfeo
> >
> > There haven't been any replies.
>
> I see a number of replies listed on the page you cite above? :)

Replies with the same subject, yes, but there's been no discussion of the 
content of Karl's note. Anyway...

> Doing encryption on an authoritative server is tricky. It was one of the
> arguments against encrypting DNS with DNSSEC, and against dnscurve.
>
> times have changed, and it deserves another look, but some note that says
> "If running out of resources, drop the encryption and serve DNS data in
> the clear might be needed". Ideally in a way that querying clients that
> want to insist on privacy can bail out instead of receiving cleartext.

Possibly, but it may also be worth discussing how to avoid getting into 
resource exhaustion situations in the first place. Do you have any thoughts on 
Karl's "need for a profile of encryption standards" comment?

Scott

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

Re: [dns-privacy] Resolver to authoritative discussion guidance

[Hollenbeck, Scott]

From: Tim Wicinski 
Sent: Thursday, July 19, 2018 4:47 PM
To: Jim Reid 
Cc: Hollenbeck, Scott ; br...@innovationslab.net; 
dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Resolver to authoritative discussion 
guidance



OK,  I'll chat with Brian since he's in charge of sending those emails for now, 
and go there.



Thank you!



Scott

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

Re: [dns-privacy] Resolver to authoritative discussion guidance

[Hollenbeck, Scott]

From: dns-privacy  On Behalf Of Tim Wicinski
Sent: Thursday, July 19, 2018 3:01 PM
To: Jim Reid 
Cc: Brian Haberman ; dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Resolver to authoritative discussion 
guidance



Jim



We're not ignoring TLD operators. But the TLD operator space is not 100% 
technical, and we feel that the work done with the SLD space will be applicable 
to the TLD space.

We also feel that working on the TLD resolver issue will rathole thinking into 
non-technical issues.



If you think this is incorrect, we'd like to hear that.



[SAH] Perhaps a little “stick to the technical issues” guidance would be 
sufficient to allow discussion of all authoritative server operational use 
cases.



Scott

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