Subject: [Add] FW: New Version Notification for draft-hal-adot-operational-considerations-00.txt

From: "Henderson, Karl" <[email-masked]>
Date: Mon, 8 Jul 2019 18:57:04 +0000

First version of a proposal for Authoritative DNS over TLS Operational Considerations. The authors welcome review and feedback.

Regards,
Karl Henderson
Sr. Researcher
Verisign Labs

On 7/8/19, 2:52 PM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-hal-adot-operational-considerations-00.txt
    has been successfully submitted by Karl Henderson and posted to the
    IETF repository.
    
    Name:		draft-hal-adot-operational-considerations
    Revision:	00
    Title:		Authoritative DNS-over-TLS Operational Considerations
    Document date:	2019-07-08
    Group:		Individual Submission
    Pages:		12
    URL:            https://www.ietf.org/internet-drafts/draft-hal-adot-operational-considerations-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/
    Htmlized:       https://tools.ietf.org/html/draft-hal-adot-operational-considerations-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-hal-adot-operational-considerations

    Abstract:
       DNS over TLS (DoT) has been gaining attention, primarily as a means
       of communication between stub resolvers and recursive resolvers.
       There have also been discussions and experiments involving the use of
       DoT to communicate with authoritative nameservers (Authoritative DNS
       over TLS or "ADoT"), including communication between recursive and
       authoritative resolvers.  However, we have identified a number of
       operational concerns with ADoT.  These operational concerns need to
       be addressed prior to ADoT's deployment at scale by DNS operators in
       order to maintain the stability and resilience of the global DNS.
       The document also provides some suggested next steps to advance the
       operator community's understanding of ADoT's operational impact.

    
    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.
    
    The IETF Secretariat

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Jul 2019 20:39:23 +0100

Hiya,

On 08/07/2019 19:57, Henderson, Karl wrote:
> First version of a proposal for Authoritative DNS over TLS
> Operational Considerations. The authors welcome review and feedback.

A few comments:

- I'm not clear what there is related to applications
doing DNS. Calling for detailed and thorough exploration
of the effects of turning on TLS between recursive and
authoritative servers makes perfect sense and is something
that has been absolutely uncontroversial in the dprive
WG, which is already chartered to look at exactly that.

- Reading the draft I get the strong impression that
the authors don't like DNS/TLS in any form. ISTM a
good/fair/balanced analysis would not leave such an
impression. I assume the authors do agree there are,
after all, some benefits to turning on TLS as well.
Is that correct? If so, why is there no mention of
that side of the coin at all?

- draft-green again? Sigh. If you want to re-run
that fiasco, then sure, if we must, I'm willing to
try help kill that zombie bad idea again if necessary,
but do any of us really think going there would be
a productive use of time and energy?

At a higher level, I had hoped we might have moved
on towards more objective analyses by now. This draft
doesn't appear to me to be a step in that direction.

Cheers,
S.

> 
> Regards, Karl Henderson Sr. Researcher Verisign Labs
> 
> 
> A new version of I-D,
> draft-hal-adot-operational-considerations-00.txt has been
> successfully submitted by Karl Henderson and posted to the IETF
> repository.
> 
> Name:		draft-hal-adot-operational-considerations Revision:	00 Title:
> Authoritative DNS-over-TLS Operational Considerations Document date:
> 2019-07-08 Group:		Individual Submission Pages:		12 URL:
> https://www.ietf.org/internet-drafts/draft-hal-adot-operational-considerations-00.txt
>
> 
Status:
https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/
> Htmlized:
> https://tools.ietf.org/html/draft-hal-adot-operational-considerations-00
>
> 
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hal-adot-operational-considerations
> 
> 
> Abstract: DNS over TLS (DoT) has been gaining attention, primarily as
> a means of communication between stub resolvers and recursive
> resolvers. There have also been discussions and experiments involving
> the use of DoT to communicate with authoritative nameservers
> (Authoritative DNS over TLS or "ADoT"), including communication
> between recursive and authoritative resolvers.  However, we have
> identified a number of operational concerns with ADoT.  These
> operational concerns need to be addressed prior to ADoT's deployment
> at scale by DNS operators in order to maintain the stability and
> resilience of the global DNS. The document also provides some
> suggested next steps to advance the operator community's
> understanding of ADoT's operational impact.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 8 Jul 2019 22:30:33 +0000

On 7/8/19, 3:40 PM, "Add on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:
>  Reading the draft I get the strong impression that
    the authors don't like DNS/TLS in any form. 

[JL] You've either misread the draft or we need to make updates in the -01 to fix this perception. The authors are in fact not opposed to DoT, and are endeavoring to sort out all the operational issues that need to be sorted to do DoT between a recursive and authoritative server - at scale. As you might imagine, auth operators such as TLD operators will be very careful in testing and deploying DoT support and we're focused on how to make progress on this front. And such a deployment needs to IMO be undertaken with clear eyes and focusing on all the possible risks and barriers to scaling up and operating reliably. 

> ISTM a

[JL] Perhaps you believe there's still an argument taking place when the argument in favor of encryption has already been won and we’re down to implementation? The authors don’t believe deploying encrypted DNS is in debate - it is going to happen. This is around how to get authoritative operators to do so successfully, which means identifying all the technical/operational risks and developing approaches to measure, monitor, and control for or mitigate them. 
    
>  draft-green again? Sigh. If you want to re-run

[JL] IMO your sarcasm isn't particularly constructive here. The section that it is mentioned in pertains to operational monitoring and we merely list a few solutions discussed in the community. We certainly meant no offense. Sounds like you may be a bit closer to that issue and might have some brief feedback as to why that 1st bullet should be removed. We are perhaps not as expert as you on this subject (or Russ or Ralph, etc.) so would appreciate any thoughts you may wish to share.

[JL] I'm sorry you feel that way - this is not the intention. Perhaps seeing what I stated above, that DNS encryption is not in debate and this is about starting a conversation with operations folks about how to get it done at scale, might change your perception and assumptions about this draft? If not then I suppose we'll need to consider adding some more explicit text about that.

Thx
JL

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Jul 2019 23:48:01 +0100

Hiya,

On 08/07/2019 23:30, Livingood, Jason wrote:
> On 7/8/19, 3:40 PM, "Add on behalf of Stephen Farrell"
> <[email-masked] on behalf of [email-masked]> wrote:
> [JL] You've either misread the draft or we need to make updates in
> the -01 to fix this perception. The authors are in fact not opposed
> to DoT, and are endeavoring to sort out all the operational issues
> that need to be sorted to do DoT between a recursive and
> authoritative server - at scale. As you might imagine, auth operators
> such as TLD operators will be very careful in testing and deploying
> DoT support and we're focused on how to make progress on this front.
> And such a deployment needs to IMO be undertaken with clear eyes and
> focusing on all the possible risks and barriers to scaling up and
> operating reliably.

Ok, maybe the draft-green reference (see below) hit too sore
a sore-point but I'd expected to see e.g. some consideration
that authoritative servers might (or might not) prefer that
not all accesses to the names they serve end up in passive DNS
databases, and that they might prefer their answers not be
as easily modified en-route if there is a feasible way to get
to use of TLS at scale (and presumably if they're not doing
DNSSEC).

I mean, if there's no benefit in turning it on, they just
won't, and there won't be any new problem. If they do turn it
on, presumably that'd be for some positive reason and not just
in reaction to some kind of peer pressure.

> 
>> ISTM a
> good/fair/balanced analysis would not leave such an impression. I
> assume the authors do agree there are, after all, some benefits to
> turning on TLS as well. Is that correct? If so, why is there no
> mention of that side of the coin at all?
> 
> [JL] Perhaps you believe there's still an argument taking place when
> the argument in favor of encryption has already been won and we’re
> down to implementation? The authors don’t believe deploying encrypted
> DNS is in debate - it is going to happen. This is around how to get
> authoritative operators to do so successfully, which means
> identifying all the technical/operational risks and developing
> approaches to measure, monitor, and control for or mitigate them.

Again, being careful ahead of time for recursive to authoritative
has been assumed by everyone involved in dprive with whom I've
spoken at least. And that makes total sense.

> that fiasco, then sure, if we must, I'm willing to try help kill that
> zombie bad idea again if necessary, but do any of us really think
> going there would be a productive use of time and energy?
> 
> [JL] IMO your sarcasm isn't particularly constructive here. 

I wasn't being sarcastic, I mean every word literally. Which is
sad, but draft-green and associated things caused about 2 years
of major angst and kerfuffle in the TLS WG and is the cause of
a sorta rift between the IETF and ETSI (who rubber-stamped the
proposal rejected by TLS and then called that eTLS), so this is
a really bad reference to include. And draft-green was all about
weakening TLS. Honestly, if you can get out another rev before
the cutoff that omitted that, I suspect you'd save you and us
all some time.

> The
> section that it is mentioned in pertains to operational monitoring
> and we merely list a few solutions discussed in the community. We
> certainly meant no offense. Sounds like you may be a bit closer to
> that issue and might have some brief feedback as to why that 1st
> bullet should be removed. We are perhaps not as expert as you on this
> subject (or Russ or Ralph, etc.) so would appreciate any thoughts you
> may wish to share.
> 
> 
> on towards more objective analyses by now. This draft doesn't appear
> to me to be a step in that direction.
> 
> [JL] I'm sorry you feel that way - this is not the intention. Perhaps
> seeing what I stated above, that DNS encryption is not in debate and
> this is about starting a conversation with operations folks about how
> to get it done at scale, might change your perception and assumptions
> about this draft? If not then I suppose we'll need to consider adding
> some more explicit text about that.

I do think some consideration of the benefits helps to evaluate the
costs, yes.

And apologies if I've over-reacted to the draft-green reference, but
my interpretation of that is that it was entirely about debating the
core design of TLS, and weakening that.

Cheers,
S.

> Thx JL

---

From: Michael Sinatra <[email-masked]>
Date: Mon, 8 Jul 2019 18:29:10 -0700

Howdy,

>> focusing on all the possible risks and barriers to scaling up and

For the most part, as an authoritative server operator, I found the
draft to be useful and informative.  But I do agree with Stephen on two
counts: First, parts of the draft, notably section 1.1, tend to be
overly dismissive of the benefits of ADoT in their tone.  That section
appears to come to the conclusion that there are limited benefits to
ADoT versus recursive DoT (rDoT?) or other forms of encryption.  A
counter example is recursive resolvers running on home networks, where
the customer can be identified by the recursive server making the
queries.  EDNS(0) Client Subnet is another, as identified by the draft.
 Although Section 1.1 seems to acknowledge that the jury is still out,
parts of it are written *as though* a conclusion has already been achieved.

Perhaps an additional avenue for study is to examine the various
use-cases and analyze the risks and benefits of DNS encryption.

[snip]

> the cutoff that omitted that, I suspect you'd save you and us

The second agreement I have is that I'd like not to see static D-H given
much (if any) consideration in the doc.  Since the audience is DNS
server operators, I'd rather see considerations for instrumenting the
*servers* (recursive and/or authoritative) so that monitoring
information can be *securely* transmitted and analyzed.

I didn't participate in the debate around draft-green, but I spent some
time several months ago reading the TLS WG mailing list archives (and I
can speculate that it was MUCH easier to spend 1-2 hours reading mail
archives than to spend 1-2 years actually participating in the debate),
and I'd like to believe that the questions are settled and that we
probably don't want to re-open them.  Put differently, since we're
talking about DNS-over-*TLS*, then we should trust the TLS WG to have
done the right thing consensus-wise and build upon their work rather
than re-inspecting it (or giving the appearance that we want to do so).
 And I do think there are other ways of solving the monitoring
consideration (e.g. logging or post-decryption dnstap-like
functionality) that should appear in section 3.5 that might well provide
a quite reasonable alternative to weakening TLS.

That brings up one picky point: The bullet point about the use of a TLS
proxy has implications for both section 3.5 and 3.6, not just 3.6, as
DNS queries could be monitored post-encryption between the proxy and
server endpoint.  So it's a potential solution to both monitoring and
architectural issues that may arise.

Overall there's a lot to think about here, and I appreciate the effort,
and plan to go over these considerations more carefully in the coming
days--and may have additional comments.

michael

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Jul 2019 11:12:33 +0000

> -----Original Message-----
> From: Add <[email-masked]> On Behalf Of Stephen Farrell
> Sent: Monday, July 8, 2019 3:39 PM
> To: Henderson, Karl <khenderson=[email-masked]>;
> [email-masked]
> Subject: [EXTERNAL] Re: [Add] FW: New Version Notification for draft-hal-
> adot-operational-considerations-00.txt
>
>
> Hiya,
>
> > First version of a proposal for Authoritative DNS over TLS Operational
> > Considerations. The authors welcome review and feedback.
>
> A few comments:
>
> - I'm not clear what there is related to applications doing DNS. Calling for
> detailed and thorough exploration of the effects of turning on TLS between
> recursive and authoritative servers makes perfect sense and is something
> that has been absolutely uncontroversial in the dprive WG, which is already
> chartered to look at exactly that.

This is on me. Karl asked me where to send his note, and I advised him to send it to the ADD list based on the instructions that Barry Leiba sent to the DPRIVE list on 8 April:

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

"A mailing list has been created for the ongoing discussion of issues with DNS over HTTPS, DNS over TLS, implementation choices for those, application usage, operational concerns, privacy concerns, performance concerns, and any other such.  Please take all that related discussion to the new list and please stop discussing it on DOH, DPRIVE, DNSOP, and any other lists — that will keep the related discussion in one place, and avoid fragmenting it and having people repeat themselves because of the fragmentation.

The new list is called ADD — Applications Doing DNS:"

So where should the discussion take place?

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Jul 2019 15:02:27 +0000

> So where should the discussion take place?

This document is about recursive resolvers, not applications, using DoT. That is clearly in the realm of DPRIVE's charter, so it should be discussed there.

--Paul Hoffman