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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Patrick,

> Am 13.08.2018 um 19:06 schrieb Patrick McManus <[e-mail]>:
> 
> Thanks Mirja.
> 
> On Mon, Aug 13, 2018 at 10:58 AM, Mirja Kühlewind <[e-mail]> wrote:
> 
> 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?
> 
> 
> 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.)

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?

> 
>  
> 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
> 
> 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.

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



> 
> -P
> 
> 
> 
>