Subject: Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

From: "Henderson, Karl" <[email-masked]>
Date: Thu, 29 Nov 2018 18:03:12 +0000

As a representative of a large root and tld operator, I’d like to request ~10 minutes (in case my comments spark discussion) on the dprive interim agenda in order to make some observations and recommendations regarding privacy between the recursive and authoritative name servers.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 30 Nov 2018 03:57:49 +0900

And as an operator of recursive and authoritative servers, I’d very much like us all to listen to what Karl is going to say.  I suspect Stéphane will be interested as well.  :-)
    
                -Bill

> On Nov 30, 2018, at 03:03, Henderson, Karl <KHenderson=[email-masked]> wrote:
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 10:14:42 -0500 (EST)

> And as an operator of recursive and authoritative servers, I’d very much like us all to listen to what Karl is going to say.  I suspect Stéphane will be interested as well.  :-)

Why wait ? Let's hear what he has to say on the list beforehand, so we
can discuss on the list and if needed during the interim. It would be
a better use of our voice-to-voice time.

Paul

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Nov 2018 15:40:51 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul Wouters
> Sent: Friday, November 30, 2018 10:15 AM
> To: Bill Woodcock <[email-masked]>
> Cc: [email-masked]; Henderson, Karl
> <KHenderson=[email-masked]>
> Subject: [EXTERNAL] Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG
> Virtual Meeting: 2018-12-10
>
> > And as an operator of recursive and authoritative servers, I’d very
> > much like us all to listen to what Karl is going to say.  I suspect
> > Stéphane will be interested as well.  :-)
>
> Why wait ? Let's hear what he has to say on the list beforehand, so we can
> discuss on the list and if needed during the interim. It would be a better
> use of our voice-to-voice time.

Here's what's been shared with the list already:

https://mailarchive.ietf.org/arch/msg/dns-privacy/YHAa2kLGcKHMPEjkJQpQJ_Amfeo

There haven't been any replies.

Scott

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Nov 2018 15:46:46 +0000

Hiya,

> https://mailarchive.ietf.org/arch/msg/dns-privacy/YHAa2kLGcKHMPEjkJQpQJ_Amfeo

Thanks for that. I fully agree that analysing the risks
here is needed. I didn't really understand this bit of
that mail though:

>> These points suggest a need for a profile of encryption
>> standards that sufficiently mitigates operational risk
>> to authoritative name servers while protecting end user
>> privacy.

Can you (or Karl I guess) explain what's meant there?

Cheers,
S.

---

From: "Henderson, Karl" <[email-masked]>
Date: Fri, 30 Nov 2018 16:06:53 +0000

Hi Stephen,

I'm suggesting something like RFC8310 but between the recursive and the authoritative. 

Regards,
Karl

On 11/30/18, 10:46 AM, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    

    Cheers,
    S.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 11:14:50 -0500 (EST)

> There haven't been any replies.

I see a number of replies listed on the page you cite above? :)

Doing encryption on an authoritative server is tricky. It was one of
the arguments against encrypting DNS with DNSSEC, and against dnscurve.

times have changed, and it deserves another look, but some note that says
"If running out of resources, drop the encryption and serve DNS data in
the clear might be needed". Ideally in a way that querying clients that
want to insist on privacy can bail out instead of receiving cleartext.

Paul

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Nov 2018 16:56:26 +0000

> From: Paul Wouters <[email-masked]>
> Sent: Friday, November 30, 2018 11:15 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]' <[email-masked]>; [email-masked]' <dns-
> [email-masked]>; 'KHenderson=[email-masked]'
> Subject: [EXTERNAL] RE: [dns-privacy] DNS PRIVate Exchange (dprive) WG
> >> Why wait ? Let's hear what he has to say on the list beforehand, so
> >> we can discuss on the list and if needed during the interim. It would
> >> be a better use of our voice-to-voice time.
> >

Replies with the same subject, yes, but there's been no discussion of the content of Karl's note. Anyway...

> Doing encryption on an authoritative server is tricky. It was one of the
> arguments against encrypting DNS with DNSSEC, and against dnscurve.
>

Possibly, but it may also be worth discussing how to avoid getting into resource exhaustion situations in the first place. Do you have any thoughts on Karl's "need for a profile of encryption standards" comment?

Scott

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 12:33:51 -0500 (EST)

> Possibly, but it may also be worth discussing how to avoid getting into resource exhaustion situations in the first place. Do you have any thoughts on Karl's "need for a profile of encryption stand…

I am not sure I see a need for a different TLS/DTLS profile compared to
regular (web) based (D)TLS connections. What do you or Karl think would
be different?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Nov 2018 18:22:34 +0000

> regular (web) based (D)TLS connections. What do you or Karl think would

(D)TLS is not the only option. Using message security instead of connection security would eliminate the need for keeping TCP and crypto state on the server, and could maybe reduce the amount of CPU usage as well.

--Paul Hoffman

---

From: "Henderson, Karl" <[email-masked]>
Date: Fri, 30 Nov 2018 19:13:46 +0000

Hi Paul,

The attack vectors and operational concerns are different for communication between the recursive-to-authoritative than for communication between the stub-to-recursive. For instance, a stub will typically communicate with one or two recursive resolvers while recursive resolvers may communicate with many authoritative resolvers - thus changing the nature of persistent TLS connections for this communication path.

The authors of [RFC8310] recognized this difference and highlight it in the Introduction section with this statement:

"The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application was out of scope for the DNS PRIVate Exchange (dprive) Working Group charter at the time this document was published."

Regards,
Karl

On 11/30/18, 12:34 PM, "Paul Wouters" <[email-masked]> wrote:

    
    
    Paul