Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Mon, 13 August 2018 20:28 UTC

Return-Path: <ekr@rtfm.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 B0A4013104E for <doh@ietfa.amsl.com>; Mon, 13 Aug 2018 13:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 KqAEw4ltmpM3 for <doh@ietfa.amsl.com>; Mon, 13 Aug 2018 13:28:11 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB01413104F for <doh@ietf.org>; Mon, 13 Aug 2018 13:28:08 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id g6-v6so12164078lfb.11 for <doh@ietf.org>; Mon, 13 Aug 2018 13:28:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dbyVew+Sde8ygFI4DFN8e5IH0pHB3uE3jLfpPn/EqTE=; b=cRry2PcgE2kJ0WBPNLU09AbgenUVyevPjmqpe2XXzqlaNnTs/8qCV9n9zMwhC1ISf+ IRe8AxENn20fHfx+n/4P0imjOOZDaSPrUC/n1fbkv0mjSAHdX8/EZywhZzpNRM7jmopg XfmF+zwxE2EQJ8vQS6AL/ImxhAr7biEo5bxFzLhkhmWjce3NOLOH3fsLiElQ5HHQG8Hg mLBCNwr2LrVCwICLnLnv/FsUvRbxMBoHdY/TFKUn74r2uzNLBzFFzwfxbqS4SZGdRPlq uGs5rAM19BhPKz+i/MxZvN/L/K6ICUbMfjuqLQaNzIckzIzCNvwsyjO/Rb5ZzcW+XOjM 98tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dbyVew+Sde8ygFI4DFN8e5IH0pHB3uE3jLfpPn/EqTE=; b=JjrIstv9FQYlneHdOnBI6jdofZME2O+SXaGHSk30qhxyR4lY0j2jQt7XUPZQzqUh5k E3yHw6hJGHZAeH755NdketdKoh/qz33Gb1izhLSum9cDz3PrxX2R1u8BiiaE50BeWw36 JCRWtrNToO8D0fes4rCk3RaM1PXW6+LD46C1DNfszK2DknN4pQSRi+VDD8ZkTi4p1zqE T5/oBRII7DdY6vi1dB4A6Ix7PDnItBB894DSxGWNRsMgkyN/ZbaqiD9zAMKvnptKcb2O 6h2YcRe8amaraX0dRqvS+ER1F1J55OYrymIHNhvgdYYmlT+QuORg65/Bi2CTDJF2DY/e 5Adw==
X-Gm-Message-State: AOUpUlEv9PmD91Son/DTWuDssHxCLH0jBKpy5txmRbJHkPk+4tnAEtj7 VS7nhtMuwc1Cx8dUKcnr83B65yjjMOMXiH8I7WBOjA==
X-Google-Smtp-Source: AA+uWPxW3uT1qOeij4oc5XOZzISFoqY+HaPO9NAgU+ZcdrBjHCXwSn+XX1bCsyX0BhMY8CAIUAgDxey9fdB+RoZCwKY=
X-Received: by 2002:a19:c3c7:: with SMTP id t190-v6mr9364717lff.108.1534192086858; Mon, 13 Aug 2018 13:28:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 13:27:26 -0700 (PDT)
In-Reply-To: <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org>
References: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 13 Aug 2018 13:27:26 -0700
Message-ID: <CABcZeBOR7b_wmuWXj+QPLAo2TO5QATnDu=TDjXT6CUNoSKdAQg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-doh-dns-over-https@ietf.org, DoH WG <doh@ietf.org>, doh-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005ad282057356ee39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB-KRsLZhttx9tGt75cps>
Subject: Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 13 Aug 2018 20:28:14 -0000

On Mon, Aug 13, 2018 at 1:16 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Thanks for the thorough review. We have a new PR for the changes below.
>
> --Paul Hoffman
>
> On 13 Aug 2018, at 12:32, Eric Rescorla wrote:
>
> COMMENTS
>> S 1.
>>
>>>
>>>   1.  Introduction
>>>
>>>      This document defines a specific protocol for sending DNS [RFC1035]
>>>      queries and getting DNS responses over HTTP [RFC7540] using https
>>>      URIs (and therefore TLS [RFC5246] security for integrity and
>>>
>>
>> You will need a cite for HTTPS.
>>
>
> We'll copy the {{RFC2818}} reference here as well.
>
> S 1.
>>
>>>
>>>      Two primary uses cases were considered during this protocol's
>>>      development.  They included preventing on-path devices from
>>>      interfering with DNS operations and allowing web applications to
>>>      access DNS information via existing browser APIs in a safe way
>>>      consistent with Cross Origin Resource Sharing (CORS) [CORS].  No
>>>
>>
>> "considered"..."include" is odd. I would probably just make this a
>> bulleted list, but alternately, "They were".
>>
>
> "They were" is good here.
>
> S 4.
>>
>>>
>>>      o  Supporting insecure HTTP
>>>
>>>   4.  Selection of DoH Server
>>>
>>>      Configuration, discovery, and updating of the URI Template [RFC6570]
>>>
>>
>> At this point in the document, it is not clear why I would need a URI
>> template, because you don't explain that till S 5. Perhaps in some
>> overview above.
>>
>
> Saying "URI Templates were used because that's the new way to do things in
> the web world" would be honest, but maybe not that helpful in the document.
> Others might have a better way to say this.
>

Sorry, this isn't an argument about templates but rather "why are templates
relevant here at all".

I think you want to say something like "The DOH client is configured with a
URI template [RFC6570] which describes how to construct the URL to use for
resolution."


> S 4.
>>
>>>      offers an unsolicited response that appears to be a valid answer to
>>> a
>>>      DNS query.  This specification does not extend DNS resolution
>>>      privileges to URIs that are not recognized by the DoH client as
>>>      configured URIs.  Such scenarios may create additional operational,
>>>      tracking, and security hazards that require limitations for safe
>>>      usage.  A future specification may support this use case.
>>>
>>
>> I am having some trouble understanding what you are prohibiting here.
>>
>
> I send an query to https://www.ekrexample.com/ over HTTP/2. During that
> HTTP/2 session, I get a DoH request/response pair from that origin.
> https://www.ekrexample.com/ is not in the list of configured URIs allowed
> for DoH for this client. I MUST NOT do anything with that DoH
> request/response.
>

How would you get a DoH request/response pair from that origin? Via push?


Also, "configured" is an odd term if you are talking about web apps
>>
>
> Even web apps appear to have configuration in them, although usually as
> JavaScript list and object declarations.
>

I don't think this is typically how Web programmers would think of it.



> S 5.1.
>>
>>>      DoH servers MUST implement both the POST and GET methods.
>>>
>>>      When using the POST method the DNS query is included as the message
>>>      body of the HTTP request and the Content-Type request header field
>>>      indicates the media type of the message.  POST-ed requests are
>>>      smaller than their GET equivalents.
>>>
>>
>> Because? I assume b/c no encoding. With that said, it is not obvious
>> that this is true because (as shown below) you have to put content-
>> length and content-type in the POST version, so if you had a smallish
>> request, you might gt more expansion that way,
>>
>
> All DoH responses are at least about 17 bytes long (the 12-byte DNS
> message header plus the shortest possible domain name plus the type and
> class), much more typically at least 40 bytes with typical names and even a
> short answer. Base64 of that will be longer than the content length and
> content type. Normal answers will definitely be longer.
>

Well, it's not b64 of that that matters but rather 1/3 of the base64 of
that, because it's only the expansion that matters.

Back of the envelope: 40 * 1/3 ~= 13, and "application/dns-message" is 23
characters.



> S 5.1.
>>
>>>      The DoH client SHOULD include an HTTP "Accept" request header field
>>>      to indicate what type of content can be understood in response.
>>>      Irrespective of the value of the Accept request header field, the
>>>      client MUST be prepared to process "application/dns-message" (as
>>>      described in Section 7) responses but MAY also process any other
>>> type
>>>      it receives.
>>>
>>
>> Why is this good?
>>
>
> To allow other future types of messages that encode DNS information.
>

When those types of messages are defined, they can update this draft.


> What would I do with like image/jpeg.
>>
>
> Nothing. That's why it is a MAY.
>

This just seems like a confusing, non-interoperable, place holder.


> I tend to think of draft-thomson-postel-was-wrong here.
>>
>
> This should be on a different thread, I believe.
>

I don't think so. We're talking about the wisdom of this design choice.



>>>      In the absence of DNSSEC information, a DoH server can give a client
>>>      invalid data in response to a DNS query.  Section 4 disallows the
>>> use
>>>      of DoH DNS responses that do not originate from configured servers.
>>>      This prohibition does not guarantee protection against invalid data,
>>>      but it does reduce the risk.
>>>
>>
>> Do you want to say something about TSIG (and it maybe not being needed
>> here)
>>
>
> Not really. The WG discussed TSIG and decided it was not needed here.
>

Right, and what I'm saying is that this document should say that it
displaces TSIG.

-Ekr