Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2018 15:14:14 +0000

On Apr 30, 2018, at 10:04 PM, Martin Thomson <[email-masked]> wrote:
> Sara's request for text regarding 7828 is reasonable.  Generic text might
> suffice along the lines of "extensions to DNS that are specific to the
> choice of transport, such as RFC 7828, are not applicable to DOH".

That seems fine, and hopefully meets Sara's desire for clarity.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 2 May 2018 12:42:13 +0100

> On 1 May 2018, at 04:22, Paul Hoffman <[email-masked]> wrote:

Hi Paul and Martin,

> Thanks, Sara! I have opened pull requests for #1, #3, and #4.

Thanks Paul for that - I’ll comment directly on the issues.

> Of the remaining:
> 
>> 2) Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. Section 6 specifically says 
>> “DNS API clients using the DNS wire format MAY have one or more EDNS options [RFC6891] in the request.” 
>> 
>> In a similar manner to the problem with truncation of responses, there are 2 EDNS options I can think of that are transport specific, but how to handle them isn’t described in this draft i.e.
>> - EDNS(0) Padding (When RFC7830 was written only DNS-over-TLS was standardised, but the text doesn’t restrict it to that it simply says “Therefore, implementations MUST NOT use this option if the DNS transport is not encrypted.”).  Alexander Mayrhofer requested a note be added about this option in his review of the -04 draft.
>> - EDNS(0) Keepalive (RFC7828).
> 
> I'm not sure why there are "problems" with these. For padding, the server can use it or not.

For me the issue is simply that HTTP padding is specifically mentioned in the draft (several times) but that EDNS(0) isn’t mentioned at all. A simple statement in Section 6 to the effect that ‘DNS API clients and servers may use EDNS(0) padding [RFC7830] in the DNS wire format independently of whether or not HTTP padding is used.’ would suffice I think. 

>  For keepalive, it makes no sense for it to support it. Just like any traditional DNS server, a DOH server has to understand its context when deciding how to answer queries with EDNS options.

[including Martin's comment]
> choice of transport, such as RFC 7828, are not applicable to DOH".  FWIW,
> HTTP/2 has its own keepalive mechanisms.

Precisely - there is no reason to use EDNS(0) Keepalive in DOH and DNS API clients shouldn’t. I’d be happy with a specific statement on that rather than the generic text… since the above could be taken to exclude the use of EDNS(0) Padding (which is an extension specific to encrypted transports)...

>> 5) Section 8: 
>> 
>>   "If a client of this protocol encounters an HTTP
>>   error after sending a DNS query, and then falls back to a different
>>   DNS retrieval mechanism, doing so can weaken the privacy and
>>   authenticity expected by the user of the client.”
>> 
>> This text brings up the biggest issue I have with the document, which is that I would like to request that it replaces the above text with a section that clarifies how DOH can be used in the context of a privacy usage profile (see both RFC7858 and RFC8310 for descriptions of Strict vs Opportunistic usage profiles for DNS-over-(D)TLS).  To be clear: in these profiles only configured servers are used (no discovery is involved). I’m happy to help with text here if there is consensus that this is in scope and beneficial to the document. 
>> 
>> The big, big gain I see here is for applications such as Stubby which would like to have a standard way to add DOH as a transport option alongside the existing use of DNS-over-TLS when using those profiles.  In this scenario Stubby would be the ‘client’ in the text above which can use either a DNS API client or a ‘traditional' DNS client.  
>> 
>> (As an aside, I note that the above is the first and only mention of the word ‘privacy' in the document and this document does not currently describe the specific privacy benefits of this specification compared to ’other mechanisms’.)
>> 
>> Two ambiguities with the current text are:
>> - RFC8310 says a DNS client should only use a single privacy usage profile when resolving a specific query (precisely to avoid the problem mentioned above) but this text seems to contradict that. 
>> - while it is heavily implied the document isn’t actually crystal clear on whether a configured ‘trusted’ server can be used if authentication of the certificate fails. 
> 
> Please, no. Or at least, not here. The complicated DNS-over-TLS usage policies are one of the reasons we have so little implementation of DNS-over-TLS. (Others may disagree with this statement.)

[Including Martins comment]
> I agree with Paul - the profile in RFC 8310 overlaps considerably with text
> in HTTP RFCs.  For instance, HTTP/2 already mandates TLS 1.2 or greater
> without compression (it also goes further to require PFS).  8310 also
> misses a few things that DOH covers, such as the OCSP/AIA deadlock.
> 
> The true advantage of DOH is that it just uses HTTP.  And that means
> relying on HTTP mechanisms for ensuring integrity, confidentiality, and
> authentication.  I think that those are broadly adequate.
> 
> Separately, I'd suggest that the 8310 profile requirements are
> unrealistic.  I'm not aware of many implementations that do raw public keys
> or cached info.  I also don't see any particular value in mandating tickets
> and false start - they each provide ample motivation on their own without
> needing a MUST.

My request was not at all to have RFC8310 to apply here in general - I completely agree that doesn’t make any sense, and I didn’t even mean this document should adopt Strict vs Opportunistic.

> It would be lovely if Stubby could add DOH as a transport that is parallel to DNS-over-TLS, and for that there has to be some common understanding of privacy and trust levels. Duplicating to twisty mazes from DNS-over-TLS usage policies is not going to help. Instead, a new document that covers DNS-over-TLS, DOH, and the likely future DNS-over-QUIC needs to deal with this, and more clearly.

I’m all for that general approach but…. what I think would help here is: 

- Can this document make any clear statement about whether or not a DNS API server is ‘trusted' if HTTPS authentication fails? 
There is an implied MUST in section 9 “while still authenticating the resulting connection via HTTPS”. If there is actually a MUST here then I believe that actually naturally maps to using DOH only with a Strict profile for client that already implement that (in the short-term and in the absence of any other guidance - we are adding DOH to Stubby right now). 

 - If there is no requirement relating to this or if that is deemed to be out of scope of this document and will be the subject of future work then please state that explicitly. 

(As a general point, in reviewing I had to trawl through the mailing list again to understand what was in and out of scope - a section in the document clarifying that would actually be very helpful I believe).  

> 
> I'm about to propose a non-WG-forming BoF in Montréal for folks who want to talk about such work. But I don't think it should stop DOH; if it does, we're probably talking at least six months to hope for consensus. (And the consensus on policy in DPRIVE was more from exhaustion than agreement.)
> 
>> 6) Section 9: 
>> 
>> “A DNS API client may face a similar bootstrapping problem when the
>> HTTP request needs to resolve the hostname portion of the DNS URI."
>> 
>> “...or resolving the DNS API server's hostname via traditional DNS “
>> 
>> DNS-over(D)TLS using only a configured authentication domain name shares many of the discovery issues that DoH has. Paragraph 4 of Section 9 overlaps with the discussion of ‘meta-queries’ as already described in more detail in RFC8310 and it would be helpful if the language could be aligned or if RFC8310 was at least referenced here. One of the issues discussed in that document is the potential for denial-of-service if these meta-queries are subject to attack, which seems worthy of note. Again, happy to help with text here.

“Alternative strategies a client might employ
   include making the initial resolution part of the configuration, IP
   based URIs and corresponding IP based certificates for HTTPS, or
   resolving the DNS API server's hostname via traditional DNS or
   another DNS API server while still authenticating the resulting
   connection via HTTPS.”

Propose adding 
“It should be noted that some of these bootstrapping mechanisms can be actively attacked which can result in denial-of-service for DOH clients in a similar manner to that for DNS-over-TLS meta-queries [RFC8310]. “

Sara.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 03 May 2018 00:58:27 +0000

On Wed, May 2, 2018 at 9:43 PM Sara Dickinson <[email-masked]> wrote:
> A simple statement in Section 6 to the effect that ‘DNS API clients and
servers may use EDNS(0) padding [RFC7830] in the DNS wire format
independently of whether or not HTTP padding is used.’ would suffice I
think.

That would be fine with me.  Or a more general: "Padding of requests and
responses can use padding provided at any protocol layer that supports it:
TLS 1.3, HTTP/2, and EDNS(0) padding can all be used as desired."

> > It would be lovely if Stubby could add DOH as a transport that is
parallel to DNS-over-TLS, and for that there has to be some common
understanding of privacy and trust levels. Duplicating to twisty mazes from
DNS-over-TLS usage policies is not going to help. Instead, a new document
that covers DNS-over-TLS, DOH, and the likely future DNS-over-QUIC needs to
deal with this, and more clearly.

> - Can this document make any clear statement about whether or not a DNS
API server is ‘trusted' if HTTPS authentication fails?

If trust is attached to a name or URI, then authenticating that identifier
is a critical precondition of authorizing a server.  Though that isn't
stated here directly, it is at implied through the use of HTTPS.  I don't
think that we need to explicitly restate requirements from RFC 2818 though.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2018 01:07:10 +0000

> For me the issue is simply that HTTP padding is specifically mentioned in the draft (several times) but that EDNS(0) isn’t mentioned at all. A simple statement in Section 6 to the effect that ‘DNS…

Is that kind of specificity really necessary? Isn't:
   DNS API clients using the DNS wire format MAY have one or more EDNS options {{RFC6891}} in the request.
and it's pair for DNS API servers sufficient? That is, why should we call out some kinds of EDNS extensions but not others?

> Precisely - there is no reason to use EDNS(0) Keepalive in DOH and DNS API clients shouldn’t. I’d be happy with a specific statement on that rather than the generic text… since the above could be t…

We have for the next version:
   Many extensions to DNS, using {{RFC6891}}, have been defined over the years.
   Extensions that are specific to the choice of transport, such as {{RFC7828}},
   are not applicable to DOH.
The fact that some extensions might or might not help DOH seems limiting, particularly because we don't know about future extensions.

> - Can this document make any clear statement about whether or not a DNS API server is ‘trusted' if HTTPS authentication fails?

I don't think so, not without running smack into the DNS-over-TLS-policy wall above.

> There is an implied MUST in section 9 “while still authenticating the resulting connection via HTTPS”. If there is actually a MUST here then I believe that actually naturally maps to using DOH only…

As well you should. 

> - If there is no requirement relating to this or if that is deemed to be out of scope of this document and will be the subject of future work then please state that explicitly. 

Personally, I dislike reading an RFC that talks about future work because it is impossible to find it, particularly if it isn't finished.

> (As a general point, in reviewing I had to trawl through the mailing list again to understand what was in and out of scope - a section in the document clarifying that would actually be very helpful…

Noted. Whereas others want to remove the current Requirements section.

> “It should be noted that some of these bootstrapping mechanisms can be actively attacked which can result in denial-of-service for DOH clients in a similar manner to that for DNS-over-TLS meta-quer…

The denial-of-service is on DOH service, not on DNS service. This goes back to the questions above. I simply don't think we (or DPRIVE, for that matter) have clear thinking on this yet.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 3 May 2018 12:56:38 +0100

> On 3 May 2018, at 02:07, Paul Hoffman <[email-masked]> wrote:
> 

See below.

>   are not applicable to DOH.

As stated, EDNS(0) Padding is specific to the transport choice (it cannot be used on unencrypted transports) so this statement would rule out using it. 

> The fact that some extensions might or might not help DOH seems limiting, particularly because we don't know about future extensions.

I actually don’t have a problem with making the generic statement because I agree with your point here, but lets be clear about the extent of it. So, for clarity I would include RFC7830 in the list if this option is taken.

If the consensus is to make specific statements then Martin’s proposed text  "Padding of requests and
responses can use padding provided at any protocol layer that supports it: TLS 1.3, HTTP/2, and EDNS(0) padding can all be used as desired.” WFM

<snip>

> I don't think so, not without running smack into the DNS-over-TLS-policy wall above.

I’m asking specifically about requirements on HTTPS authentication, nothing related to DNS-over-TLS here...

Hum…Martin seems to think differently:

> On 3 May 2018, at 01:58, Martin Thomson <[email-masked]> wrote:
> 

Maybe you do for the DNS audience…. I’ve talked to 3 other DNS folks who read the draft and were not clear on that…..

> This goes back to the questions above. I simply don't think we (or DPRIVE, for that matter) have clear thinking on this yet.

If the document is going to enumerate the possible bootstrapping techniques then I think it should at least make some statement about the security considerations of using them, or else kick all discussion of bootstrapping options to the future document. I also don’t think there is anything unclear about the specific attack path described in the above text. 

Sara.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 4 May 2018 13:54:50 +0200

Hello,

[comments inline on Padding]

> For me the issue is simply that HTTP padding is specifically mentioned in the draft (several times) but that EDNS(0) isn’t mentioned at all. A simple statement in Section 6 to the effect that ‘DNS…

I do agree with Sara on this. It seems incomplete to mention HTTP
padding a few times, but not mention DNS padding at all, given that
the protocol is a "mixture" of both worlds.

And remembering a few discussions i had with fellow encryption gurus,
it seems preferrable to perform padding at the "innermost" level,
where the application has the greatest extent of control over whether
or not padding has been performed, and to what extent. Looking at the
layering of DOH, that probably means that EDNS padding gives an app
more control than HTTP padding, and HTTP padding gives an application
more control than padding on the TLS layer.

Therefore, i do suggest that we do mention EDNS padding as at least an
equal choice to HTTP padding.  I can prepare text (or a pull request
if that is preferred).

best,
Alex

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2018 15:42:07 +0000

> equal choice to HTTP padding.  I can prepare text (or a pull request

I have created Pull Request #173 to add this.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 4 May 2018 18:03:48 +0100

Hi All, 

The text in the latest GitHub version of the draft now uses phrases like "a client MUST specifically authorize DNS API servers”. 

I’m not clear if there is any difference between ‘authorizing’ a server and just using a server? If there is some subtlety here then I’d like to understand if but if not I created https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174> to simplify the text and also put the discussion of selection of server in its own section. 

Sara. 

> On 30 Apr 2018, at 18:59, Sara Dickinson <[email-masked]> wrote:
> 
> 
> 4) Section 8: With regard to trusted/untrusted servers I would suggest at least a small restructure for clarity. At the moment the first discussion of the client trust model is in section 5.3 ‘Server Push’.
> 
> I would suggest adding a section before this (possibly after section 3) called something like ’Trust model for client queries’ with the following (combining text from section 5.3 and 8):

---

From: Patrick McManus <[email-masked]>
Date: Mon, 7 May 2018 07:47:46 -0400

Thanks for this suggestion. I like it.

On Fri, May 4, 2018 at 1:03 PM, Sara Dickinson <[email-masked]> wrote:

> Hi All,
>
> The text in the latest GitHub version of the draft now uses phrases like
> "a client MUST specifically authorize DNS API servers”.
>
> I’m not clear if there is any difference between ‘authorizing’ a server
> and just using a server? If there is some subtlety here then I’d like to
> understand if but if not I created https://github.com/
> dohwg/draft-ietf-doh-dns-over-https/pull/174 to simplify the text and
> also put the discussion of selection of server in its own section.
>
> Sara.
>
> 4) Section 8: With regard to trusted/untrusted servers I would suggest at
> least a small restructure for clarity. At the moment the first discussion
> of the client trust model is in section 5.3 ‘Server Push’.
>
> I would suggest adding a section before this (possibly after section 3)
> called something like ’Trust model for client queries’ with the following
> (combining text from section 5.3 and 8):
>
>
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 8 May 2018 17:56:53 +0100

Hi All, 

A small pull request after off-list comments by Willem Toorop on the wording for DNSSEC usage:
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/176 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/176>

Sara. 

> On 4 May 2018, at 18:03, Sara Dickinson <[email-masked]> wrote:
> 
> Hi All, 
> 
>> On 30 Apr 2018, at 18:59, Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>