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

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 01 Aug 2018 07:47:13 -0700

So, with padding policy now in the RFC Editor's queue, it would be grand 
if the WG could put more energy into resolver-to-authoritative. The 
chairs started a bunch of topic-specific threads that got a bit of 
response, but then silence fell. I care a lot about this, and hope 
others do as well.

--Paul Hoffman

---

From: "A. Schulze" <[email-masked]>
Date: Wed, 1 Aug 2018 18:09:44 +0200

Am 01.08.2018 um 16:47 schrieb Paul Hoffman:
> So, with padding policy now in the RFC Editor's queue, it would be grand if the WG could put more energy into resolver-to-authoritative. The chairs started a bunch of topic-specific threads that got a bit of response, but then silence fell. I care a lot about this, and hope others do as well.

Hello,

I also care about that topic. I see two independent challenges:
1. establish a authenticated secure channel between resolver and authoritative
2. resolver must detect, use and cache this channel

There was some work at IETF101+102 Hackathon (1) addressing point 1.
It's implementing the DNSSEC-Chain-Extension. But not more then prototyping...

Andreas

(1) https://github.com/IETF-Hackathon/ietf101-project-presentations/blob/master/DNS_DOH_presentation.pdf, Page 6

---

From: Brian Haberman <[email-masked]>
Date: Fri, 31 Aug 2018 10:22:10 -0400

All,
     The conversations around this topic have gone silent. Are there
other perspectives that we need to understand?

     Tim and I are discussing an interim in September to get some
focused discussion on requirements, issues, and gating factors. Please
continue to raise items that you think warrant consideration for the
recursive to authoritative privacy work item. Without content, it won't
make much sense to hold an interim.

Regards,
Brian

On 7/19/18 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>