Subject: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

From: Patrick McManus <[email-masked]>
Date: Tue, 29 Oct 2019 10:19:39 -0600

I appreciate the authors kicking off the effort with this draft that
proposes phase 2 requirements.

On a couple of occasions the draft makes creates requirements wrt law
enforcement compliance. e.g. "comply with locally relevant law enforcement
[..] (high priority)".

While RFC 2804 says
"The IETF has decided not to consider requirements for wiretapping as part
of the process for creating and maintaining IETF standards.". There is
clear guidance for avoiding this requirement in any document designed to
create an expectation of privacy from end to end, before it is adopted by a
WG.

-Patrick

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 29 Oct 2019 16:47:41 +0000

+1

________________________________________
From: dns-privacy <[email-masked]> on behalf of Patrick McManus <[email-masked]>
Sent: Tuesday, October 29, 2019 12:19 PM
To: DNS Privacy Working Group
Subject: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

I appreciate the authors kicking off the effort with this draft that proposes phase 2 requirements.

On a couple of occasions the draft makes creates requirements wrt law enforcement compliance. e.g. "comply with locally relevant law enforcement [..] (high priority)"..

While RFC 2804 says
"The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards.". There is clear guidance for avoiding this requirement in any document designed to create an expectation of privacy from end to end, before it is adopted by a WG.

-Patrick

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2019 15:07:07 -0400

>proposes phase 2 requirements.

As do I, but it still needs a lot of work.

One thing that would help me a lot is matching up the features with
what problem they're supposed to solve.

* Keeping specific people from seeing your query stream (e.g., your ISP)
* Keeping random snoopers from seeing your query stream
* The above for particular parts of your query stream, e.g. 2LDs
* Being sure you're talking to the right server (the certificate issue)
* Other stuff?

Depending on what your goal is, you might mix and match other techniques
like local mirroring of zones, at least ones that aren't too huge.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:01:20 +0000

How does this change suit you? https://github.com/alex-nicat/ietf-dprive-phase2-requirements/pull/9/commits/7662d32616c4b1bf8da43f782974cf9dcf9aeebc

s/ and to comply with locally relevant law enforcement or regulatory requirements/ and to comply with locally relevant legal requirements

or should it change to “locally relevant requirements”?

Jason

From: dns-privacy <[email-masked]> on behalf of Patrick McManus <[email-masked]>
Date: Tuesday, October 29, 2019 at 12:20 PM
To: DNS Privacy Working Group <[email-masked]>
Subject: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

While RFC 2804 says

-Patrick

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:04:44 +0000

Can you be more specific on your bullet list? What I mean is that this list seems covered in "Threat Model and Problem Statement" so I am wondering what gaps there may be there, if any. Perhaps just ensuring you are talking to the correct/intended server (the cert issue you note)?

Jason

On 10/29/19, 3:08 PM, "dns-privacy on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    _______________________________________________
    dns-privacy mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "John R Levine" <[email-masked]>
Date: 30 Oct 2019 14:27:04 -0400

> Can you be more specific on your bullet list? What I mean is that this 
> list seems covered in "Threat Model and Problem Statement" so I am 
> wondering what gaps there may be there, if any. Perhaps just ensuring 
> you are talking to the correct/intended server (the cert issue you 
> note)?

It seems to me there's a bunch of threats that don't overlap very much, 
and what you do depends on what threats you think are important, e.g.. how 
much you care who you're talking to vs. who might be observing on the 
side.  Tossing all the threats into one pot and trying to solve them all 
at the same time doesn't strike me as a path to success.

I don't think I have any new threats there, but I do think it's worth 
separating them into groups that can be addressed by particular 
techniques.

>    like local mirroring of zones, at least ones that aren't too huge.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly