Oblivious DNS over HTTPS
draft-pauly-dprive-oblivious-doh-11

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-pauly-dprive-oblivious-doh-09. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will perform a single registry action.

IANA will add application/oblivious-dns-message to the media types registry at https://www.iana.org/assignments/media-types after the IESG approves a separate request to register the type. This request has been submitted as a management item for the 2/17 telechat.

Thank you,

Amanda Baber
IANA Operations Manager

draft-pauly-dprive-oblivious-doh has been presented to the ISE for
publication as an Experimental RFC on the Independent Stream.

==Purpose==

This document describes an experimental protocol that allows clients to
hide their IP addresses from DNS resolvers via proxying encrypted DNS
over HTTPS (DoH) messages. The protocol is termed "Oblivious DNS over
HTTPS.

The document contains a dedicated section (section 10) to discuss the
scope of the experiment.

== History==

This document was discussed in DPRIVE and the question was asked about
how to progress the work. The Independent Stream was suggested as an
option, and in the absence of a strong push within the WG for adoption,
the authors selected the Independent Stream.

The document was sent to add@ietf.org by Eliot Lear on 2021-11-01 to
raise some discussion points.

The document was first brought to the ISE in April 2021 at version -06.
Since then it has been revised several times to address review comments.

==Non-IETF Work==

The Abstract, and the Introduction make the scope of this work clear,
stating that the work is an experiment and was developed outside the
IETF.

==Security Considerations==

The whole document is relevant to Privacy and so security plays a big
part. The authors have provided a substantial Security Considerations
section to highlight some potential issues and some possible attacks.

==IANA==

This document requests IANA to make an assignment of a Media Type from
the registry of Multipurpose Internet Mail Extensions (MIME) and Media
Types. The assignment policy for that registry is Specification Required
with Expert Review. The designated experts for this registry are Ned
Freed and Alexey Melnikov.

The document contains an adequate request form with the appropriate
details.

The DEs have not been consulted yet.

==Reviews==

This document has been reviewed for the ISE by Mark Nottingham and David
Schinazi. The ISE also did a review.

The reviews raised a number of points of substance and some editorials
all of which have been addressed in updates to the document.

Details of the reviews can be retrieved on request.

==Remaining Nits and Edits==

There are some nits around the use of BCP 14 language that the authors
will resolve in a new revision.

==Points of Discussion==

In his email to add@ietf.org, Eliot Lear stated:

> Just for the record, I think this draft leads to a situation where
> miscreants can hide their tracks.
> Section 10.1 of that document is weak.
> This has the potential to leave web sites unable to determine who
> is attacking them, and also prevents service providers from
> backtracing such attacks.
>
> This demonstrates precisely why an appropriately strong applicability
> statement is necessary in any ADD output.

This was refuted by Tommy Pauly and independently by Eric Rescorla as:

> If someone is attacking the Web site, they will need to actually send
> packets to the site, which will either (1) contain their IP or (2)
> will be proxied.
> In the former case, they can determine who is attacking them and in
> the latter case, they can proxy the DNS requests through the proxy and
> don't need ODoH, which is primarily a performance improvement over
> generic proxying.

There was no further debate of this point.