Subject: [Doh] Mirja Kühlewind's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 13 Aug 2018 07:58:58 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-doh-dns-over-https-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One question:
In case DoH doesn't work for some reason, is this supposed to fallback to DNS
over TLS? I guess if the selected host name would allow detection of DNS and
SNI is used, it wouldn't be too hard to block DoH requests....? Is that a
concern?

Also one smallish comment:
As already brought up in the TSV-ART review (Thanks Ferando!) I would recommend
to further clarify this sentence in section 5.1: "Using the GET method is
friendlier to many HTTP cache implementations." What does "friendlier" mean...?
Or at least maybe provide a forward reference to sec 6.1.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 13 Aug 2018 13:06:38 -0400

Thanks Mirja.

> SNI is used, it wouldn't be too hard to block DoH requests....? Is that a
DoH doesn't proscribe any particular path to choosing servers and protocols
(even for choosing the DoH server) - each protocol has different properties
and particular servers might have properties only the configurer can
understand (e.g. trust in the service, not just authentication) in the
context of the endpoints it knows about. So whether fallback is suitable is
something DoH can only really comment on by describing its properties
(encrypted and authenticated transport).

There is no expectation that the same server run DNS service using more
than one protocol (i.e. there is no expectation that you use the same host
and ratchet down from doh, to dot, to plaintext tcp, to dns.)

> Or at least maybe provide a forward reference to sec 6.1

roughly it means more likely to work for a variety of reasons.. I'm not
sure delving into those reasons really is helpful to the DoH reader - the
important property is that HTTP caching works-well with GET and not-so-well
with POST. Is friendly a bad word for that? its commonly used in the http
and application space around caching afaict.

-P

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 09:33:39 +0200

Am 13.08.2018 um 19:06 schrieb Patrick McManus:
> Thanks Mirja.
> 
> On Mon, Aug 13, 2018 at 10:58 AM, Mirja Kühlewind <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     One question:
> DoH doesn't proscribe any particular path to choosing servers and protocols (even for choosing the DoH server) - each protocol has different properties and particular servers might have properties only the configurer can understand (e.g. trust in the service, not just authentication) in the context of the endpoints it knows about. So whether fallback is suitable is something DoH can only really comment on by describing its properties (encrypted and authenticated transport).

I suggest to address downgrade attacks.

> 
> There is no expectation that the same server run DNS service using more than one protocol (i.e. there is no expectation that you use the same host and ratchet down from doh, to dot, to plaintext tcp, to dns.)
> 
> roughly it means more likely to work for a variety of reasons... I'm not sure delving into those reasons really is helpful to the DoH reader - the important property is that HTTP caching works-well with GET and not-so-well with POST. Is friendly a bad word for that? its commonly used in the http and application space around caching afaict.
> 

I suggest something like "better caching performance".

Renne

---

From: Star Brilliant <[email-masked]>
Date: Thu, 16 Aug 2018 09:09:53 +0000

> I suggest something like "better caching performance".

Agree. Here are my personal opinions:

GET:
- Better caching

POST:
- No base64 overhead? (We have gzip so they are same)
- Not logged by default? (An evil server operator can deploy logging at both DNS level and HTTP level)
- Support longer requests than GET.

Usually I personally prefer GET unless the URL is potentially longer than 2048 bytes. Because I could not come up with any more benefits of using POST.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 16 Aug 2018 11:09:01 +0200

Hi Patrick,

> Am 13.08.2018 um 19:06 schrieb Patrick McManus <[email-masked]>:
> 
> Thanks Mirja.
> 
> On Mon, Aug 13, 2018 at 10:58 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> One question:

Okay thanks for the explanation. I guess it is somewhere „hidden“ in doc that DoH-only servers might be a likely deployment scenario. Is that something worth mention explicitly?

> roughly it means more likely to work for a variety of reasons... I'm not sure delving into those reasons really is helpful to the DoH reader - the important property is that HTTP caching works-well…

For me „friendly“ was just kind of a meaningless word in this context (and I respectively wasn’t aware that this word is commonly used). I don’t think you need to give any reasons but maybe it’s simply more clear to say „GET is more likely to be supported by many HTTP caches“?

Mirja