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

Sara Dickinson <sara@sinodun.com> Wed, 02 May 2018 11:43 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14FA12DA6F for <doh@ietfa.amsl.com>; Wed, 2 May 2018 04:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDbHEEMvA3Sj for <doh@ietfa.amsl.com>; Wed, 2 May 2018 04:43:06 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED59126B72 for <doh@ietf.org>; Wed, 2 May 2018 04:43:05 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::] (port=64996) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1fDq9z-0007IW-AC; Wed, 02 May 2018 12:43:04 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org>
Date: Wed, 02 May 2018 12:42:13 +0100
Cc: DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com>
References: <EB0551FD-B7D6-4834-9979-75D162FC5A62@sinodun.com> <DBFFE98A-972D-44BE-AD20-5F3C7B378312@sinodun.com> <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3445.6.18)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/pyqdZzKLiNtsYPvuYF2L87h12EI>
Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 11:43:09 -0000


> On 1 May 2018, at 04:22, Paul Hoffman <paul.hoffman@icann.org> 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]
> 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".  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.