Subject: Re: [Add] "primary control over DNS routing should lie with..."

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Mon, 27 Jul 2020 23:24:04 +0000

-Taking off my chair hat and posting as a contributor –

Rob,

The RFC’s you cite (RFC1958, RFC7624) here, and have cited before when the discussion of security models has popped up are seemingly being taking out of context and are being raised to a higher level of authority that I believe the IAB intended them to be.

They are being cited out of context as if they are complete architecture design documents issued by the IAB and these documents supersede and invalidate any other approaches, technology or operational choices.  They are instead Informational guidance, based on specific issues that the IAB has examined. They are not legislation passed by the IAB or even the IETF to which compliance is mandatory and punishable.    Hence why they are published as Informational RFCs and not Standards Track RFCs. It says so right on the first page of each document:

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Architecture Board (IAB)
   and represents information that the IAB has deemed valuable to
   provide for permanent record.  It represents the consensus of the
   Internet Architecture Board (IAB).  Documents approved for
   publication by the IAB are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741<https://tools.ietf.org/html/rfc5741#section-2>.

The level they have been raised to is beyond the role of the IAB.  Those RFC’s are informational guidance on specific issues that the IAB has looked into, discussed, and produced INFORMATIONAL documents on how to address the issues architecturally.   All IAB documents also needs to be read in the context of their other published RFCs and  in the context of the standards and technology available and when all those other documents and things are considered – it still is up to the choice of the network and security architect to choose how to build their systems.

The IAB is not the architectural authority for the Internet, so it’s not correct to cite their publications and to suggest that anything not listed inside them is to be thrown away and abandoned.  The IAB Informational RFCs are good guidance on topics and not final technical rulings on a subject in the same way a technical specification like TLS can either establish or deprecate API’s or particular meanings of bits.

The IAB’s documents are helpful but they aren’t the final word on subjects, nor are they meant to be.   Ultimately, the ideas in them do help guide IETF Standards Track discussions and directions and in that way contribute to the shaping of the Internet, but they don’t in the way you’ve asserted invalidate and deprecate all other approaches.  The Internet isn’t organized that way – it’s not a centralized IAB designed architecture.    If it where we would have all be using IPv6 20 years ago as well as every browser would be doing DNSSEC.

Basically put, IAB RFC’s are informational not legislative documents.

Paul makes a very valid point – there are very significant numbers of networks in Enterprises, governments, schools, universities, and even homes of some highly skilled engineers that will have DoH present on devices, operating systems, and applications and will be attempting to do discovery, and these networks do have security practices and security systems which may interfere with certain discovery approaches – and ADD should be taking those things into account the best we can.

In practical terms – there are several valid uses cases of where a DoH user will be attempting to discover a resolver:

(1) The open Internet;
(2) home networks connected via a CPE device controlled by the user;
(3) home networks connected via a CPE device controlled by the Access Network provider or ISP;
(4) guest/visitor networks from café’s, airplanes, airports, bus stations, and maybe soon your own car where the user has no direct control or administrative insight/control/say.
(5) private networks such as Enterprises, business, schools, government offices, etc.;
(6) Mobile networks with the edge gateway between the mobile device and the Internet run by the mobile operator – who may  also have considerable control on the behavior of the mobile device.

In all cases, except #1 – the open Internet - there may be a variety of security settings, tools, monitors, blocks, dynamic responses that will need to be successfully worked with in order for a successful DoH resolver discover to take place.  If we only design for #1 in our work in ADD we will be coming up very short on what actual users need to have if they want to easily use DoH.

The work being done in ADD on discovery does need to, as best it can, recognize that the situations above exist and try to understand and work within the constraints that come with them – otherwise a great many of those devices, operating systems, and applications will be unable to successfully use DoH, and that in turn hampers trying to accommodate the recommendations in RFC 7624 on addressing pervasive monitoring in the case of DNS queries.

So to reject the point that Paul is raising is actually working against the goal of RFC 7624 because it may well cut off user’s from being able to use DoH.

…Putting back on the Chair hat….

              Discussing the technical merits and details of discovery approaches is fine, even discussing issues introduced
              by particular security models and tools and how to work with them is in scope of evaluating discovery  proposals.
              But unless a post can bring it back to advancing our discovery discussion – it’s probably out of scope for ADD.

Regards
Glenn

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 22:32:50 -0700

On Mon, Jul 27, 2020 at 4:24 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> The RFC’s you cite (RFC1958, RFC7624) here, and have cited before when the
> discussion of security models has popped up are seemingly being taking out
> of context and are being raised to a higher level of authority that I
> believe the IAB intended them to be.
>
>
If those documents aren't convincing, you could consult RFC 7258 -
Pervasive Monitoring Is an Attack (aka  BCP 188).

>
> Paul makes a very valid point – there are very significant numbers of
> networks in Enterprises, governments, schools, universities, and even homes
> of some highly skilled engineers that will have DoH present on devices,
> operating systems, and applications and will be attempting to do discovery,
> and these networks do have security practices and security systems which
> may interfere with certain discovery approaches – and ADD should be taking
> those things into account the best we can.
>

It is not a valid point. If one owns the devices, then configure them. As
another participant wrote: "From an endpoint's perspective, there is no
authoritative way to distinguish between network administration ('good')
and network attacks ('bad') without some prior knowledge and trust of the
network, such as preinstalled certificate".

thanks,
Rob

---

From: Steffen Nurpmeso <[email-masked]>
Date: Wed, 29 Jul 2020 16:12:20 +0200

Deen, Glenn (NBCUniversal) wrote in
 <[email-masked]>:
 |Paul makes a very valid point – there are very significant numbers \
 |of networks in Enterprises, governments, schools, universities, and \
 |even homes of some highly skilled engineers that will have DoH present \
 |on devices, operating systems, and applications and will be attempting \
 |to do discovery, and these networks do have security practices and \
 |security systems which may interfere with certain discovery approaches \
 |– and ADD should be taking those things into account the best we can.
 |
 |In practical terms – there are several valid uses cases of where a \
 |DoH user will be attempting to discover a resolver:

Please let me be the one who does not understand the dozens of
occurrences of the word DoH aka DNS over HTTPS/1/2/3 (and maybe
later QUIC) in your message as well as the overall overwhelming
DoH flood all over this thread.  I personally am happy that
finally there is DNS over D?TLS, and with longer living
connections or states, even more so.  If there is an already open
HTTPS1/2/3 connection then why not reuse it if possible to pass
some binary blobs (Tony Finch could contribute existing super
small working perl code for DoH123 as well as DoTLS), especially
since the connection is already secured.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)