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

[Michael Sinatra <[e-mail]>]

Howdy,

On 2019-07-08 15:48, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 08/07/2019 23:30, Livingood, Jason wrote:
>> On 7/8/19, 3:40 PM, "Add on behalf of Stephen Farrell"
>> <[e-mail] on behalf of [e-mail]> 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.

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]

>>> 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?
>>
>> [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 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