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] 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] Fwd: NomCom 2023 Call for Volunteers

[Tim Wicinski]

DNSOP/DPRIVE

Martin Thompson is chairing this year's version of the IETF Nominating
Committee. It's a good thing to volunteer, and I can speak strongly on the
fact that 10+ years of volunteering, and I have not been selected(*).

tim

(8) Now that I've said that

-- Forwarded message -
From: NomCom Chair 2023 
Date: Mon, Jun 5, 2023 at 7:50 PM
Subject: NomCom 2023 Call for Volunteers
To: IETF Announcement List 


The IETF Nominating Committee (NomCom) appoints people to fill the open
slots on the IETF LLC, IETF Trust, the IAB, and the IESG.  Ten voting
members for the NomCom are selected from a pool of volunteers.  A large
pool of volunteers helps make the process work better.

CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer

NomCom activity is expected to start in July and run through to November.
The goal is to do the bulk of the work at IETF 117 and 118, with
supplemental conference calls between those times.  Remote participation
will be supported.

The NomCom activities involve collecting requirements from the community,
reviewing candidate responses, reviewing feedback from community members
about candidates, interviewing candidates, and nominating a slate of
candidates.

RFC 8713 details the NomCom process.  With the recent publication of RFC
9389, this is the first year of new qualification criteria, after a few
years of trials.  People qualify for NomCom participation in one of three
ways: attendance at IETF meetings (online or virtual), service as a working
group chair or secretary, or publication of IETF RFCs.

https://datatracker.ietf.org/accounts/profile/ lists your eligibility, but
you can still volunteer even if that says "No".  You can also volunteer by
sending me an email.

Within the next week or two, I will add more details on the timeline and
the selection process.

Thank you!
Martin Thomson
nomcom-chair-2...@ietf.org

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
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

[Tim Wicinski]

Scott

On Mon, Jun 5, 2023 at 3:36 PM Hollenbeck, Scott 
wrote:

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

tim

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

[Tim Wicinski]

Thanks Paul ! We've been following the gitlab updates and do like the
updated version.

Brian, we should change the datatracker to say "Waiting for WG Chairs
go-ahead"
(me bossing Brian around)

tim


On Fri, May 26, 2023 at 2:01 PM Paul Hoffman  wrote:

> 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?
>
> > Thanks to everyone who has provided feedback to date!
>
> Indeed! The draft feels much tighter now.
>
> --Paul Hoffman (for Joey and dkg)
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

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.

thanks
tim



On Thu, Mar 2, 2023 at 3:17 PM Hollenbeck, Scott  wrote:

> > -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
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Meeting at IETF116

[Tim Wicinski]

All

The chairs have been discussing and we are currently planning on NOT having
a meeting at IETF116.

If anyone has issues with this please take this up with the chairs.

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

[dns-privacy] IETF NomCom: Selecting Leadership

[Tim Wicinski]

All



The NomCom is tasked with selecting the IETF leadership, like the IESG

and the IAB. For the NomCom to be able to make an informed decision, they
need feedback from the wider IETF community.


Please, allocate some time to provide feedback on people that you

interacted with the NomCom with their important task.


The deadline for this feedback is Nov 28.


https://datatracker.ietf.org/nomcom/2022/feedback/



Comments to the NomCom are confidential, but *not* anonymous. If this is a
concern, your chairs are here for you and more than happy to submit
feedback.


All types of feedback is welcome.



Thanks

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

[dns-privacy] Fwd: dprive - Cancelling a meeting request for IETF 115

[Tim Wicinski]

FYI

We are not cancelling, but are doing another combined meeting with ADD.

thanks
tim


-- Forwarded message -
From: IETF Meeting Session Request Tool 
Date: Fri, Oct 14, 2022 at 6:12 PM
Subject: dprive - Cancelling a meeting request for IETF 115
To: 
Cc: , , , <
lfl...@amsl.com>




A request to cancel a meeting session has just been submitted by Liz Flynn,
on behalf of the dprive working group.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

[Tim Wicinski]

DPRIVE is also a fine location.

Has anyone implemented DNS over DTLS for your use case?

tim

On Mon, Aug 15, 2022 at 6:04 AM Jaime Jiménez  wrote:

> CCing the right DNSOP mailing list now.
>
> On 15.8.2022 11.26, Jaime Jiménez wrote:
>
> Dear CoRE WG,
>
> We would like to start the call for adoption on draft-lenders-dns-over-coap.
> The draft defines a protocol for sending DNS messages over secure CoAP (DTLS 
> and/or OSCORE). The draft was discussed during IETF114 and on IETF113 and was 
> well-received by the group.
> https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/
>
> During the last IETF meeting there were no objections for adoption so we 
> confirm this now on the mailing list. Please let us know if you support 
> adopting this draft. As many people will still be on vacation, we the WGA 
> call will last a couple of weeks, ending the *1st of September*.
>
> Note that DNSOP and DPRIVE are in the loop as the draft is relevant for their 
> working groups too.
>
> BR,
>
> --
> Jaime Jiménez
>
>
> ___
> core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core
>
> --
> Jaime Jiménez
>
> ___
> 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] Minutes from IETF114

[Tim Wicinski]

All

Thanks for attending IETF114, whether in person or remote and for doing the
combined session with ADD again.  The minutes are attached to the end of
the ADD minutes here:
https://datatracker.ietf.org/meeting/114/materials/minutes-114-add-01

I will also include them as they are short.

One thing I'd like to say about the unilateral probing work is I'm happy to
see the authors working away on it, as well as others from the merge
requests waiting.  We do want to hear about Implementations (and I feel
track them).  Right now, I feel Peter is all alone with his implementation,
and that does not seem right.

Perhaps by the London IETF there could be some unilateral probing
experiments during the Hackathon.

thanks
tim

Minutes:
-

DPRIVE WG
2022-07-26
Chairs: Tim Wicinski and Brian Haberman
Notes here only cover comments at the mic, not from the slides

Admin stuff and WG update
Things are going along, but slow
Wants to see where things are going

draft-ietf-dprive-unilateral-probing: Daniel Kahn Gillmor
Tim: Would like to hear from other implementers
Benno Overeinder: Will speak offline about new work
Puneet Sood: Google Public DNS is doing at least parts of this
Viktor Dukhovni: Looking to speak with auth servers about tuning and so 
on
Paul Hoffman: This supposed to be harmless or minimal impact
Let us know if that's not right in the draft
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

FYI

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

tim


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

>
>
> A request to cancel a meeting session has just been submitted by Liz
> Flynn, on behalf of the dprive working group.
>
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE WG action items

[Tim Wicinski]

All

Thanks for the reviews from folks.   I just want to point out (and thank!)
Paul Hoffman for taking the review comments and putting them in the gitlab
issue tracker for the document
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues?sort=created_date=opened

The bigger discussions will always happen here, but this is highly useful

thanks again

tim




On Tue, Mar 29, 2022 at 7:57 AM Brian Haberman 
wrote:

> Hi all,
>   Tim and I wanted to followup on our session at IETF 113. The
> focus, as we see it, should be on two items:
>
> 1. Read
> https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/
> and provide feedback to the WG and authors
>
> 2. Provide feedback to the chairs on any efforts/plans related to
> implementations or deployments of DPRIVE standards
>
> We (the chairs) believe there is still a lot for us to learn and we want
> to make sure that we capture as much information as we can to ensure the
> WG is generating viable and constructive solutions.
>
> Regards,
> Brian
> ___
> 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] NOTE Updated date and time of DPRIVE session at IETF113

[Tim Wicinski]

All

Please note the new date and time for DPRIVE

* Date: Thursday 24 March 2022
* Time: 1430-1515 CEST (UTC+1)

In preparing for this meeting we realized we would not need a full two hour
session. In discussion with Eric our AD it was suggested we share the time
slot with the ADD WG *for time optimizations only*

Also note the
* MeetEcho:
https://meetings.conf.meetecho.com/ietf113/?group=add==1

* Minutes: https://notes.ietf.org/notes-ietf-113-add
* dpr...@jabber.ietf.org

I've the updated agenda

https://datatracker.ietf.org/meeting/113/materials/agenda-113-dprive-03.md

Thanks

tim/Brian

---

# DNS Privacy Exchange (DPRIVE) WG
### IETF 113

* Date: Thursday 24 March 2022
* Time: 1430-1515 CEST (UTC+1)
* MeetEcho:
https://meetings.conf.meetecho.com/ietf113/?group=add==1
* Minutes: https://notes.ietf.org/notes-ietf-113-add
* dpr...@jabber.ietf.org

* https://datatracker.ietf.org/meeting/113/session/dprive


### Current Working Group Business

*   draft-dkgjsal-dprive-unilateral-probing
-
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
- 15min

*   draft-ietf-dprive-unauth-to-authoritative
-
https://datatracker.ietf.org/doc/draft-ietf-dprive-unauth-to-authoritative/
-  15min

*   Future plans for dprive - is the WG completed all tasks?
- Chairs, 20min
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-dkgjsal-dprive-unilateral-probing

[Tim Wicinski]

All

The Call for Adoption has ended and we thank folks for their feedback.
We've adopted this work and will be part of the discussion at IETF113

tim

On Sun, Feb 13, 2022 at 8:47 PM Tim Wicinski  wrote:

>
>
> This starts a Call for Adoption for draft-dkgjsal-dprive-unilateral-probing
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
>
> Please review this draft to see if you think it is suitable for adoption
> by DPRIVE, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> We will count the postive comments already posted.
>
> This call for adoption ends:26 February 2022
>
> Thanks,
>
> tim
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Call for Agenda Items - IETF113

[Tim Wicinski]

All,

IETF 113 is coming up. The chairs have requested a 2-hour slot for
DPRIVE. Note that our meeting time is now Friday 25 March,
11:30-13:30 UTC.

Since we have two adopted drafts, we've placed both of them on
the agenda for discussion, along with an item to discuss where to take
the working group from here.

 Please let the chairs know of any other agenda topics you would like to
propose for this session.  As always, current WG items, topics raised on the
mailing list, then all other topics.

Neither of us will be in Vienna, but fear not! Benno Overeinder has
graciously offered to sit up front.


Regards,
Brian & Tim


# IETF113 Agenda

*   draft-dkgjsal-dprive-unilateral-probing
-
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
- 15min

*   draft-ietf-dprive-unauth-to-authoritative
-
https://datatracker.ietf.org/doc/draft-ietf-dprive-unauth-to-authoritative/
-  15min

*   Future plans for dprive - is the WG completed all tasks?
- Chairs, 20min
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Call for Adoption: draft-dkgjsal-dprive-unilateral-probing

[Tim Wicinski]

This starts a Call for Adoption for draft-dkgjsal-dprive-unilateral-probing

The draft is available here:
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We will count the postive comments already posted.

This call for adoption ends:26 February 2022

Thanks,

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

Re: [dns-privacy] DPRIVE Agenda for IETF 112

[Tim Wicinski]

All

Slight re-ordering of the agenda, swapping unilateral-probing and ds-glue
spots.

Also, I added a short chairs item about moving DNS-over-DTLS to historic

https://datatracker.ietf.org/meeting/112/materials/agenda-112-dprive-03

See you Thursday Noon UTC!

tim


On Fri, Oct 29, 2021 at 1:27 PM Brian Haberman 
wrote:

> All,
>   Here is the latest agenda for our session at IETF 112.
>
> https://datatracker.ietf.org/meeting/112/materials/agenda-112-dprive-01
>
> Regards,
> Brian & Tim
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

# DNS Privacy Exchange (DPRIVE) WG
### IETF 112, 

* Date: 11 November 2021
* Time: 1200-1400 UTC
* MeetEcho: [https://meetings.conf.meetecho.com/ietf112/?group=dprive==1](https://meetings.conf.meetecho.com/ietf112/?group=dprive==1)
* Minutes: [https://codimd.ietf.org/notes-ietf-112-dprive](https://codimd.ietf.org/notes-ietf-112-dprive)

* Jabber: [dpr...@jabber.ietf.org](dpr...@jabber.ietf.org)

* [Datatracker](https://datatracker.ietf.org/wg/dprive/documents/)

* [Upload Slides](https://datatracker.ietf.org/meeting/112/session/dprive)

### Chairs
* Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com)
* Brian Haberman [br...@innovationslab.net](br...@innovationslab.net)

### Very Responsible Area Director
* Eric Vyncke [evyn...@cisco.com](evyn...@cisco.com)

#
## Agenda

### Administrivia

* Agenda Updates, etc,  10 min
* NOTE WELL : https://www.ietf.org/about/note-well.html

*   Move DNS-over-DTLS to historic? 
- Re-Allocate port to QUIC (IESG)
- Chairs

### Current Working Group Business

*   draft-ietf-dprive-unauth-to-authoritative
- https://datatracker.ietf.org/doc/draft-ietf-dprive-unauth-to-authoritative/
- paul.hoff...@icann.org 30min
- Chairs Action:

### New Working Group Business

*   draft-dkgjsal-dprive-unilateral-probing
- https://gitlab.com/dkg/dprive-unilateral-probing/-/blob/main/unilateral-probing.md
- joeyg...@gmail.com 20min
- Chairs Action:

*   draft-schwartz-ds-glue
- https://datatracker.ietf.org/doc/draft-schwartz-ds-glue/
- bem...@google.com 20min
- Chairs Action:

*   draft-dickson-dnsop-ds-hack
- https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
- brian.peter.dick...@gmail.com 10min
- Chairs Action:

*   draft-dickson-dnsop-glueless
- https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
- brian.peter.dick...@gmail.com 10min
- Chairs Action:

*   draft-dickson-dprive-adot-auth
- https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
- brian.peter.dick...@gmail.com 5min
- Chairs Action:

*   draft-dickson-dprive-dnst
- https://datatracker.ietf.org/doc/draft-dickson-dprive-dnst/
- brian.peter.dick...@gmail.com 5min
- Chairs Action:
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DNS queries over CoAP draft at CoRE WG

[Tim Wicinski]

Jaime/Marco

Thanks for the heads up!  It looks like CoRE meets on Monday, and DNSOP
meets on Thursday.
So if you do get a request, please let us know and we'll mention it during
the Chairs Slides.

Also, I cc'ed the DPRIVE WG chairs (Brian Haberman, and some slacker named
Tim), because that was the WG
which was involved with the DNS-over-DTLS, and up until now, we have not
seen it ever implemented.

thanks
tim




On Tue, Oct 26, 2021 at 5:24 AM Jaime Jiménez  wrote:

> Dear DNSOP working group chairs,
>
> The CoRE WG has been working on the following document:
>
> https://datatracker.ietf.org/doc/html/draft-lenders-dns-over-coap-02
>
> As the abstract states: "This document defines a protocol for sending DNS
> messages over the Constrained Application Protocol (CoAP).  These CoAP
> messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for
> Constrained RESTful Environments (OSCORE) to provide encrypted DNS message
> exchange for constrained devices in the Internet of Things (IoT)."
>
> This is a heads up to let you know that the authors may request Working
> Group Adoption in CoRE during the coming IETF 112. It is also likely that
> during the progress of the document reviews from DNS experts will be
> requested.
>
> Best,
>
> Marco and Jaime, CoRE WG Chairs.
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE WGLC : https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

[Tim Wicinski]

This is a good point Ben. I'll catch up with Brian and discuss, but I'd
also like to hear from the working group and DNS-over-QUIC authors where
they feel this should live.

tim

On Fri, Oct 15, 2021 at 4:49 PM Ben Schwartz  wrote:

> On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema 
> wrote:
>
>> * Details on usage of 0-RTT with XFR QUERY, issue
>> https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The
>> current text is wrong, because 0-RTT resumption includes carry over of
>> the authentication negotiated in the previous connection. We may want to
>> not consider XFR Queries as replayable, and ask servers to wait until
>> the handshake is complete before processing them.
>>
>> * Details on the 0-RTT mitigation text, issue
>> https://github.com/huitema/dnsoquic/issues/102 by Martin Thomson. The
>> current text is based on the original analysis done by DKG years ago,
>> which pointed out the risks of replaying 0-RTT packets at attacker
>> chosen times. That attack is largely mitigated by the replay protection
>> in TLS 1.3, which is mandatory to implement. 0-RTT packets can only be
>> replayed within a narrow window, which is only wide enough to account
>> for variations in clock skew and network transmission.Need to update the
>> text and account for that.
>>
>
> This seems like another good reason to move the 0-RTT discussion into the
> 0-RTT draft.  I've opened a copy-and-paste PR here:
> https://github.com/ghedo/draft-ghedini-dprive-early-data/pull/4
>
> I would appreciate clearer guidance from the chairs on where the 0-RTT
> text should live.
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE WGLC : https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

[Tim Wicinski]

Christian

Thanks for bringing this up.  I make it a point to follow/receive updates
on all the repos of dprive documents, but I missed your repository.   The
chairs are advocates for using repositories like github for documents, as
we feel they have positive effects.

I believe the chairs have said this before, but it bears repeating: Please
feel free to use github for issue tracking,  especially those involving
editorial discussions.  But those issues raised which involve normative
changes to the document itself should be brought to the working group
mailing list for wider discussion and consensus.

I have not read all the issues Martin has raised, but those that look
substantial (such as 0-RTT) should be brought to the list. I suggest
starting separate email threads for each issue, to work through them
individually.

thanks
tim


On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema 
wrote:

> As Martin mentions, we had a number of issues opened recently in the
> GitHub repo managed by the authors
> (https://github.com/huitema/dnsoquic/). A lot of them have been opened
> after reviews by members of the QUIC working group. We have a bit of a
> culture clash here. The QUIC WG used GitHub intensely, but DPRIVE is
> usually more cautious, using it for coordination between the authors of
> the draft and possibly for straightforward editorial issues. here is a
> short list of the issues that are definitely not editorial:
>
> * Error code extensibility, and greasing of error codes. Several QUIC
> frames carry application defined error codes: reset stream, stop sending
> and close connection. The draft specifies a small set of error codes to
> use with these frames, and also specifies an extension mechanism to
> register more error codes. Issues
> https://github.com/huitema/dnsoquic/issues/80 and
> https://github.com/huitema/dnsoquic/issues/81, by Lucas Pardue, request
> to specify that receiving an "unknown" error code is not an error, and
> suggest that implementations can test the extensibility mechanism by
> sometimes sending different error codes, a.k.a., greasing. Proposed
> resolution in https://github.com/huitema/dnsoquic/pull/108.
>
> * Request to specify what happens if a node receives data in unexpected
> QUIC streams, issue https://github.com/huitema/dnsoquic/issues/82 by
> Lucas Pardue. DoQ only uses bidirectional QUIC streams opened by the
> client when sending a query, but QUIC permits other type of streams,
> such as unidirectional streams opened by the client or the server, or
> bidirectional streams open by the server. The spec did not specify how
> to handle data received in such streams. The proposed resolution is to
> treat that as a protocol error.
>
> * Getting rid of the text about not deliberately avoiding middle-boxes,
> issue https://github.com/huitema/dnsoquic/issues/90 by Martin Thomson.
> While the text is correct, it does not discuss potential usage of SNI
> encryption or Encrypted Client Hello (ECH), both of which can be used to
> "armor" a TLS based protocol and make it harder to block by
> middle-boxes. Adding a discussion of such mechanism is likely to be
> contentious. The discussion of middle-boxes in section 4.3. is not
> essential in the document, and the simplest solution is to just remove it.
>
> * Clarifying what happens if the client sends a query on a stream but
> fails to close the stream, issue
> https://github.com/huitema/dnsoquic/issues/93 by Martin Thomson. The
> draft specifies that adding a new query after the first one is an error,
> but is silent about failure to close the stream. Waiting for a proposed
> resolution.
>
> * Details on connection closure and client abandoning connections before
> the idle timeout elapses, issue
> https://github.com/huitema/dnsoquic/issues/98. Proposed resolution is
> that the client can always "walk away", and to only require explicitly
> clsoing the connection if transactions are pending.
>
> * Details on usage of 0-RTT with XFR QUERY, issue
> https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The
> current text is wrong, because 0-RTT resumption includes carry over of
> the authentication negotiated in the previous connection. We may want to
> not consider XFR Queries as replayable, and ask servers to wait until
> the handshake is complete before processing them.
>
> * Details on the 0-RTT mitigation text, issue
> https://github.com/huitema/dnsoquic/issues/102 by Martin Thomson. The
> current text is based on the original analysis done by DKG years ago,
> which pointed out the risks of replaying 0-RTT packets at attacker
> chosen times. That attack is largely mitigated by the replay protection
> in TLS 1.3, which is mandatory to implement. 0-RTT packets can only be
> replayed within a narrow window, which is only wide enough to account
> for variations in clock skew and network transmission.Need to update the
> text and account for that.
>
> * Comparison of privacy effects of long duration session and session
> 

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

[Tim Wicinski]

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.

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

[dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

[Tim Wicinski]

All

The authors took the advice from the working group and extracted the more
common features
into a separate document.   The chairs would like the working group to give
some comments, as
we feel a document like this should be considered for adoption.


https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt
Please read and comment on this draft.

thanks
tim




-- Forwarded message -
From: Paul Hoffman 
Date: Wed, May 19, 2021 at 12:59 PM
Subject: [dns-privacy] New draft-ietf-dprive-unauth-to-authoritative and
draft-pp-dprive-common-features
To: dpr...@ietf.org 


Greetings again. Peter and I have revised
draft-ietf-dprive-unauth-to-authoritative and
draft-pp-dprive-common-features based on recent mailing list traffic. One
major change is that we realized that we could move even more sections from
unauth-to-authoritative to common-features because they would apply to the
fully-authenticated use case. Please review them to see if you agree.

If people like the idea of us splitting out common features, it would be
good if it too became a WG document, particularly to help focus the
discussions on the unauthenticated and fully-authenticated use cases.

--Paul Hoffman and Peter van Dijk

https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt
https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt

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


smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox

[Tim Wicinski]

To Paul's point, this is the ICANN Base Registry Agreement listing the
permitted "TLD Zone Contents".

https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1

This is only for gTLDs that have signed this agreement.  The ccTLDs
generally have their own contracts which will vary.

This idea could or should work for all authoritative domains that are not
TLDs.

tim



On Tue, May 11, 2021 at 9:37 PM Paul Wouters  wrote:

> On Tue, 11 May 2021, Eric Rescorla wrote:
>
> > From my perspective, the primary open question is the wisdom of having
> > some kind of record in the parent domain.
>
> > While I understand that there are people who have reservations about
> > whether it will be practical to popuate the parent
>
> This is not about some people having reservations. As I explained
> before, you are talking about:
>
> - Updating DNS resolvers understand a new DS-like record on the 'wrong'
>end of the zone cut (incompatible with RFC 3597)
> - Updating DNS auth server code to serve a new DS-like on the 'wrong'
>end of the zone cut (incompatible with RFC 3597)
> - Update all the DNS servers run these new DNS resolvers
> - Adding a new EPP extension to transport the new record to the
>Registrar
> - Adding a new EPP extension to transport the new record from the
>Registrar to the Registry
> - Registrars updating their code (libraries and webgui)
> - Registries updating their code (libraries)
> - Updating ICANN contracts about allowed RR types
> - Writing CDS/CDNSKEY style auto-updating for this new record
> - Updating zone file verification tools to not barf on record being
>out of bailiwick
>
> Last time, I recommended you talk to people at the REGEXT working
> group, Registries/Registrars and DNS hosters, our ICANN liaison or SSAC.
>
> Did you contact any of these people to ask about the feasability of
> your proposal?
>
> > 2. Is this proposal a plausible starting point for that?
>
> No it is not. If a TLD that falls under ICANN policues would suggest
> running software that supports this proposed record, it would surely
> trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I
> would strongly advise not reject the TLDs technical proposal.
>
> This has nothing to do with what I want. I _want_ this record or similar
> solution to work, but it just realistically cannot work. That is also why
> people (including me) who are normally very strict against overloading
> have suggested the only way to signal something at the parent is via
> overloading the NS or DS record in some way. And using DS is better
> because it is signed and can be verified at the child.
>
> Paul
>
> ___
> 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] Publication has been requested for draft-ietf-dprive-xfr-over-tls-07

[Tim Wicinski via Datatracker]

Tim Wicinski has requested publication of draft-ietf-dprive-xfr-over-tls-07 as 
Proposed Standard on behalf of the DPRIVE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/


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

Re: [dns-privacy] [Ext] IETF 110 DPRIVE Agenda

[Tim Wicinski]

Paul

Not an unreasonable idea.   We'll bump the Oblivious DNS Over HTTPS talk
up, and
the Authoritative Encryption Discussion to the last part of the meeting.

tim


On Thu, Feb 25, 2021 at 4:12 PM Paul Hoffman  wrote:

> Given that "Signaling Authoritative DNS Encryption" is very much related
> to "Recursive to Authoritative DNS with Encryption", it might make the
> discussion more productive if they were adjacent in the agenda.
>
> --Paul Hoffman___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-06.txt

[Tim Wicinski]

Thanks Sara

Folks should take a look at the changes, and those who raised issues can
ensure
these updates have addressed everything.

thanks
tim


On Thu, Feb 11, 2021 at 11:41 AM Sara Dickinson  wrote:

> Hi All,
>
> This update should address the comments made during WGLC:
>
> * Update text relating to pipelining and connection reuse after WGLC
> comments.
> * Add link to implementation status matrix
> * Fix various typos
>
> Best regards
>
> Sara.
>
> > On 11 Feb 2021, at 16:39, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
> >
> >Title   : DNS Zone Transfer-over-TLS
> >Authors : Willem Toorop
> >  Sara Dickinson
> >  Shivan Sahib
> >  Pallavi Aras
> >  Allison Mankin
> >   Filename: draft-ietf-dprive-xfr-over-tls-06.txt
> >   Pages   : 39
> >   Date: 2021-02-11
> >
> > Abstract:
> >   DNS zone transfers are transmitted in clear text, which gives
> >   attackers the opportunity to collect the content of a zone by
> >   eavesdropping on network connections.  The DNS Transaction Signature
> >   (TSIG) mechanism is specified to restrict direct zone transfer to
> >   authorized clients only, but it does not add confidentiality.  This
> >   document specifies the use of TLS, rather than clear text, to prevent
> >   zone content collection via passive monitoring of zone transfers:
> >   XFR-over-TLS (XoT).  Additionally, this specification updates
> >   RFC1995, RFC5936 and RFC7766.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-06
> > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-xfr-over-tls-06
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

I believe when Brian sent the call out, he did say
"The focus of the call is the protocol defined in the draft."
The details do need to be fleshed out, but the chairs felt
the working group saw this as a starting point.

Also, as it was pointed out, the chairs have not seen any proposals
involving fully-authenticated encryption.  This will allow some focus.
It could very well be that the working group adopts this, and can't come
to agreement on solutions.

tim




On Mon, Feb 8, 2021 at 4:02 PM Paul Wouters  wrote:

> On Feb 8, 2021, at 12:11, Paul Hoffman  wrote:
> >
> > 
> > Without a fleshwd-out proposal for a fully-authenticated protocol to
> compare to, saying that this WG should not try to fulfill its charter to
> help encrypt recursive to authoritative traffic just seems wrong.
>
> We went over this in great detail with Peter van Dijk’s “put pubkey in the
> DS record” proposal where he wrote something fleshed out and we discussed
> it at great length, touching on things like RRT’s vs parent or child being
> in change control vs TLSA _prefix records on NS records vs domain records.
>
> We are discussing disagreement on basic concepts here, not on finishing up
> details after WG adoption of the idea. The only consensus I’ve seen so far
> is the problem statement.
>
> Once we get a rough consensus on a type of solution, we can think about
> fleshing it out. This document is fleshed out but doesn’t seem[*] to have
> consensus on its basic premise of its solution.
>
> Paul
> [*] the chairs will make that call
> ___
> 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] Minutes from Interim uploaded

[Tim Wicinski]

All

I uploaded the minutes taken from the interim into the datatracker.  You
can find it here:
https://datatracker.ietf.org/doc/minutes-interim-2021-dprive-01-202101271800/

I want to thank everyone who went behind me and cleaned up my comments.  It
saved me from listening to the recording.

If anyone is incorrectly quoted, or is missing please drop a note to the
chairs so we can fix that up.

thanks to everyone.

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

[dns-privacy] Working Group Last Call for draft-ietf-dprive-xfr-over-tls

[Tim Wicinski]

All

The authors on the xfr-over-tls draft have published an update to their
document and feel they have addressed all issues.


This starts a Working Group Last Call for draft-ietf-dprive-xfr-over-tls

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  4
February 2021

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

Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

On Sun, Oct 11, 2020 at 11:04 PM Benjamin Kaduk  wrote:

>
> > >Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
> > >
> > > It looks like
> > > (
> > >
> https://mailarchive.ietf.org/arch/msg/dns-privacy/1pZL1FA57hzE1e09mQ2HMg2aWYY/
> > > )
> > > Sara was going to follow up with the DITL authors to try and ascertain
> > > whether "almost all queries" is still accurate for the "UDP" aspect,
> > > though the IETF mailarchive search doesn't seem to find any more recent
> > > traffic on that topic.  Do we know if anyone actually heard back about
> > > this (or the "sent in [the] clear" a few lines previously)?
> > > I do not pretend to have the expertise needed to judge how the changes
> > > deployed by major browser affect the statistics for "all DNS traffic"
> > > (which presumably includes both stub-to-resolver and
> > > resolver-to-authoritative).
> > >
> >
> >
> > I  talked with Sara, who did reach out to the authors, and they informed
> us
> > that there  was no updates.
>
> It's good that we heard back, though I guess this still doesn't match with
> my intuition (and I guess Alissa made this into a discuss point).  But, I
> don't trust my intuition here without data to back it up :)
>
>
They presented that paper in the fall of 2019 at DNS-OARC
(https://indico.dns-oarc.net/event/32/contributions/728/ though oddly,
it was not recorded).  At the last OARC in September,
(https://indico.dns-oarc.net/event/34/contributions/speakers)
there was a talk about QNAME minimisation, but not on encryption.




> > > Section 4.1
> > >
> > >authentication or authorization of the client (resolver).  Due to
> the
> > >lack of search capabilities, only a given QNAME will reveal the
> > >resource records associated with that name (or that name's non-
> > >existence).  In other words: one needs to know what to ask for, in
> > >
> > > I agree with Warren that this statement ("only [...] will reveal [...]
> > > or that name's non-existence") is overly strong.
> >
> >
> > > Section 4.2
> > >
> > >The DNS request includes many fields, but two of them seem
> > >particularly relevant for the privacy issues: the QNAME and the
> > >source IP address. "source IP address" is used in a loose sense of
> > >"source IP address + maybe source port number", because the port
> > >
> > > In other contexts I've seen this combination referred to as the
> > > "transport address".
> > >
> > >The QNAME is the full name sent by the user.  It gives information
> > >about what the user does ("What are the MX records of example.net?"
> > >means he probably wants to send email to someone at example.net,
> > >which may be a domain used by only a few persons and is therefore
> > >very revealing about communication relationships).  [...]
> > >
> > > (editorial) something like not-a-secret-cabal.example might make the
> > > example more visceral than example.net does.
> > >
> > >create more problems for the user.  Also, sometimes, the QNAME
> embeds
> > >the software one uses, which could be a privacy issue.  For
> instance,
> > >_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
> > >
> > > (nit) I trust that this can be made into a complete sentence while
> > > addressing Warren's more-substantive comment.
> > >
> > >There are also some BitTorrent clients that query an SRV record for
> > >_bittorrent-tracker._tcp.domain.example.
> > >
> > > In a similar vein, I'm not sure what domain.example is supposed to
> > > represent here -- the domain of the author of the BitTorrent client?
> > >
> > >Therefore, all the issues and warnings about collection of IP
> > >addresses apply here.  For the communication between the recursive
> > >
> > > I mostly assume that this is intended to be a reference to the generic
> > > concerns about "IP addresses are PII", etc., that one is ambiently
> > > exposed to by reading enough about the Internet.  (There does not seem
> > > to be previous discussion of "collection of IP addresses" in this
> > > document, which would seem to indicate that it is not trying to refer
> > > back to previous text.)  If so, perhaps an extra word or two would help
> > > ("all the standard issues and warnings", "all the generic issues and
> > > warnings", etc.) clarify the intent of the reference.
> > >
> > >
> > I want to get back to this.
>
> Okay.
>
>
> > >In both cases, the IP address
> > >originating queries to the authoritative server is as sensitive as
> it
> > >is for HTTP [sidn-entrada].
> > >
> > > I don't see how [sidn-entrada] supports the claim that
> end-user-adjacent
> > > DNS client IP addresses are equally sensitive as HTTP client IP
> > > Addresses; it mentions "sensitive" only twice (as "privacy-sensitive",
> > > admittedly, applying to such IP addresses, but as an assertion without
> > > justification) and "http" only in URLs (mostly in the references) and
> as
> > 

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

[Tim Wicinski]

Alissa,

On Wed, Oct 7, 2020 at 9:43 PM Alissa Cooper via Datatracker <
nore...@ietf.org> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> DISCUSS:
> --
>
> == Section 1 ==
>
> "At the time of writing, almost all this DNS traffic is currently sent
>in clear (i.e., unencrypted).  However there is increasing deployment
>of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
>particularly in mobile devices, browsers, and by providers of anycast
>recursive DNS resolution services.  There are a few cases where there
>is some alternative channel encryption, for instance, in an IPsec VPN
>tunnel, at least between the stub resolver and the resolver.
>
>Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
>This has practical consequences when considering encryption of the
>traffic as a possible privacy technique.  Some encryption solutions
>are only designed for TCP, not UDP and new solutions are still
>emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic]."
>
> This text made me wonder about the value of publishing this bis document at
> this point in time. Things are evolving so rapidly that, with respect to
> several of the new parts of this document (e.g., the last few paragraphs of
> Sec. 6.1.1, Sec. 6.1.1.1, Sec. 6.1.1.2), an immutable summary designed to
> represent reality over the long term doesn't really seem feasible right
> now.
> Why not wait to see how QUIC, DOH, ADD, ODNS, etc. shake out in the next
> few
> years and take this up then?
>
>
The consensus of the WG was that enough changes have occurred since the
first document was published that it made sense to collect those details in
one place.  One could easily argue that this space is rapidly evolving, so
to say "let's just wait..." could be a never ending wait. Publishing this
document now allows the community to agree on the current state of affairs
that can help it focus on the critical next steps.

(Now saying that, we lack a summary narrative which lays all those out.
Which has been added).



== Section 6.1.1.2 ==
>
> "Users will only be aware of and have the ability to control such
>settings if applications provide the following functions:
>
>o communicate clearly the change in default to users
>
>o provide configuration options to change the default
>
>o provide configuration options to always use the system resolver"
>
> This doesn't seem true. If the third bullet isn't provided, users still
> have
> awareness and control. Also, the bullets seem redundant with the text
> above, as
> if this is saying "users only have awareness and control if they have
> awareness
> and control." As a result I'm not sure what this text is really meant to
> convey.


First. Another comment changed the first bullet to be:

  "communicate clearly the change to users when the default application

 resolver changes away from the system resolver"

Now these bullets are in relation to an application.   We could update the
second two bullet points to be something like this:

  o  provide configuration options to change the default application
resolver

  o  provide configuration options to allow the application to always use
the system resolver



> --
> COMMENT:
> --
>
> Please remove uses of "us" and "we," given that this is a consensus
> document.
>
>
Thanks. I believe I found them

"Privacy policies for these servers may or may not be available and users
> need
> to be aware that privacy guarantees will vary with network." --> This is
> unrealistic as almost no users understand any of this. I'd recommend
> removing
> this.
>
>
"user" in this case is an individual but is also meant to represent
"administrator

of computing resources" such as in an enterprise environment, etc.



> Section 6.1.3: The title says "Blocking of User Selected DNS Resolution
> Services" but the text is actually broader than that and applies to
> blocking of
> resolution services whether or not they are user-selected. I would suggest
> changing the title.
>
>
Would "Altering of User Selected DNS Resolution Services" work in this case?



> Section 6.1.4.2:
> "Privacy focused users 

Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

On Wed, Oct 7, 2020 at 12:16 AM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> COMMENT:
> --
>
> Section 1
>
>At the time of writing, almost all this DNS traffic is currently sent
>in clear (i.e., unencrypted).  However there is increasing deployment
>
> nit: I think that "in the clear" is the term of art (add "the").
>

Another comment suggested changing "in clear (i.e., unencrypted)"
to just be "unencrypted."

Would this work for you?


>Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
>
> It looks like
> (
> https://mailarchive.ietf.org/arch/msg/dns-privacy/1pZL1FA57hzE1e09mQ2HMg2aWYY/
> )
> Sara was going to follow up with the DITL authors to try and ascertain
> whether "almost all queries" is still accurate for the "UDP" aspect,
> though the IETF mailarchive search doesn't seem to find any more recent
> traffic on that topic.  Do we know if anyone actually heard back about
> this (or the "sent in [the] clear" a few lines previously)?
> I do not pretend to have the expertise needed to judge how the changes
> deployed by major browser affect the statistics for "all DNS traffic"
> (which presumably includes both stub-to-resolver and
> resolver-to-authoritative).
>


I  talked with Sara, who did reach out to the authors, and they informed us
that there  was no updates.

>
>This has practical consequences when considering encryption of the
>traffic as a possible privacy technique.  Some encryption solutions
>are only designed for TCP, not UDP and new solutions are still
>emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic].
>
> [It looks like dnsoquic became draft-huitema-dprive-dnsoquic.]
>
>
Oh good catch - and in *our* WG!



> Section 3
>
>multiple dynamic contexts of each device.  This document does not
>attempt such a complex analysis, instead it presents an overview of
>the various considerations that could form the basis of such an
>analysis.
>
> nit: looks like a comma splice.
>

I changed "such a complex analysis, instead it" to
"such a complex analysis, but instead it"


> Section 4.1
>
>authentication or authorization of the client (resolver).  Due to the
>lack of search capabilities, only a given QNAME will reveal the
>resource records associated with that name (or that name's non-
>existence).  In other words: one needs to know what to ask for, in
>
> I agree with Warren that this statement ("only [...] will reveal [...]
> or that name's non-existence") is overly strong.


> Section 4.2
>
>The DNS request includes many fields, but two of them seem
>particularly relevant for the privacy issues: the QNAME and the
>source IP address. "source IP address" is used in a loose sense of
>"source IP address + maybe source port number", because the port
>
> In other contexts I've seen this combination referred to as the
> "transport address".
>
>The QNAME is the full name sent by the user.  It gives information
>about what the user does ("What are the MX records of example.net?"
>means he probably wants to send email to someone at example.net,
>which may be a domain used by only a few persons and is therefore
>very revealing about communication relationships).  [...]
>
> (editorial) something like not-a-secret-cabal.example might make the
> example more visceral than example.net does.
>
>create more problems for the user.  Also, sometimes, the QNAME embeds
>the software one uses, which could be a privacy issue.  For instance,
>_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
>
> (nit) I trust that this can be made into a complete sentence while
> addressing Warren's more-substantive comment.
>
>There are also some BitTorrent clients that query an SRV record for
>_bittorrent-tracker._tcp.domain.example.
>
> In a similar vein, I'm not sure what domain.example is supposed to
> represent here -- the domain of the author of the BitTorrent client?
>
>Therefore, all the issues and warnings about collection of IP
>addresses apply here.  For the communication between the recursive
>
> I mostly assume that this is intended to be a reference to the generic
> concerns about "IP addresses are PII", etc., that one is 

Re: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

On Wed, Oct 7, 2020 at 8:44 AM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for responding to the SECDIR review (and thank you to Stephen
> Farrell
> for performing the SECDIR review).
>
> ** Section 3.5.1.1.  Per “These resolvers may have strong, medium, or weak
> privacy policies …”, what are the dimensions of this Likert-style scale?  I
> recommend a simpler sentence -- “… may have varied privacy policies”.
>
>
Ok, i've made that change.

> ** Section 6.1.1.  Per “All major OS's expose the system DNS settings and
> allow
> users to manually override them if desired”, agreed.  However, in managed
> environments, users may not be able to manually override these settings.
>
>
Yes. I am leaving this open for now.

> ** Section 6.1.3.  Per “User privacy can also be at risk if there is
> blocking
> (by local network operators or more general mechanisms) …”, what is a “more
> general mechanism”?  Also, "local network operator" describes who is doing
> the
> blocking and "general mechanisms" seems to be describing a technique.
>
>
I removed the comment in parenthesis

** Section 8.  Editorial.  Per “They are used for many reasons – some good,
> some bad.”, I’d recommend against making judgements and stick to a rubric
> of
> operational practices and attacker behavior (say RFC7258).  I’m not sure
> this
> sentence is needed.
>

Ok, I've dropped it.

>
> Editorial nits
>
> -- ** Section 6.1.1.  Editorial.  s/additionally highly dependent/highly
> dependent/
>
> -- Section 12.  Typo. s/apprecriated/appreciated/
>

fixed

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

Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

Rob

You are not the only person to request the summary of changes.  It's a fine
idea and we'll pull something together.

tim


On Wed, Oct 7, 2020 at 1:29 AM Rob Sayre  wrote:

> On Tue, Oct 6, 2020 at 10:23 PM Benjamin Kaduk  wrote:
>
>> Perhaps "search" was not the best word to use
>>
>
> I think that is correct. Maybe the document should include a summary of
> the changes relative to RFC 7626. Let me apologize in advance if there is
> one, and I've missed it.
>
> thanks,
> Rob
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

On Thu, Oct 8, 2020 at 2:23 AM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> COMMENT:
> --
>
> I'll add my thanks for this document.  I have tripped on some of the
> issues in
> my experience, but some of the others described here were eye-opening.  I'm
> also learning from the ensuing discussions.
>
> Section 1:
>
> A couple of nits:
>
> * "DNS relies on caching heavily ..." -- suggest "DNS relies heavily on
> caching
> ..."
>
>
fixed

* "Both are a big privacy concern since ..." -- suggest "Both are big
> privacy
> concerns since ...", unless you mean the two of them collectively (in which
> case, please say so)
>
>
Another edit suggested changing this to "Both are a significant privacy"
Does that work?



> I agree with Warren in that it's not clear what's leaking in the example
> at the
> bottom of the second paragraph of Section 4.2.
>
> In Section 5.1, please expand "CPE" on first use.
>

Good catch - updated

>
> I'm having trouble parsing the third paragraph of Section 5.2.  The fourth
> paragraph in the same section needs some commas.
>

Third Paragraph - instead of "There are some general examples, for example,"
Maybe "Some general examples include "?

How about this for the fourth paragraph:


Note that even when using encrypted transports, the use of clear text
transport
options to decrease latency can provide correlation of a users'
connections,

e.g. using TCP Fast Open [@RFC7413].


thanks

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

Re: [dns-privacy] Robert Wilton's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

Rob

On Mon, Oct 5, 2020 at 8:40 AM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> COMMENT:
> --
>
> Hi,
>
> Thank you for this document.  I found it interesting and easy to read.
>
> A few minor comments/nits that I spotted whilst reading this document:
>
> "in clear (i.e., unencrypted)." => "unencrypted."
> "However there is" => "However, there is"
> "designed for TCP, not UDP and new" => "designed for TCP, not UDP, and new"
> "It can be noted also that" => "It can also be noted that"
> "Both are a big privacy concern" => "Both are significant privacy concerns"
> "de-NAT DNS queries dns-de-nat [3]" => "de-NAT DNS queries [3]"?
>
>
Thanks for these - the last one appears to be a markdown reference fail.
I'll make sure it's worked out

thanks
tim

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

Re: [dns-privacy] Erik Kline's Yes on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

[Tim Wicinski]

On Tue, Oct 6, 2020 at 2:04 AM Erik Kline via Datatracker 
wrote:

> Erik Kline has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> --
> COMMENT:
> --
>
> [[ questions ]]
>
> [ section 6.1.1.1 ]
>
> * Does "Strict DoT" have a definition somewhere?  I couldn't find one
>   in 8499 nor in 7858.
>
>
Erik

There is not a definition for "Strict DoT", but DNSOP has a CfA out on
updating 8499-bis with
some updates which will include Strict DoT.


> [[ nits ]]
>
> [ section 1 ]
>
> * "sent in clear", consider perhaps: "sent in the clear"
>
> [ section 4.1 ]
>
> * "those transaction" -> "those transactions"
>
> [ section 6.1.1 ]
>
> * "to limited subset" -> "to a limited subset"
>
> [ section 6.1.3 ]
>
> * "know to be used" -> "known to be used"
>
>
> Thanks - updated all of these

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

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

[Tim Wicinski]

Warren

   There are many ways in which supposed "private"
   resources currently leak. A few  examples are  DNSSEC NSEC zone walking;
   passive-DNS services; etc.

with the references added in. and changing the section title

tim


On Wed, Oct 7, 2020 at 8:16 PM Warren Kumari  wrote:

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

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

[Tim Wicinski]

Warren


On Wed, Oct 7, 2020 at 4:40 PM Warren Kumari  wrote:

> On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman 
> wrote:
> >
> > Hi Warren,
> >  Thanks for the feedback. I have a couple of responses (as document
> > shepherd) inline...
> >
> > On 10/5/20 5:42 PM, Warren Kumari via Datatracker wrote:
> > > Warren Kumari has entered the following ballot position for
> > > draft-ietf-dprive-rfc7626-bis-06: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
> > >
> > >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > Apologies for changing my YES to a DISCUSS -- I found a later version
> of my
> > > notes on this draft.
> > >
> > > My DISCUS is specifically around the"The Alleged Public Nature of DNS
> Data" /
> > > "It has long been claimed that "the data in the DNS is public" section
> -- it
> > > seems to be unnecessarily creating and then shooting down a strawman.
> The "the
> > > data in the DNS is public" aphorism talks is more about the
> confidentiality one
> > > can expect **publishing** data in the DNS, not the privacy of the
> lookups.
> > > This whole section (to my mind) undersells the threat that publishing
> something
> > > in the DNS and expecting it to remain private creates -- for example,
> I'd be
> > > extremely foolish to insert: my-password-fd345432233e.example.com 600
> IN TXT
> > > "Hunter2"
> > >
> > > Services like Farsight Securities (excellent!) DNSDB will likely
> capture this
> > > almost as soon as I use it somewhere. In addition, the "Due to the
> lack of
> > > search capabilities, only a given QNAME will reveal the resource
> records
> > > associated with that name" sentence is either false, or at the very
> least,
> > > misleading.
> >
> > The above is an excellent example of the subtle difference between DNS
> > publication privacy and DNS transaction privacy. DNSDB only know the
> > domain name because the DNS transaction is not encrypted.
> >
> > The goal of this section, going back to 7626, is to point out that
> > difference. I believe you agree with that given your support for the
> > second paragraph in the section.
> >
> > >
> > > $ dig +dnssec foo.ietf.org | grep NSEC
> > > clearly tells me that the names etherpad.ietf.org and ftp.ietf.org
> both exist,
> > > and $ dig +dnssec ftpa.ietf.org | grep NSEC tells me that the next
> name is
> > > guides.ietf.org
> > >
> >
> > Sure, if a zone operator leverages NSEC records, the above could happen.
> > If a zone operator does not want that type of enumeration to occur,
> > NSEC3 records should be used.
> >
> > Is the ask here for some description of possible means of enumerating a
> > zone if NSEC records are published? Or that Passive DNS allows observers
> > to collect names if a collector is in the DNS exchange path? That seems
> > like overkill to me given that the enumeration can only occur in very
> > specific instances.
>
> I think that much of what is making me twitch is the tone in this
> section -- the section title is: "The *Alleged* Public Nature of DNS
> Data" (emphasis mine) and the first sentence is: "It has long been
> claimed that "the data in the DNS is public"."; both of these imply
> that data in the DNS should not be thought of as (generally) public,
> or that it is generally feasible to keep DNS data private.  I think
> that this is likely to lead to people thinking that putting
> super-secret stuff in the DNS will end well for them. There are all
> sorts of ways that this leaks, including NSEC zone walking, people
> looking up secretproject.corp.example.com at work, and then taking
> their laptop home, opening it and having the browser reload the page,
> search-list magic, passive-dns, etc.
>
> How is something like (will need massaging):
>
> 4.1.  The Public Nature of DNS Data
>
>It is often stated that "the data in the DNS is public".  This sentence
>makes sense for an Internet-wide lookup system,  and there
>are multiple facets to the data and metadata involved that deserve a
>more detailed look.  First, access control lists (ACLs) and private
>namespaces notwithstanding, the DNS operates under the assumption
>that public-facing authoritative name servers will respond to "usual"
>DNS queries for any zone they are authoritative for without further
>authentication or authorization of the client (resolver).  Due to the
>lack of search capabilities, only a 

Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

[Tim Wicinski]

(speaking not as a chair)

I think this is worth doing.

tim



On Thu, Aug 6, 2020 at 3:45 PM John R. Levine  wrote:

> Yes, this is worth doing.  Agree with comments that it has to be
> compatible with non-opportunistic encryption.
>
> R's,
> John
>
> PS: RFC 7435.
>
> > Greetings again. The following is a short text-based version of my
> slides from last week's WG meeting. I'd like to find out if this is one of
> the use cases that the WG would be interested in dealing with.
> >
> > Use case: Opportunistic encryption for recursive to authoritative
> >
> > In this use case, a resolver operator says “I’m happy to use encryption
> with the authoritative servers if it doesn’t slow down getting answers by
> much”, and an authoritative server says “I’m happy to use encryption with
> the recursive resolvers if it doesn’t cost me much”.
> >
> > Opportunistic encryption is defined in RFC 7535. From the abstract:
> "Protocol designs based on Opportunistic Security use encryption even when
> authentication is not available, and use authentication when possible,
> thereby removing barriers to the widespread use of encryption on the
> Internet."
> >
> > The assumptions behind the use case are:
> > • More encryption is good for the Internet
> > • Resolver vendors are smart and motivated
> > • Most resolvers don’t validate with DNSSEC and may never want to
> > • Authoritative operators don’t care much about encryption, but some
> would turn it on because more encryption is good for the Internet
> > • Other use cases for authentication stronger than opportunistic may
> appear and would co-exist with this one
> >
> > The other slides had thoughts about possible solutions that implement
> this use case, but before we go there, I wanted to find out if more than a
> handful of people here are interested in this use case. If so, I could turn
> the above into a draft with some possible solutions for us to bang on.
> >
> > --Paul Hoffman
> >
> >
>
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-ghedini-dprive-early-data

[Tim Wicinski]

All

The call for adoption has ended and we're received feedback on adopting and
working
on this.  Consensus appears the document needs work but is a good starting
point

thanks
tim


On Tue, Apr 14, 2020 at 11:45 AM Christopher Wood 
wrote:

> I support adoption and am willing to review.
>
> Best,
> Chris
>
> On Tue, Apr 14, 2020, at 2:42 AM, Stephen Farrell wrote:
> >
> > I support adoption. There's work to be done on it, but
> > it's a good start and should be a useful document.
> >
> > S.
> >
> > On 08/04/2020 18:27, Tim Wicinski wrote:
> > > This starts a Call for Adoption for draft-ghedini-dprive-early-data
> > >
> > > The draft is available here:
> > > https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
> > >
> > > Please review this draft to see if you think it is suitable for
> adoption
> > > by DPRIVE, and comments to the list, clearly stating your view.
> > >
> > > Please also indicate if you are willing to contribute text, review,
> etc.
> > >
> > > This call for adoption ends: 22 April 2020
> > >
> > > Thanks,
> > >
> > >
> > > ___
> > > 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
> >
> > Attachments:
> > * 0x5AB2FAF17B172BEA.asc
> > * signature.asc
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-huitema-dprive-dnsoquic

[Tim Wicinski]

All

The call for adoption has ended and strong consensus to adopt.  Thanks
for all the feedback.

tim


On Wed, Apr 22, 2020 at 6:18 AM Benno Overeinder  wrote:

> I support the adoption of the draft and I am willing to contribute/review.
>
> -- Benno
>
>
> On 08/04/2020 18:41, Tim Wicinski wrote:
> >
> > This starts a Call for Adoption for draft-huitema-dprive-dnsoquic
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DPRIVE, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc.
> >
> > This call for adoption ends: 22 April 2020
> >
> > Thanks,
> > tim/brian
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
> >
>
>
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] DPRIVE Interim 2020-01 Minutes, Actions

[Tim Wicinski]

All

Brian and I thank all for attending the DPRIVE interim yesterday, and we
want to thank Eric our AD for helping out with slides at the last minute.

I've uploaded the minutes which were in the Etherpad (Thanks Benno!)

https://datatracker.ietf.org/doc/minutes-interim-2020-dprive-01-202004081600/

If you have any corrections, please let us know, or send us a pull request
to the github version:

https://github.com/DPRIVE/wg-materials/blob/master/dprive-ietf107/dprive-ietf107-minutes.md

Actions from the meeting

draft-huitema-quic-dnsoquic

We started a call for adoption on this draft (
https://mailarchive.ietf.org/arch/msg/dns-privacy/tHNGQvHCjd4xJQTNdqS-E0Mtg20/),
and is receiving comments.

draft-ghedini-dprive-early-data

Based on the conversation, we also started a call for adoption on this
draft (
https://mailarchive.ietf.org/arch/msg/dns-privacy/GXnXWzWr6CEqpnBWoiNSfb7vxvc/).
  We'll want to hear on this as well.

draft-mglt-add-signaling-filtering-policies

The chairs were more interested in starting some spirited discussion on the
larger topic, and the we appreciated the comments.  The chairs will talk
this out with the author, but we thank Daniel for the talk.

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

[dns-privacy] Call for Adoption: draft-ghedini-dprive-early-data

[Tim Wicinski]

This starts a Call for Adoption for draft-ghedini-dprive-early-data

The draft is available here:
https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 22 April 2020

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

[dns-privacy] Call for Adoption: draft-huitema-dprive-dnsoquic

[Tim Wicinski]

This starts a Call for Adoption for draft-huitema-dprive-dnsoquic

The draft is available here:
https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 22 April 2020

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

[dns-privacy] DPRIVE Interim Meeting 8 April 2020 16:00-17:30 UTC

[Tim Wicinski]

All,

Here’s some more information and preparation material for DPRIVE  WG
Virtual meeting:

Date: Wednesday April 8th, 2020
Time: 16:00-17:30 (UTC)

Location: WebEx
https://ietf.webex.com/ietf/j.php?MTID=m88e3d0d091544ea59c79eb5e610a115a

Jabber:  xmpp:dpr...@jabber.ietf.org?join


EtherPad: TBD

Agenda:
https://datatracker.ietf.org/doc/agenda-interim-2020-dprive-01-dprive-01/

Volunteers?
==
We need volunteer(s) to help take notes to etherpad and to watch Jabber for
questions.
If you’re willing please let the chairs (dprive-cha...@ietf.org) know.

BlueSheets
==
Attendees are asked to visit and enter your Name+Affiliation in the
Blue-Sheet section of the DPRIVE Etherpad.
Please add your name and affiliation to the DPRIVE etherpad.

Mic Line Queue
=
The Mic Line will use the WebEx chat channel.  To get in the queue type q+
to leave type q-.
Please don’t type questions or other things into the WebEx chat channel as
that will make
managing the queue very hard for the chairs.  Please use the Jabber channel
for side conversations.

When you connect into WebEx you should start off as auto-muted so you’ll
need to unmute yourself to speak when called.

Helpful Info & Prep
==
The IETF has prepared a couple of documents to help get everyone ready,
including a reminder that you need to register for IETF107 as a remote
participant to join remotely.

  https://www.ietf.org/how/meetings/107/session-participant-guide/

  https://www.ietf.org/how/meetings/107/session-presenter-guide/


Agenda
==

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

### Current Working Group Business

*   DNS over Quic
- https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
- Authors
- 15 min
- Chairs Action: Adopt?

*   Using Early Data in DNS over TLS
- https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
- alessan...@ghedini.me
- 15 min
- Chairs Action: Adopt?

### New Working Group Business

*   Signaling resolver's filtering policies
-
https://datatracker.ietf.org/doc/draft-mglt-add-signaling-filtering-policies/
- draft-mglt-add-signaling-filtering-polic...@ietf.org
- 15 min
- Chairs Action: ?
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Errata Held for Document Update] RFC7858 (5375)

[Tim Wicinski]

I agree with Patrick's comment that the folks from DNScrypt should be the
ones giving us the
guidance here.

Tim
(wearing the hat today, so Warren doesn't have to)

On Mon, Dec 23, 2019 at 1:01 PM Patrick Mevzek 
wrote:

> On 23/12/2019 12:54, Warren Kumari wrote:
>
> > W
> > p.s: if it were mine, I'd probably mark it hold for update with a note
> > of "someone should validate this..."
>
> In May 2018, I also reported that the correct one was probably more the
> ..info one than the .org one, because at that time both dnscrypt.org and
> www.dnscrypt.org replied with wrong X.509 certificates.
>
> At least right now both resolves correctly but with different content.
>
> Maybe, people behind DNScrypt project/tools/implemnentations should
> voice which website is the correct one...
>
> --
> Patrick Mevzek
>
> ___
> 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] Draft Minutes from IETF106 meeting

[Tim Wicinski]

Thanks again to Mr. Paul Hoffman for putting together the draft minutes of
the meeting.
Because of the Phase 2 discussion had several useful points, I plan on
going back
and listening to the audio  and confirm with the authors on that portion to
make sure we picked up everything.

The minutes are here.

https://datatracker.ietf.org/doc/minutes-106-dprive/

If you see anything that looks incorrect please drop a note to the chairs,
or send a pull request:

https://github.com/DPRIVE/wg-materials/blob/master/dprive-ietf106/dprive-ietf106-minutes.txt

Thanks for a productive meeting

Tim/Brian
DPRIVE WG
IETF 106, Singapore
Chairs: Tim Wicinski, Brian Haberman (remote)
Minutes taken by Paul Hoffman
Text from slides not given here

Admiistrivia

Adaptive DNS: Improving Privacy of Name Resolution
draft-pauly-dprive-adaptive-dns-privacy
Tommy Pauly
Tim: Which list for discussion?
Tommy: Both
Brian Dickson: GoDaddy will turn on DNSSEC signing for all customers
Alex Mayrhofer: Get into a grey area of what is recursive and what is 
authoritative
We should be careful
Could instead use a URI RR
Tommy: URI RR doesn't let you say what the semantics of the 
value is
Do we want to put DoH in front of main authoritative 
servers?
Alex: Maybe like hosts.txt made modern
Petr Špaček: Custom made Tor network with DNS on top
Tommy: It is possible to build to deploy with bad privacy 
prolicies
Stephen Farrel: Maybe being too optimistic
How will a client choose the oblivious feature?
Tommy: Looking for an assertion between two zones
Stephen: Needs a lot more specification
Lawrence Colitti: Duplicated information from the HTTPSVC record
Tommy: It is a hint where to go look
Gives a way to know which additional domains to look
Pushing over HTTP2 at the same time
Lawrence: Why tie oblivious with the other parts?
Ben Schwartz: We should be thinking more about architecture
Likes the idea of mixing recursive and authitative
Mode-switching resolver
Ralf Weber: Encourage to look into other transports
Vittorio Bertola: Does this actually give more privacy?
Wants to see more analysis on this
Thinks it reduces privacy
Tommy: Definitely has a relationship with the name that they 
are going to
Is about to connect to the same address
Tim: Part of this falls into DPRIVE charter
Move this here instead of ADD   

Oblivious DNS Over HTTPS
draft-pauly-dprive-oblivious-doh
Chris Wood
Paul Hoffman: Make this oblivious HTTP, do it somewhere else
RalfW: Gets scared of network of open proxies
Could be abused to kill DoH servers
Chris: Doesn't make this worse
Tiru Reddy: Why not just use a VPN instead
Chris: That is another type of proxy
Petr: ?
Stephen: Of two minds; maybe just do a Tor-ish thing, maybe a purely 
DNS thing
Mike Bishop: If you proxy is far from the client, you will get worse 
location information
Tor uses consistent node
Lawrence: Bear in mind latency
DNS is lightweight at the moment, could get overwhelmed by size 
of TLS
Brian: Have you looked at three-way party encryption?

DNS server privacy policy with assertion token
draft-reddy-dprive-dprive-privacy-policy
Tiru Reddy
Paul Wouters: Seem reinvention of EV certs for DNS
Mark Nottingham: Explore why P3P efforts failed
Why should need to learn new kinds of consent model
Ben: Supportive of idea of geting opaque human-readable information 
about a DNS server
Statiing as a privacy policy takes it into difficult domain
Machine-readable formatting is not going to work
Trying to reduce legal language to machine-readable language is 
hard
Need exceptions
Is happy to have just a URL
Tiru: Wants to have both
Vitorrio: Finds it useful
Will needs to merge with user provisioning
Eric Rescorla: How will this work in practice?
(Walks through scenario)
Web PKI is based on mechanical comparision of domain names, not 
user comparison
Browsers are moving away from this
Alissa Cooper: This has been tried in many places
Invokes GEOPRIV
Need to look elsewhere

DNS Privacy Requirements for Exchanges between Recursive Resolvers and 
Authoritative Servers
draft-lmo-dprive-phase2-requirements
Alex Mayrhofer and Jason Livingood
Section 4:
Eric: Needs to discuss downgrade

Re: [dns-privacy] Call for Adoption: draft-hzpa-dprive-xfr-over-tls

[Tim Wicinski]

Hi

The call for adoption for this document has finished and we've received
consensus on adopting this work.



On Wed, Nov 6, 2019 at 11:24 AM Robert Edmonds  wrote:

> Tim Wicinski wrote:
> > This starts a Call for Adoption for draft-hzpa-dprive-xfr-over-tls
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DPRIVE, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc.
>
> I support adoption of draft-hzpa-dprive-xfr-over-tls and am willing to
> review.
>
> --
> Robert Edmonds
>
> ___
> 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] Tentative agenda for DPRIVE IETF 106

[Tim Wicinski]

All

We've put together a tentative agenda for the DPRIVE meeting for IETF106,
listed here:
https://datatracker.ietf.org/meeting/106/materials/agenda-106-dprive-00

Also included below. Please contact the chairs for any issues, etc.

Brian won't be attending in person but is planning to be there remotely.
We will need minute takers and jabber scribes.

Thanks
Tim/Brian



# DNS Privacy Exchange (DPRIVE) WG
## IETF 106, Singapore

* Date: 22 November 2019
* Time: 1000-1200 SST 1500-1700 UTC
* Room: Collyer

* Chair: Tim Wicinski 
* Chair: Brian Haberman 

* Very Responsible Area Director: Éric Vyncke 

* [DataTracker](https://datatracker.ietf.org/group/dprive/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

### New Working Group Business

*   Draft name:  Adaptive DNS: Improving Privacy of Name Resolution
- Datatracker URL:
https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/
- Authors
- Time Requested:  20

*   Draft name:  Oblivious DNS Over HTTPS
- Datatracker URL:
https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/
- Authors
- Time Requested:  20

### Current Working Group Business

*   Draft name:  DNS Privacy Requirements for Exchanges between Recursive
Resolvers and Authoritative Servers
- Datatracker URL:
https://datatracker.ietf.org/doc/draft-lmo-dprive-phase2-requirements/
- Authors Working Session
- Time Requested:  70
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

[Tim Wicinski]

The working group has given lots of feedback on this and the authors have

worked to address all these concerns. The last larger item was discussed and

resolved during our interim.


We want to run a 1 Week WGLC to confirm all outstanding items have been
resolved.


This starts a Second Working Group Last Call for draft-ietf-dprive-bcp-op


Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/



The Current Intended Status of this document is: Best Current Practices


Please review the draft and offer relevant comments.

If this does not seem appropriate please speak out.

If someone feels the document is *not* ready for publication, please speak
out with your reasons.


This starts a two week Working Group Last Call process, and ends on: 8
November 2019
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

Thanks Stephen

(Follow up on this in another email)


On Thu, Oct 31, 2019 at 9:16 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 31/10/2019 13:12, Sara Dickinson wrote:
> > Hi All,
> >
> > Following the DPRIVE interim meeting earlier this week I’ve done an
> > update to the draft with two main changes:
> >
> > 1) I have remove the text around consent that did not have consensus
> > i.e. paragraph 2 in section 5.3.3 and Item 6 in the DROP Practice
> > statement (and in the example). I believe the chairs will follow up
> > with a request to the list to gain consensus on what text (if any)
> > can be agreed on wrt this topic based on the options discussed in the
> > interim.
>
> I had a look at the diff and -05 certainly resolves my
> comments on this topic.
>
> Thanks,
> S.
>
>
> >
> > 2) I hope that all the other comments raised on the list during WGLC
> > are now also addresses in this version. If I’ve missed anything
> > please let me know.
> >
> > Best regards
> >
> > Sara.
> >
> >> On 31 Oct 2019, at 13:10, internet-dra...@ietf.org wrote:
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories. This draft is a work item of the DNS PRIVate Exchange
> >> WG of the IETF.
> >>
> >> Title   : Recommendations for DNS Privacy Service
> >> Operators Authors : Sara Dickinson Benno J. Overeinder
> >> Roland M. van Rijswijk-Deij Allison Mankin Filename:
> >> draft-ietf-dprive-bcp-op-05.txt Pages   : 40 Date
> >> : 2019-10-31
> >>
> >> Abstract: This document presents operational, policy and security
> >> considerations for DNS recursive resolver operators who choose to
> >> offer DNS Privacy services.  With these recommendations, the
> >> operator can make deliberate decisions regarding which services to
> >> provide, and how the decisions and alternatives impact the privacy
> >> of users.
> >>
> >> This document also presents a framework to assist writers of a DNS
> >> Recursive Operator Privacy Statement (analogous to DNS Security
> >> Extensions (DNSSEC) Policies and DNSSEC Practice Statements
> >> described in RFC6841).
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-05
> >> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-05
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-05
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> ___ dns-privacy mailing
> >> list dns-privacy@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dns-privacy
> >
> > ___ dns-privacy mailing
> > list dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
> >
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Call for Adoption: draft-hzpa-dprive-xfr-over-tls

[Tim Wicinski]

This starts a Call for Adoption for draft-hzpa-dprive-xfr-over-tls

The draft is available here:
https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We'll count all current emails about adoption.

This call for adoption ends: 15 November 2019

Thanks,

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

[dns-privacy] Working Group Last Call for draft-ietf-dprive-bcp-op

[Tim Wicinski]

This starts a Working Group Last Call for draft-ietf-dprive-bcp-op

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/


The Current Intended Status of this document is: Best Current Practices

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on: 30
August 2019

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

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

[Tim Wicinski]

This starts a Working Group Last Call for draft-ietf-dprive-rfc7626-bis


Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

The Current Intended Status of this document is: Informational

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  30
August 2019

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

[dns-privacy] Draft Minutes from DPRIVE IETF104

[Tim Wicinski]

All

Here are the draft minutes from this morning's meeting.

https://datatracker.ietf.org/meeting/104/materials/minutes-104-dprive-00

Please drop a note to the chairs or the list with any updates, comments,
etc.

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

[Tim Wicinski]

I see dialing info of

1-650-479-3208 Call-in toll number (US/Canada)
Access code:  640 873 331

I am digging up alternative numbers.

On Mon, Dec 10, 2018 at 9:18 AM Henderson, Karl  wrote:

> Is there a dial-in number for the dprive webex meeting today?
> ___
> 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] Rough Agenda for IETF103

[Tim Wicinski]

Hi

Here's a rough agenda for IETF103.  We're going to follow through on the
discussions from the mailing list on the User Perspective, and Recursive /
Authoritative Perspective.

*https://datatracker.ietf.org/meeting/103/materials/agenda-103-dprive-00
<https://datatracker.ietf.org/meeting/103/materials/agenda-103-dprive-00>*

 If folks would like to present for one of these perspective, please send
the chairs a note. If there are multiple folks, we'll pick one.

thanks
Tim/Brian
# DNS Privacy Exchange (DPRIVE) WG
## IETF 99, Prague

* Date: Wednesday 7 November, 2018
* Time: 09:00-11:00 IST
* Room: Meeting 1

* Chair: Tim Wicinski 
* Chair: Brian Haberman 

* IESG Overlord:  Terry Manderson 

* [DataTracker](https://datatracker.ietf.org/group/dprive/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

### Step 2 Discussion

* User Perspective,  30 Minutes

* Authorative and Recursive Perspecive, 1 Hour

## Time Remaining 

* draft-bretelle-dprive-dot-for-insecure-delegations, 10 min
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-dickinson-dprive-bcp-op

[Tim Wicinski]

All

Thanks for the feedback -the call for adoption has ended and we have solid
consensus to adopt and work on this document.  The chairs will work with
the authors to upload an updated version.

On Mon, Jul 23, 2018 at 3:24 AM, Matthijs Mekking 
wrote:

>
>
> On 07/18/2018 08:33 PM, Jim Reid wrote:
>
>>
>>
>> On 18 Jul 2018, at 19:25, Barry Raveendran Greene 
>>> wrote:
>>>
>>> I support the adoption of this work into the WG.
>>>
>>
>> +1
>>
>
>
> +1 more
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

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

Tim


On Thu, Jul 19, 2018 at 4:43 PM, Jim Reid  wrote:

> On 19 Jul 2018, at 21:17, Tim Wicinski  wrote:
> >
> > For example, Verisign has .com which is quite large.  My Employer has
> domains at the SLD issue that 'currently' has > 100MM records.
> >
> > Are the difference serving records vs serving delegations?
>
>
>
>
> I doubt response sizes will be markedly different. Or at least not enough
> to matter much. What should be important is the query rate. If an
> authoritative server is getting thousands++ of queries per second -- most
> likely TLD and root servers -- what's the impact when much of that traffic
> goes over TLS? If I ran such a server, I'd be very reluctant to switch on
> DNS over TLS (or DOH or whatever). And even less likely to do that if this
> WG starts from a problem statement which excludes my PoV.
>
> Some TLD operators may well be less clueful than others. However as Scott
> said sticking to the technical issues should mean the WG gets a more
> complete picture of the use cases.
>
> An important constituency didn't engage in the development of DNSSEC-bis,
> refused to deploy it and that's why we got DNSSEC-ter. OK, that's an
> over-simplification. But it shows what might happen in this WG if some use
> cases and requirements get overlooked.
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

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.

Tim


On Thu, Jul 19, 2018 at 2:56 PM, Jim Reid  wrote:

> On 19 Jul 2018, at 19:30, Tim Wicinski  wrote:
> >
> >  For the time being, we would like to bypass the TLD server operator
> > perspective. While we are in this phase of discussion, the chairs would
> > like everyone to follow these guidelines:
> >
> > - Focus on *what* is needed.
>
> This seems wrong to me. Sorry.
>
> If TLD operators are to be bypassed at this stage, how can the WG get a
> clear understanding of what's needed? I think operators of "important" auth
> servers have to be part of the discussion from the outset. If not, the WG
> may well come up with a solution that busy authoritative servers can't or
> won't deploy.
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Tim Wicinski]

Also

If you feel the chairs are missing some aspect of this, please speak up and
let's make sure those are covered.

thanks
Tim


On Thu, Jul 19, 2018 at 2:10 PM, Brian Haberman 
wrote:

> All,
>  The chairs would like to get the WG discussion started on exploring
> privacy solutions for recursive resolver to/from authoritative server
> exchanges. To start, we want to focus on *use cases and requirements*.
> In our view, the WG needs to consider the:
>
> - User perspective
> - Implementer perspective
> - 2nd-level server operator perspective
> - Recursive resolver operator perspective
>
>  For the time being, we would like to bypass the TLD server operator
> perspective. While we are in this phase of discussion, the chairs would
> like everyone to follow these guidelines:
>
> - Focus on *what* is needed.
> - Avoid *how* to achieve it.
> - Consider both ends of DNS the exchange.
> - Scenarios will frame the discussion.
>
>  The chairs will start a mailing list thread for each of the four
> discussion points. As ideas are presented, we will start aggregating the
> details in a GitHub repo.
>
> Regards,
> Brian & Tim
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Call for Adoption: draft-dickinson-dprive-bcp-op

[Tim Wicinski]

This starts a Call for Adoption for draft-dickinson-dprive-bcp-op

The draft is available here:
https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 3 August 2018

Thanks,
DPRIVE co-chair
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] IETF102 Agenda

[Tim Wicinski]

All

We've uploaded the draft agenda but we think things will be pretty much in
shape.

We also have some first time presenters at the IETF on the Oblivious DNS
draft,
but we know y'all will be most welcoming.

thanks, and see you in Montreal

tim
brian


-
# DNS Privacy Exchange (DPRIVE) WG
## IETF 102, Montreal

* Date: Wednesday, 18 July 2017
* Time: 13:30-15:00 CEST
* Room: Place du Canada

* Chair: Tim Wicinski 
* Chair: Brian Haberman 

* IESG Overlord:  Terry Manderson 

* [DataTracker](https://datatracker.ietf.org/group/dprive/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

### Current Working Group Business

* Some analysis of the RIPE Atlas probe data on DNS-Privacy, Brian Haberman

* [draft-dickinson-dprive-bcp-op](https://datatracker.ietf.
org/doc/draft-dickinson-dprive-bcp-op/)

### New Working Group Business

* [draft-annee-dprive-oblivious-dns](https://datatracker.ietf.
org/doc/draft-annee-dprive-oblivious-dns/)

## Stage 2

* Recursive to Authorative discussion,  Chairs
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] IETF101 Call for Agenda Requests

[Tim Wicinski]

All

The preliminary agenda for IETF101 was released: 
https://datatracker.ietf.org/meeting/101/agenda.html


DPRIVE is slated for Wednesday 21 March, 2018  in the first afternoon 
slot (13:30-15:00)


This is a call for requests for agenda topics.

Additionally, we have been discussing a DPRIVE hackathon table. Sara 
Dickinson and I have been talking about this, and
there is probably something specific shaping up (Sara always knows more, 
we'll have to get with her). Sign up here:


    http://ietf.org/how/runningcode/hackathons/101-hackathon/


We look forward to seeing everyone in London!

thanks
tim

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

[dns-privacy] Draft Minutes from DPRIVE,

[Tim Wicinski]

Paul Hoffman has sent us the draft of the minutes from the DPRIVE 
session.  I've taken a look, and I'm impressed in his capturing of the 
wonderful DKG discussion.


https://www.ietf.org/proceedings/99/minutes/minutes-99-dprive-00.txt

please send any corrections to the chairs

tim
DNS Privacy Exchange (DPRIVE) WG
IETF 99, Prague
Tuesday, 18 July 2017, 09:30-12:00 CEST
Chairs: Tim Wicinski and  Brian Haberman
Minutes taken by Paul Hoffman
Text from the slides is not reproduced here

draft-ietf-dprive-dtls-and-tls-profiles
Give it a Review!
People need to review and comment
Want to get the ADs to remove their DISCUSSes
Stephane Bortzmeyer; Most of the IESG remarks were on details
DHCP was not important in the draft
The draft didn't change a lot
Francis Dupont: Maybe reach out to the various review teams to re-review

draft-ietf-dprive-padding-policy: Alex Mayrhofer
Daniel Kahn Gillmor: Analysis is "what percentage of query/response 
pairs is in the same-size bucket"
Adding random length doesn't improve benefit
Christian Huitema: It's harder to impelement random padding correctly
Daniel: DNScrypt uses a nonce in the query, and he used that in the 
research
Christian: Don't merge the documents
Padding strategy depends on which transport you use
This is find for UDP, but maybe quite different for TCP or 
other transports
Alex: What other transports are in scope?
Christian: Padding also helps protect from DoS
Will send text to the list
Daniel: Keep it as a separate draft
Patches in many clients and servers
Updating resolvers with new defaults is easy
Shane Kerr: This seems like a good policy
Maybe want to hear from crypto folks
Stephane: Document is OK and we should move forward
Will do a review
Tim: this should be Experimental
Need more reviewer
Olafur, DKG, Sara, Christian, Shane, David Lawrence 
agree to review
Wes Hardaker: DNSOP is working on extensions that will change sizes
Brian: Do the slides include how the data was analyzed
Daniel: Only in presentation format
Happy to share the programs used to analyze
Can run the code over datasets from other recursive 
resolvers

draft-huitema-quic-dnsoquic: Christian
Lots of people know what QUIC is
Phill Hallam-Baker: Proposed something like QUIC before QUIC
QUIC lets him have an idempotent server
Can make recursive resolver completely idempotent?
Chistian: We need to have some state for crypto, but can we 
reduce the state needed?
Because this comes in application layer, you can try 
new things more easily
?1: Current way QUIC is specified is that one UDP packet maps to one 
QUIC packet
Proposal to make several UDP packets in one QUIC packet
Ian Swett: Likes the proposal for QUIC
Christian: Has data about current DNS works in here
Ben Schwartz: Wants to be able to multiplex this over a single port
Christian: There are use cases for DNS-over-HTTP-over-QUIC for 
stealth
Flip side is that servers need a full HTTP stack, with 
tradeoffs
Ben: Wants this in parallel, not necessarily in HTTP
Christian: Allow multiple ALPNs,
Alex: Joke about "QUIC over DNS"
Reminds him of encrypted RTP problem from ten years ago
Worried about proliferation of number of transports
?1: Doesn't QUIC seem heavyweight?
Would prefer a simpler protocol that is DNS-specific
Christian: We get implementation experience by working this out
Andrew Sullivan: QUIC is pretty promising for our use cases
Nervous about how this is framed as stub-to-recursive, and 
recursive-to-authoritative
Uncomfortable to make this split
Christian: two reasons for QUIC: privacy and performance
Half of queries to resolvers are from cache
Thus need to think about UDP retransmission for 
responses that take longer
Tradeoff of efficiency and performance
Andrew: Retransmission hurt on the server side as well
Phill: There was a proposal to do a DNS-specific transport
QUIC is becoming new SSH
Few proposals for new crypto protocol
We are going to change the DNS protocol no matter what
The spec for DNS is awful, and doesn't say everything that it 
needs to
Doesn't

[dns-privacy] Administrative: Minute Takers, Jabber Scribe and

[Tim Wicinski]

All

Putting out a call for folks to take minutes at DPRIVE Tuesday Morning, 
as well as Jabber Scribe.   If you can please drop the chairs a note.


Also, if you are presenting, we would like to see slides by Tomorrow 
afternoon.


Thanks and see you all Tuesday Morning bright and early

tim

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

Re: [dns-privacy] Padding policies draft

[Tim Wicinski]

On 6/28/17 12:01 PM, Sara Dickinson wrote:


On 13 Jun 2017, at 08:37, Shane Kerr > wrote:


Alexander and all,

tl;dr Lets move forward with our best guesses now. dkg's
 recommendations seem good, but maybe we can tweak these based on
 expected maximum packet sizes.



I agree, I think an update to the draft referencing dkg’s work is the 
best way to proceed. This seems a good topic for discussion in Prague.




I agree this would be a great discussion topic in Prague.


tim

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

[dns-privacy] Thanks for input on padding-profile draft....now can we talk TLS Profiles?

[Tim Wicinski]

All

We are grateful for the feedback on edns-padding-profile document, The 
Chairs would like to get some more comments on the TLS Profiles draft, 
found here:


https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

There was some good discussion during the meeting in Seoul, but we don't 
have enough discussion on the mailing to move this draft forward.


thanks
tim

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

Re: [dns-privacy] Draft minutes form IETF97

[Tim Wicinski]

The most excellent summary Sara said at the mic was "Hard Fail is Toast".

Also, Paul's memory is correct - Leave Fallback alone.

tim


On 11/25/16 3:58 PM, Paul Hoffman wrote:

On 25 Nov 2016, at 11:38, Warren Kumari wrote:


Hi all,

I have uploaded draft minutes from the DPRIVE meeting in Seoul
Please take a look and send any corrections / clarifications.

https://www.ietf.org/proceedings/97/minutes/minutes-97-dprive-00

Thanks to Suzanne and Dan.


The minutes for the Profiles discussion doesn't reflect the mic
interactions on the open topics that Sara brought up. In specific, there
seemed to be general agreement on leaving the fallback terminology
alone, and on removing hard-fail from the options.

--Paul Hoffman

___
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] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile

[Tim Wicinski]

All,

This document has been in holding pattern while the dns-over-dtls 
document was addressed and moved forward.  Also, the authors were 
waiting to hear from one straggler author (dkg, the secure courtesy 
phone please).  The chairs feel we will use the WGLC as a forcing 
function the latter issue.


This starts a Working Group Last Call for:
   draft-ietf-dprive-dtls-and-tls-profile

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.


This starts a two week Working Group Last Call process, and ends on 20 
October 2016


thanks
tim

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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

[Tim Wicinski]

On 8/31/16 1:54 AM, Tirumaleswar Reddy (tireddy) wrote:

Hi Allison,



Thanks for the review. Please see inline [TR]



*From:*Allison Mankin [mailto:allison.man...@gmail.com]
*Sent:* Wednesday, August 31, 2016 5:36 AM
*To:* Tirumaleswar Reddy (tireddy) 
*Cc:* Warren Kumari ; dns-privacy@ietf.org;
dprive-cha...@tools.ietf.org; draft-ietf-dprive-dnsod...@ietf.org;
Allison Mankin ; John Heidemann 
*Subject:* Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.



My calendar reminds me this is the last day of this WGLC.

Overall comments:

This is a well-written spec.  I'm especially appreciative of how much
the draft has gotten aligned with RFC 7858.  I support its publication
soon as an Experimental.



Three suggestions/concerns:



Abstract and Section 1 -

I'd like to see a note added that the Experiment will be concluded when
the spec is evaluated through an implementation and some testing of the
details.



[TR] I am not sure if this line is required, I don’t see other drafts
with Experimental status adding this line !




WG Chair here.  In conversations with our A-D on this draft, the lack of 
any appearance of an implementation feels that this needs to be spelled 
out - one suggestion would be an "Implementation Section"


https://tools.ietf.org/html/rfc6982


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-03.txt

[Tim Wicinski]

All,

I know everyone wants to work on the Next Thing, but we'd like to get 
some reviews of this draft.  The chairs are hoping to have this in WGLC 
before the next meeting.


thanks
tim


On 7/8/16 6:37 PM, Sara Dickinson wrote:

Hi All,

This is a minor update which adds some additional text to section 9.2 on the 
use of DANE.

Regards

Sara.


On 8 Jul 2016, at 17:35, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange of the IETF.

   Title   : Authentication and (D)TLS Profile for DNS-over-(D)TLS
   Authors : Sara Dickinson
 Daniel Kahn Gillmor
 Tirumaleswar Reddy
Filename: draft-ietf-dprive-dtls-and-tls-profiles-03.txt
Pages   : 21
Date: 2016-07-08

Abstract:
  This document describes how a DNS client can use a domain name to
  authenticate a DNS server that uses Transport Layer Security (TLS)
  and Datagram TLS (DTLS).  Additionally, it defines (D)TLS profiles
  for DNS clients and servers implementing DNS-over-TLS and DNS-over-
  DTLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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



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

Re: [dns-privacy] DPRIVe Agenda requests for Berlin

[Tim Wicinski]

All

Since we never heard anything back from folks about needed face time in 
Berlin, Warren and I have decided to cancel our time slot and give it to 
a more needy working group.


We will both be around in Berlin if anyone feels the need to bend our 
collective ears.


tim

On 5/25/16 7:54 PM, Tim Wicinski wrote:

All

Since the last meeting, the DNS over TLS draft has been published as
RFC7858.  The drafts on DNS over DTLS and the Profiles drafts received
feedback during the last meeting and we are awaiting updates.

The chairs have requested a slot for the upcoming Berlin meeting, though
we feel that currently in a waiting position.  We're asking authors if
they wish for any time for the meeting, and if so to please contact the
chairs, as well as have document updates before 1 June 2016.

The chairs currently are considering returning the meeting slot for
Berlin if there is not enough work to consider.

thanks


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

[dns-privacy] DNS + 0-RTT

[Tim Wicinski]

As many of you are aware, with the TLS1.3 spec, there is some security 
concerns around DNS+TLS1.3 0-RTT.  dkg put together some threat models 
and instead of forwarding some long thread, I figure I would put this 
out there and let Mr. Gilmor lay out his theories.


Daniel, you're it.

tim

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

[dns-privacy] Jabber Scribes and note takes for DPRIVE

[Tim Wicinski]

All

We don't have a long agenda, but we could use a jabber scribe(s) and 
note takes for DPRIVE Wednesday morning @10am.


Please drop us a note if you are able to assist and we would be grateful


thanks
tim

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

Re: [dns-privacy] Spencer Dawkins' Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

[Tim Wicinski]

Shane's explanation on padding is a great summary of the mailing list 
discussion during the document review.


tim
(as DocumentShepherd)

On 3/1/16 5:39 AM, Shane Kerr wrote:

Spencer,

At 2016-02-29 20:38:34 -0800
"Spencer Dawkins"  wrote:

Thanks for producing this draft. I do have one question about this text:

   The PADDING octets SHOULD be set to 0x00.  Other values MAY be used;
   for example, in cases where there is a concern that the padded
   message could be subject to compression before encryption.  PADDING
   octets of any value MUST be accepted in messages received.

I'm not entirely sure I understand the point of "SHOULD be set to 0x00".
I'm not questioning the SHOULD (you explain why choosing another value
would be a good idea, thank you ), but I'm wondering why there's a
normative requirement at all.

I was trying to guess, and one hypothesis was that if the padding is
consistently 0x00, it's less likely to provide a covert channel (or at
least you'd be more likely to notice packets using different padding),
but the security considerations section didn't mention that, so I'm still
lost.

If there's a reason to zero the padding bytes in the uncompressed case, a
sentence of explanation might be useful.


There was a lot of discussion on the list about this very topic,
actually. I'm not sure if it can be reduced to a sentence or two.

IIRC, the idea is that we should recommend some value there to give
guidance for implementors to avoid common mistakes (such as using
uninitialized memory, which might contain left-over values).

Someone did raise the possibility of having a covert channel, but it
was recognized that there are so many places for putting covert data
into DNS that this is not really a concern. For example, one could
simply use any unregistered EDNS(0) option and stick data in there, or
encode it into the QNAME, or put values in the query ID, or...

Putting random data in the padding was considered, but it did not seem
to add any real value beyond zero-padding.

Cheers,

--
Shane "not an editor on the draft" Kerr



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

[dns-privacy] Call for Adoption: draft-dgr-dprive-dtls-and-tls-profiles

[Tim Wicinski]

The chairs realized earlier today that we encouraged this draft to be 
created, but once it was, we forgot to start a formal Call for Adoption. 
 With the feedback already, this document looks ready for adoption and 
being worked on.


This starts a Call for Adoption for draft-dgr-dprive-dtls-and-tls-profiles

The draft is available here: 
https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/


Please review this draft to see if you think it is suitable for adoption 
by DPRIVE, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 26 January 2016

Thanks,
tim wicinski
DPRIVE co-chair

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

[dns-privacy] Working Group Last Call for draft-ietf-dprive-edns0-padding

[Tim Wicinski]

This starts a Working Group Last Call for
draft-ietf-dprive-edns0-padding

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.


This starts a two week Working Group Last Call process, and ends on
8 December 2015

thanks
tim

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

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

[Tim Wicinski]

Alex

Why don't you propose some text, as we have a bandwidth delay product 
with you.


thanks
tim

On 11/17/15 5:30 PM, Alex Mayrhofer wrote:

Hello,

Jumping into this thread late, sorry. Anyways, my proposal:

- I think we should stick with requiring 0x00 padding (I am avoiding the
term 'payload' here for a reason). This would prevent the abuse as a
covert channel, is easily understood and implementable, and should not
have any significant performance impact during creation of a message.

- In the sense of "be conservative what you send, be liberal what to
accept" I'm fine to change to text to require (recommend?) a Responder
to ignore the contents. Which means that a malformed padding will never
(rarely?) trigger an error response. However, my feeling is that we
should still allow a "strict Responder" to indicate an error. That boils
down to text like "a Responder MUST/SHOULD (?) ignore the contents of
Padding" - I'd go for SHOULD,  and subsequently keep the definition to
use FORMERR if a strict Responder wishes to indicate an error

- Further, I understand that TLS level compression is discouraged for
DNS anyways ( I'm not an expert in this field, but that's what I
understood what dkg said in our initial hallway discussion in Praha), so
I'd stick with 0x00. If we find out this is really a problem,  we can
always define a padding with more sophisticated contents which Updates
or Obsoletes this document. Requiring that a Responder ignores the
contents would create forward compatibility on the Responder end.

I'm more than happy to propose text if th WG agrees with the above
summary :-)

Alex
(from mobile, sorry for brevity and typos)



 Stephen Farrell schrieb 



On 17/11/15 01:43, Daniel Kahn Gillmor wrote:
 > On Mon 2015-11-16 16:20:21 -0500 , Stephen Farrell wrote:
 >> I agree that that is clearly the opinion in the TLS WG today. I'm
 >> less sure I agree that's correct - my fear is that it's being driven
 >> maybe too much by browsers and the web, where the conclusion is
 >> valid.
 >
 > Well, certainly for a system-wide (or application-wide) arbitrary DNS
 > client it's the same risk.

Similar but not quite the same. Cookies are the main likely target
of CRIME but a DPRIVE equivalent can only target the (non-inserted)
QNAME (or is there more?), which hasn't quite got the same kind of
sensitivity.

 >  We have no way of knowing how many avenues
 > there are for attackers to be able to make the user make certain DNS
 > requests to their preferred privacy-preserving resolver.

Sure. I would guess the introduction of DPRIVE will change the
attack surface and new attacks will be discovered. (Timing may
well prove a fertile ground I would guess.)

 > And since we expect (D)TLS channels to be kept open and reused, that
 > attacker-controlled data will be touching the same deflate dictionary
 > that the ostensibly private queries are using.  This is the same
 > scenario as CRIME and BREACH, no?

Depends. It is unclear to me why padding doesn't help here,
if applied after compression. (Mind you, at that point I don't
know why one is bothering with compressing;-)

 >
 >>> Any attempt at compression needs to happen at the application layer
 >>> itself with full knowledge of the risks and tradeoffs.
 >>
 >> FWIW, I don't agree with the above, I think it's generalising too
 >> much from the browser use-case.
 >
 > The point here is that if you don't know how the application layer mixes
 > attacker-controlled data with data that needs to be confidential, TLS
 > can't possibly do compression safely.

But what is the application layer for a system wide stub resolver?
Your argument would also imply DNS/DPRIVE can't do compression either.

 > So while i agree with you that there could be (non-browser) applications
 > that clearly never mix any attacker-controlled data with
 > sensitive/private data on the same TLS channel, the only way to know
 > whether you're in such a state is by reasoning about it *at the
 > application layer*, which is why that's where the decisions about
 > compression need to be made.

We don't agree about that. I don't think I've seen a convincing
argument that's the *only* way to know. (E.g. always emitting
fixed size packets in a single write and sending some cover
traffic now and then when there's any compression in play would
also seem to help, no?) But that's off topic for this list I
guess, and may get too complicated before it'd get useful
enough.

 >
 > anyway, i'm glad we agree on the outcome :)

Yep - isn't the entire discussion of compression for DNS
pretty moot anyway? It's not clear to me what compressible
plaintext there is where compression would be a real benefit.

Cheers,
S.


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


___
dns-privacy mailing list

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

[Tim Wicinski]

Hi

The Call for Adoption ended and we have strong consensus to adopt the 
document.


The document is also very close to WGLC, once the padding discussion has 
been sussed out.


Thank you all for your comments and reviews.

tim


On 11/3/15 7:54 AM, Tim Wicinski wrote:


During the meeting on Monday, it was obvious the Working Group wanted to
make this an official EDNS option.  We reached out to the author and
while he is traveling for an extended period of time, he is happy to
work on edits (with a small delay built in, but nothing this impatient
chair finds too onerous).

This starts a Call for Adoption fordraft-mayrhofer-edns0-padding

The draft is available here:
https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 17 November, 2015 12:00 UTC

Thanks,
tim wicinski


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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[Tim Wicinski]

All,

The WGLC has finished, and it appears to be rough consensus on moving 
forward.  I want to touch base with my co-chair and AD on one issue, but 
I will work on the Shepherd write up over the next few days and submit 
it into the pipeline. I plan on mentioning the issues raised about 
waiting for other documents before moving forward in my shepherd notes.


tim


On 10/22/15 2:23 AM, Warren Kumari wrote:

Dear DPRIVE WG,

The authors of draft-ietf-dprive-dns-over-tls-01 have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/

Please review this draft to see if you think it is ready for
publication and send comments to the DPRIVE list, clearly stating your
view.

We have chosen to run this WGLC during the IETF meeting, and have it
end after the meeting. This will allow us use meeting time to discuss
contentious WGLC issues (if any).
This will be a 3 week WGLC, and ends Thu 12-Nov-2015.


To satisfy RFC 6702 ("Promoting Compliance with Intellectual Property
Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-dns-over-tls-01?  If so, has this IPR been disclosed
in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and
5378 for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)




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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[Tim Wicinski]

On 11/13/15 8:22 AM, Paul Hoffman wrote:



Just to be clear: do the chairs read the rough consensus to be that the
draft needs to remove Sections 3.2 and all of Section 4, and move them
to a new document?

--Paul Hoffman


Yes, I do (once I remembered).  I am circling back with the others,  but 
I believe this is the case.


I'm also waiting for the -02 before actioning.

tim

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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[Tim Wicinski]

(as chair)

I don't see the point in holding up this document for the other DTLS 
document(s).   Using the "running code" practice, there is code out here 
which supports dns-over-tls.   The authors of dns-over-dtls do not have 
a plan to implement any solutions at this time.  However, as chair, I've 
reached out and I do believe some of the folks who have implemented the 
current dns-over-tls solution work on a proof of concept of dns-over-dtls.


I'll chat with Warren about this, but I don't see the reasons to hold 
this one for now.


tim

On 11/9/15 11:32 AM, Simon Josefsson wrote:

"Mankin, Allison"  writes:


My two cents is that the authentication profile for TLS and DTLS
should not be the same as a draft with flows.

I reviewed the flows draft before it was submitted (and thank the
authors for responding to initial comments).  Unsurprisingly, the
flows draft is almost entirely made up of flows.  I estimate that many
will have to change in response to DPRIVE WG review/discussion of the
DTLS fragmentation scheme; also, some of them may need to change based
on what is finalized for 1.3 in the TLS WG.  In keeping with other
precedents at IETF, I’d see the flows draft as an informational
document to help implementors/deployers.


I don't think this WG should wait for completion of TLS 1.3.  If you
write drafts the right way, I don't see anything that needs to be
changed moving from TLS 1.2 to TLS 1.3.  Or are you thinking of
mandating TLS >= 1.3 for dprive?

I believe the dprive documents are in reasonable shape, and the only
worrying concern is that the (D)TLS-considerations ought to be
synchronized between DoDTLS and DoTLS.  It appears there is already work
towards fixing that, and once that document is available, there could be
a WG last call on all three documents.  I don't see anything that would
prevent this from happening during the next 0-3 months process-wise.  I
believe that TLS 1.3 will not be finalized within that time-frame.

/Simon



The authentication profile for TLS/DTLS is something we can pull
together now, with some work by the WG, and I’d expect it to be
standards track.  I would not want to delay it for finishing the
detailed engineering on the DTLS draft.

Bottom line: I very much support Sara’s offer to start a stand-alone
document for the authentication profile.  Speaking for the TLS
authors, we’ll be happy to add language pointing ahead to an
authentication profile external to our draft.

Allison

.



On Oct 27, 2015, at 11:12 AM, Tirumaleswar Reddy (tireddy)  
wrote:



From: Sara Dickinson [mailto:s...@sinodun.com ]
Sent: Tuesday, October 27, 2015 7:34 PM
To: Tirumaleswar Reddy (tireddy)
Cc: dns-privacy@ietf.org 
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01


On 27 Oct 2015, at 12:31, Tirumaleswar Reddy (tireddy)
> wrote:


I’m saying I think creating a separate document that specifically
covers authentication for both TLS and DTLS makes most sense to me
and will be clearer for consumers of the documents.

[TR] We can move this Section to
https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00

and that will take care both (D)TLS profile for DNS privacy and
authenticating the server.

I guess this is a decision for the working group since the DTLS
draft is adopted, but the above document isn’t.

[TR] Yes, of course; will do that only after WG feedback and adoption of the 
draft.

-Tiru

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


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



___
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] Fwd: [IANA #878759] General Request for Assignment (dns-parameters - draft-mayrhofer-edns0-padding)

[Tim Wicinski]

All,

The EDNS Option Code for padding (aka  draft-mayrhofer-edns0-padding) 
is '12'


tim
--- Begin Message ---
Dear Tim,

We've registered the following DNS EDNS0 Option Code:

12  Padding Optional[draft-mayrhofer-edns0-padding]

Please see
http://www.iana.org/assignments/dns-parameters/

The reviewer writes, "Status at RFC if Standards Track : Standard.'" If this 
change will be appropriate, could you mention this in the IANA Considerations 
section?

Your third request was just sent to the reviewer today.

Thanks,

Amanda Baber
IANA Senior Specialist
ICANN

On Tue Nov 03 08:10:21 2015, tjw.i...@gmail.com wrote:
> 
> Contact Name:
> Tim Wicinski
> 
> Contact Email:
> tjw.i...@gmail.com
> 
> Type of Assignment:
> New EDNS EDNS0 Option Codes (OPT)
> 
> 
> Registry:
> http://www.iana.org/assignments/dns-parameters/dns-
> parameters.xhtml#dns-parameters-11
> DNS EDNS0 Option Codes (OPT)
> 
> 
> 
> Description:
> new draft being adopted on EDNS Padding
> 
> 
> Additional Info:
> https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/



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

[dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

[Tim Wicinski]

During the meeting on Monday, it was obvious the Working Group wanted to 
make this an official EDNS option.  We reached out to the author and 
while he is traveling for an extended period of time, he is happy to 
work on edits (with a small delay built in, but nothing this impatient 
chair finds too onerous).


This starts a Call for Adoption fordraft-mayrhofer-edns0-padding

The draft is available here:
https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/

Please review this draft to see if you think it is suitable for adoption 
by DPRIVE, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 17 November, 2015 12:00 UTC

Thanks,
tim wicinski

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

Re: [dns-privacy] draft-am-dprive-eval-02

[Tim WIcinski]

(no hats)

With this new version, I think the document is useful and provides a 
solid discussion of how to quantify privacy mechanisms for a DNS 
implementer who is not a security subject matter expert.


tim
On 11/2/15 6:22 PM, Andrew Sullivan wrote:

Despite my comments against the hum at the mic, I have read this
document and think it should certainly be adopted.  I just don't want
Yet Another Meaningless Commitment.  (If you looked before and can't
fact it again, give it a try.  It's much improved.)

A



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

[dns-privacy] Minute Takers and Jabber Scribers

[Tim Wicinski]

Hi

We're looking for Jabber Scribes and Minute takers for the DPRIVE 
meeting monday afternoon.


Drop us a note if you're able to help.

thanks
tim

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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[Tim Wicinski]

Bob

https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

is a working URL

thanks for pointing that out

tim


On 10/22/15 6:59 PM, Bob Harold wrote:


On Thu, Oct 22, 2015 at 5:23 AM, Warren Kumari > wrote:

Dear DPRIVE WG,

The authors of draft-ietf-dprive-dns-over-tls-01 have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/

Please review this draft to see if you think it is ready for
publication and send comments to the DPRIVE list, clearly stating your
view.

We have chosen to run this WGLC during the IETF meeting, and have it
end after the meeting. This will allow us use meeting time to discuss
contentious WGLC issues (if any).
This will be a 3 week WGLC, and ends Thu 12-Nov-2015.


To satisfy RFC 6702 ("Promoting Compliance with Intellectual Property
Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-dns-over-tls-01?  If so, has this IPR been disclosed
in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and
5378 for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)

The URL is not working for me, and I cannot find a working URL.  Is it
just me?

--
Bob Harold



___
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] Draft WG Agenda Published

[Tim Wicinski]

Hi

We've published a draft agenda of the working group. It can be found 
here: https://www.ietf.org/proceedings/93/agenda/agenda-93-dprive


If we missed anyone please let us know.

Also, Don't Forget Your Slides

The Chairs,

---

WG: DNS PRIVate Exchange (dprive)
Meeting:IETF 93, Prague
Location:   Hilton Prague, Karlin I/II
Date:   24 July 2015
Time:   09:00-11:30 CEST
Chairs: Warren Kumari
Tim Wicinski


- Agenda Bashing, Blue Sheets, etc (10 min)

- Working Group Updates

DNS over DTLS, Reddy, 20 min
draft-ietf-dprive-dnsodtls

TLS for DNS, Manckin, 20
draft-ietf-dprive-start-tls-for-dns

Evaluation of Privacy for DNS Private Exchange, Mankin, 10 Mankin
draft-am-dprive-eval


- New Working Group Business
IPsec AUTH_NULL opportunistic DNS, Wouters, 10 min
Demo!

- Wrap Up
Where are we going? Chairs, 10 min

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

[dns-privacy] Last Call for Agenda Time for Prague

[Tim Wicinski]

The deadline for submitting agenda items is July 5th.   If you have any 
last minute items to put on the agenda, please let us know.


thanks
tim

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

[dns-privacy] Fwd: IETF 93 Preliminary Agenda

[Tim Wicinski]

All

The draft IETF agenda has been published, and it has DPRIVE with a 
Friday Morning slot for 2.5 hours.  Now, Warren and I requested a 1.5 
hour slot, but since there were more requests for slots, we can only 
assume they made the best of the situation. Please do take as a sign for 
an hour of speaking.


Also, if you have requests to speak please let your chairs now.  The 
deadline for draft WG agendas is Sunday July 5th.


thanks
tim/warren
---BeginMessage---

The IETF 93 preliminary agenda has been posted.  The final agenda will be 
published on Friday, June 26th, 2015.  

If you would like to request a change to the preliminary agenda, please send a 
message to age...@ietf.org and copy all relevant Area Directors.

Please note the cut-off date for requests to reschedule Working Group sessions 
and BOFs is Wednesday, June 24th, 2015 at UTC 23:59.

https://datatracker.ietf.org/meeting/93/agenda.html
https://datatracker.ietf.org/meeting/93/agenda.txt

Thank you!

IETF Secretariat

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

Re: [dns-privacy] Call for Adoptions on the 3 documents.

[Tim Wicinski]

On 4/23/15 7:11 AM, Ilari Liusvaara wrote:

Also, it occurs to me that if there is NAT with non-sticky behaviour
with UDP DNS (UDP DNS might very well be special-cased), things are not
going to work at all without channel identifier (because the ports
change constantly).

Dunno if such middleboxes exist, or if they exist, how common those
are.


-Ilari


I would think that all the focus on middleboxes in the IETF and the IAB, 
that most middlebox behavior has been identified.



Mark Andrews has done an impressive job document (poor) EDNS compliance
http://users.isc.org/~marka/ts.html - I think such a task around 
middleboxes would be useful


tim

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

Re: [dns-privacy] Draft minutes posted.

[Tim Wicinski]

I've updated the minutes with the changes submitted and pushed them to up.

http://www.ietf.org/proceedings/92/minutes/minutes-92-dprive

tim

On 4/3/15 11:40 AM, Tim Wicinski wrote:


There are here:

http://www.ietf.org/proceedings/92/minutes/minutes-92-dprive

tim


On 4/3/15 11:24 PM, Stephane Bortzmeyer wrote:

On Wed, Apr 01, 2015 at 06:11:19PM -0400,
  Warren Kumari war...@kumari.net wrote
  a message of 20 lines which said:


Draft minutes for DPRIVE have been posted.


Posted where?

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



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

Re: [dns-privacy] Draft minutes posted.

[Tim Wicinski]

There are here:

http://www.ietf.org/proceedings/92/minutes/minutes-92-dprive

tim


On 4/3/15 11:24 PM, Stephane Bortzmeyer wrote:

On Wed, Apr 01, 2015 at 06:11:19PM -0400,
  Warren Kumari war...@kumari.net wrote
  a message of 20 lines which said:


Draft minutes for DPRIVE have been posted.


Posted where?

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



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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review.

[Tim Wicinski]

I agree with Warren that there is solid consensus.

tim

(I'm traveling as well the next two weeks, working with a slight delay)


On 3/9/15 2:18 PM, Warren Kumari wrote:

Oh, I should mention that I'm at IEEE in Berlin at the moment, and so
I haven't confirmed this call with my co-chair.  It's possible he has
a different view here, in which case he and I will duke it out
offline, or on the stage in Dallas.

W


On Mon, Mar 9, 2015 at 10:14 AM, Warren Kumari war...@kumari.net wrote:

Thank you everyone who participated.

In my opinion there is consensus for publishing this document (after
Stephane has folded in all comments[0]).

Many of the comments were about the contents without clear I approve
of this document statements, but in my view the tone was positive.


W
[0]: I apologize, I have not checked the version in git to see if
*all* comments have already been addressed.


On Mon, Feb 23, 2015 at 5:36 PM, Warren Kumari war...@kumari.net wrote:

Dear DPRIVE WG,

The authors of draft-ietf-dprive-problem-statement have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/

This document was discussed at the DPRIVE meeting at IETF91 - some
notes here: http://tools.ietf.org/wg/dprive/minutes?item=minutes-91-dprive.html

The document has also been worked on in GitHub, here:
https://github.com/bortzmeyer/my-IETF-work
It has also received a fair bit of on-list discussion.

Please review this draft to see if you think it is ready for
publication and send comments to the list, clearly stating your view.
Even if you previously expressed support for the document (e.g during
adoption), please respond to the WGLC showing that you still support
it.

This WGLC ends Mon 09-Mar-2015.


In addition, to satisfy RFC 6702 (Promoting Compliance with
Intellectual Property Rights (IPR)):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-problem-statement?  If so, has this IPR been
disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879,
3669, and 5378 for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)


--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf




--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf






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

Re: [dns-privacy] (re-)identifying from sets of queries (was Re: Start of WGLC for draft-ietf-dprive-problem-statement - please review.)

[Tim Wicinski]

On 2/27/15 10:46 AM, Stephane Bortzmeyer wrote:

On Fri, Feb 27, 2015 at 10:38:53AM -0500,
  Phillip Hallam-Baker i...@hallambaker.com wrote
  a message of 78 lines which said:


BTW are we planning to IETF last call this doc and publish as an RFC
or is this internal only?


The charter is silent about it. My goal is certainly to have this
document published as a RFC, we need clear documentation of privacy
properties of IETF protocols, like RFC 6973 says.

Now, whether or not an IETF Last Call is necessary, I don't know.




Warren and I have discussed this, though not recently. The consensus (from the group and 
from ADs) is published as an RFC.  I know a few have felt the IETF are awash in 
problem statements.

tim

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

Re: [dns-privacy] DPRIVE next steps

[Tim Wicinski]

On 11/24/14 5:26 PM, Melinda Shore wrote:

On 11/24/14 1:05 PM, Tim Wicinski wrote:

I did not say a requirements document. I said the Problem Statement, and
evaluation metrics.  Neither are requirements.


I've been concerned about the proliferation of problem statement
documents (and use case documents, but less about requirements
documents).  They introduce delay into the process.  Sometimes that
delay is necessary or helpful but often it isn't.  The situations
in which problem statement documents are helpful include those
where the working group charter is unacceptably fuzzy or where
there's a lot of contention for ownership of solutions.  I'm
not sure that I see that a problem statement document will be
particularly helpful for moving this work forward.  One thing
that might minimize the process damage from having one is agreeing
ahead of time that a dprive problem statement will *not* be
published as an RFC.


Melinda,

I know that when the initial charter discussion was taking place, there 
was careful discussion to focus on a specific problem space, and not 
letting things get out of hand.


One of the ways the ADs were going to do this was by a problem 
statement.  I think if you poll the IESG you will get a solid percentage 
of them that are following this group closely.


Also, the chairs were not interested in letting the problem statement 
drag along.  We did feel everyone wants to work on their answers and 
very few folks appear to place serious eyes on it.


If the group feels that the problem statement should never leave be 
published, and the ADs are fine with that, we can do that.  However, I 
feel we can have a WGLC for the problem statement on or near 1/1/2015 
and be done.


The chairs had no desires to spend time on working on requirement 
documents or use case documents. That is what the wiki is for.


Also, if people want to work on their solutions, they are more than 
welcome to. They do not need to have drafts adopted to continue studying.


Thanks
tim

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

[dns-privacy] DPRIVE next steps

[Tim Wicinski]

(I was waiting to confirm the wording with Warren, but I failed to 
remember he was away last week).


Coming out of IETF91, we saw good discussion around the problem 
statement; the beginnings of a discussion around evaluation metrics; and 
several different solutions searching for the appropriate problem.


The chairs feel that it is too early to address the solution documents. 
 We are looking to see solid work done on the Problem Statement.  It 
needs some strong editorial work to bring it front and center. It should 
be possible to generate that into a Working Group Last Call before Dallas.


Then we would like to see some action on the evaluation document. I know 
when I spoke with Allison they were having some resource scheduling 
conflicts, and I had offered to assist with the document if there was a 
working outline. Perhaps others will feel so inclined.


While I think we all like to work on solution space, we need to move the 
first part of the work forward.


thanks
tim

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