Subject: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2021-01-27

From: IESG Secretary <[email-masked]>
Date: Tue, 12 Jan 2021 13:44:30 -0800

The DNS PRIVate Exchange (dprive) WG will hold
a virtual interim meeting on 2021-01-27 from 18:00 to 20:00 UTC.

Agenda:
Administrivia - 10 minutes
Opportunistic Encryption (draft-pp-recursive-authoritative-opportunistic) - 20 minutes
Opportunistic encryption from resolvers perspective - 40 minutes
Opportunistic encryption from authoritative perspective - 40 minutes
Wrap-up - 10 minutes

DPRIVE Jan 2020 Interim
Hosted by DPRIVE Working Group

https://ietf.webex.com/ietf/j.php?MTID=m93424bce1283301bf925e9b68826f7c1
Wednesday, Jan 27, 2021 1:00 pm | 2 hours | (UTC-05:00) Eastern Time (US
& Canada)
Meeting number: 178 706 0933
Password: hmRMWcUA758

Join by video system
Dial [email-masked]
You can also dial 173.243.2.68 and enter your meeting number.

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 178 706 0933

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=m93424bce1283301bf925e9b68826f7c1

---

From: Brian Haberman <[email-masked]>
Date: Thu, 21 Jan 2021 08:50:02 -0500

Hi all,
     As noted in the agenda below, we will have three primary
discussions. The chairs asked Paul to go over the latest version of the
opportunistic encryption draft for recursive to authoritative exchanges.
After that, we would like to focus on how such an approach will work
from the recursive resolver's perspective followed by how such an
approach will work from the authoritative server's perspective.

     The last two discussions will be free form. There will be no slides
as this should be a collaborative discussion. Please review Paul's draft
and come with your good ideas and feedback on its impact on the two ends
of the DNS exchange.

     The chairs would also like to solicit volunteers to keep minutes so
that we have a good record of any decisions and action items from the
meeting.

Regards,
Brian

On 1/12/21 4:44 PM, IESG Secretary wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 25 Jan 2021 16:47:18 -0500

The agenda and the slides for the opportunistic encryption draft have
been posted to the meeting materials page for the upcoming interim.

https://datatracker.ietf.org/meeting/interim-2021-dprive-01/session/dprive

Regards,
Brian

---

From: Jacques Latour <[email-masked]>
Date: Tue, 26 Jan 2021 21:07:16 +0000

>> Opportunistic encryption from authoritative perspective

I was hoping to make it tomorrow but in case I don't, here's my feedback.   I want to avoid a DoH here by voicing my concerns too late where this proposal end up a MUST instead of SHOULD to support encryption on authoritative.  I'm pretty sure that there are many people that are silent on this proposal, or simply don't have visibility.  I think encryption at this level is not addressing the root problem to preserve client privacy.  We should look at how clients could round robin their queries to resolvers via DoH, DoT, even D-over-Jabber 😉, there are 10000s of open resolvers, anonymity can be achieved for sure to an authoritative server. 

It’s not because we can we should, and I don't see how this level of encryption will enhance the end client’s privacy posture. If you don’t trust the resolver, pick one you trust, because if you run your own, people can see the which authoritative you’re querying…

In reading through the draft that there’s going to be unacceptable induced latency on resolver for TLDs and authoritative domains that are (would) not ADoT enabled.

Jacques

-----Original Message-----
From: dns-privacy <[email-masked]> On Behalf Of Brian Haberman
Sent: January 25, 2021 4:47 PM
To: [email-masked]
Subject: [EXT] Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2021-01-27

Regards,
Brian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jan 2021 00:22:38 +0000

On Jan 26, 2021, at 1:07 PM, Jacques Latour <[email-masked]> wrote:
> I was hoping to make it tomorrow but in case I don't, here's my feedback.   I want to avoid a DoH here by voicing my concerns too late where this proposal end up a MUST instead of SHOULD to support encryption on authoritative.  

Just to be clear, there is nothing in the current draft that even suggests "SHOULD". There are many reasons why a particular authoritative server operator would not want to add ADoT.

> I'm pretty sure that there are many people that are silent on this proposal, or simply don't have visibility.  I think encryption at this level is not addressing the root problem to preserve client privacy.  

Quite true, but that is not even listed as part of the use case.

> We should look at how clients could round robin their queries to resolvers via DoH, DoT, even D-over-Jabber 😉, there are 10000s of open resolvers, anonymity can be achieved for sure to an authoritative server. 

True. If the use case is "a user wants to be assured of more anonymity", this proposal is not good for that.

> It’s not because we can we should, and I don't see how this level of encryption will enhance the end client’s privacy posture.

It will slightly but unpredictably help the privacy of users of a resolver. It helps the privacy of the users in aggregate, but certainly not in the specific.

> If you don’t trust the resolver, pick one you trust, because if you run your own, people can see the which authoritative you’re querying…

I don't see how "pick one you trust" helps the privacy, given that the resolver still needs to talk to authoritative servers.

> In reading through the draft that there’s going to be unacceptable induced latency on resolver for TLDs and authoritative domains that are (would) not ADoT enabled.

If a resolver decides that the increased latency is unacceptable, then it won't use the protocol. However, that should be an operational decision for the resolver operators to make, not forced on them by reluctant authoritative server operators. An authoritative operator can decide not to support ADoT if they don't want resolvers using it with their service, of course, but not for the whole DNS.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Tue, 26 Jan 2021 16:36:34 -0800

On Tue, Jan 26, 2021 at 4:23 PM Paul Hoffman <[email-masked]> wrote:

> > In reading through the draft that there’s going to be unacceptable
> induced latency on resolver for TLDs and authoritative domains that are
> (would) not ADoT enabled.
>
> If a resolver decides that the increased latency is unacceptable, then it
> won't use the protocol. However, that should be an operational decision for
> the resolver operators to make, not forced on them by reluctant
> authoritative server operators. An authoritative operator can decide not to
> support ADoT if they don't want resolvers using it with their service, of
> course, but not for the whole DNS.
>

I won't be able to attend the interim, but I think the proposal looks very
reasonable. The latency / cpu penalty seems almost overstated, since I
expect most of these transactions will happen over persistent connections.

thanks,
Rob