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

[Tim Wicinski]

Scott

On Fri, Jun 9, 2023 at 1:42 PM Hollenbeck, Scott  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/
>
> WRT observations, we do have a WG wiki we could use:
>
> https://wiki.ietf.org/group/dprive


Would you be able to produce some of these measurements based on
experiments you run?
That would be super useful.

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

[Rob Sayre]

On Fri, Jun 9, 2023 at 3:44 PM Hollenbeck, Scott 
wrote:

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

Hi,

I agree that a recharter would be required. However, what you're asking for
here exceeds the requirements of a Proposed Standard, so that does seem a
bit ad-hoc to me.

https://www.rfc-editor.org/rfc/rfc7127.html#section-3.1

In particular this paragraph applies:
"The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet."


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

So, your employer has contractual obligations to implement some
IETF-standards track documents. I'm still a little mystified, because I
don't think anyone would sign or write such an agreement for documents
not-yet-written. I figured the objection would be the typical
encryption-related ones (cost, observability, etc). The sort of thing we
saw with HTTP2 and DoT/DoH/DoQ.

But I also originally wrote that Experimental would work here, even if the
label is inaccurate.

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

Re: [dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07

[Salz, Rich]

He apologizes for his lack of Geography. (or he should)

My excuse: I am a typical American, ignorant of the rest of the world :)
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07

[Tim Wicinski]

I pointed out to Mr Salz that Alajuela is the location of the author in
question, not their employer.

He apologizes for his lack of Geography. (or he should)

tim


On Fri, Jun 9, 2023 at 4:20 PM Rich Salz via Datatracker 
wrote:

> Reviewer: Rich Salz
> Review result: Has Nits
>
> The term "unilateral" makes me do a double-take. That's probably on me,
> but I
> always think of it in a military context. So I am glad to see a short clear
> definition early in the document, in the terminology section.  All of the
> comments below are optional.
>
> I am curious why Joey's affiliation is in the author's area but not the
> title
> page.
>
> Sec 2.1  I think before this there should be an intro sentence, like "There
> were two main priorities for this work" or some such. Also the "--" should
> probably be a colon.
>
> Sec  2.2  Is the main point of the first paragraph to say that DoQ and DoT
> don't address this type of deployment but leave it open for future docs?
> If
> so, maybe that's worth stating directly.
>
> Sec 3 I think the ALPN the client "should" use (lowercase) is better than
> "may
> use"
>
> Sec 3.1 Merge first two paragraphs
>
> Sec 3,2 A server *could* use a classic TLS server cert, right? Worth
> mentioning? Worth proposing an eKU for DNS?
>
> Sec 4.1 Is this 'happy eyeballs'?  If so, worth mentioning I think.
>
> Sec 4.2, Merge the first two sentences: This document encourages the first
> strategy, to minimize timeouts or accidental delays and does not describe
> the
> other two." The remaining paragraphs contain some redundancy or otherwise
> could
> benefit from editing. For example, consider not saying anything about NS
> records.
>
> Sec 4.3, combine the two paragraphs that appear just after the table.
>
> Sec 4.4, combine first two paragraphs. Last paragraph seems out of place
> for
> this doc.
>
> Sec 4.5 In the table is "retain across reset" mean server restart? Are the
> last
> two paragraphs duplicate of 4.4? If not, I don't appreciate the difference;
> merge them into one.
>
> Sec 4.6, ah, happy eyeballs comparison.  Consider a forward pointer from
> 4.1
>
> Sec 4.6. Nice details.  Does this borrow from what SMTP opportunistic
> does? If
> so, might be worth mentioning.
>
> Sec 4.6.3.1 "store early data"  Is store the right word?  Send or stuff
> comes
> to mind.
>
> Sec 4.6.3.3  Do not send SNI.  Hmm.  Okay.  That's a big change from
> common web
> tls deployments.  Worth calling out?
>
> Sec 4.6.8.2, can you point to specific sections in the RFCs?  Okay if not.
>
> Sec 4.6.10, there's no title for the section referenced in 7858? :)
>
> Sec 5, "This document has no IANA considerations" is the boilerplate I've
> seen
> most often.
>
> Sec 6.2, A suggestion of what statistics to report would be useful. I also
> think the section title isn't great.
>
> Appendix A, is that to be removed when published?  Should A and B
> explicitly
> say they are not normative?
>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07

[Rich Salz via Datatracker]

Reviewer: Rich Salz
Review result: Has Nits

The term "unilateral" makes me do a double-take. That's probably on me, but I
always think of it in a military context. So I am glad to see a short clear
definition early in the document, in the terminology section.  All of the
comments below are optional.

I am curious why Joey's affiliation is in the author's area but not the title
page.

Sec 2.1  I think before this there should be an intro sentence, like "There
were two main priorities for this work" or some such. Also the "--" should
probably be a colon.

Sec  2.2  Is the main point of the first paragraph to say that DoQ and DoT
don't address this type of deployment but leave it open for future docs?  If
so, maybe that's worth stating directly.

Sec 3 I think the ALPN the client "should" use (lowercase) is better than "may
use"

Sec 3.1 Merge first two paragraphs

Sec 3,2 A server *could* use a classic TLS server cert, right? Worth
mentioning? Worth proposing an eKU for DNS?

Sec 4.1 Is this 'happy eyeballs'?  If so, worth mentioning I think.

Sec 4.2, Merge the first two sentences: This document encourages the first
strategy, to minimize timeouts or accidental delays and does not describe the
other two." The remaining paragraphs contain some redundancy or otherwise could
benefit from editing. For example, consider not saying anything about NS
records.

Sec 4.3, combine the two paragraphs that appear just after the table.

Sec 4.4, combine first two paragraphs. Last paragraph seems out of place for
this doc.

Sec 4.5 In the table is "retain across reset" mean server restart? Are the last
two paragraphs duplicate of 4.4? If not, I don't appreciate the difference;
merge them into one.

Sec 4.6, ah, happy eyeballs comparison.  Consider a forward pointer from 4.1

Sec 4.6. Nice details.  Does this borrow from what SMTP opportunistic does? If
so, might be worth mentioning.

Sec 4.6.3.1 "store early data"  Is store the right word?  Send or stuff comes
to mind.

Sec 4.6.3.3  Do not send SNI.  Hmm.  Okay.  That's a big change from common web
tls deployments.  Worth calling out?

Sec 4.6.8.2, can you point to specific sections in the RFCs?  Okay if not.

Sec 4.6.10, there's no title for the section referenced in 7858? :)

Sec 5, "This document has no IANA considerations" is the boilerplate I've seen
most often.

Sec 6.2, A suggestion of what statistics to report would be useful. I also
think the section title isn't great.

Appendix A, is that to be removed when published?  Should A and B explicitly
say they are not normative?



___
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

[Paul Hoffman]

Here is my first cut of wording for a new operational considerations section to 
deal with systems that are both recursive and authoritative on port 853. 
Comments are welcome.

As recursive resolvers implement this protocol, authoritative servers will see 
more probing on port 853 of IP addresses that are associated with NS records.
Such probing of an authoritative server should generally not cause any 
significant problems: if the authoritative server is not supporting this 
protocol, it will not respond on port 853, and if it is supporting this 
protocol, it will act accordingly.

However, a system that is a public resolver that supports DoT and/or DoQ may 
also have an IP address that is associated with NS records.
This could be accidental (such as a glue record with the wrong target address) 
or intentional.
In such a case, resolvers following this protocol will look for authoritative 
answers to ports 53 and 853 on that system, and the system would need to be 
able to differentiate queries for recursive answers from queries for 
authoritative answers.

___
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

[dns-privacy] OARC 41 - Call for Contribution -- deadline extension

[Manu Bretelle]

Deadline for OARC 41 abstract submission is extended to June 20th, 23:59
UTC.

Please note that, we are looking for contributions and remote participation
is actively supported

*

OARC 41 will be a two-day hybrid meeting and the dates are 6th and 7th
September to be co-located with ICANN DNS Symposium in Da Nang, Vietnam.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).


   - Deployment: DNS config management and release process.


   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.


   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency


   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either 10 or 20 minutes in length (plus 5 minutes
for Q). Proposals for in-person lightning presentations will be opened at
the Workshop.

Workshop Milestones:

2023-04-16 Submissions open via Indico
2023-06-20 Deadline for submission (23:59 UTC)
2023-06-27 Preliminary list of contributions published
2023-07-11  Full agenda published
2023-08-08 Deadline for slideset submission and Rehearsal
2023-09-06 OARC 41 Workshop - Day1
2023-09-07 OARC 41 Workshop - Day2

The Registration page and details for presentation submission are published
at:


To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Example guidelines
for presentation slides: https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 41

   - your talk will be broadcast live and recorded for future reference


   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting


   - Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. It
   would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
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

[Paul Hoffman]

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

I'll issue a new draft with the new status, and add text about recursive 
resolvers doing DoT and/or DoQ for stub resolvers, as well as being 
authoritative servers on the same address.

--Paul Hoffman

___
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