Re: [Tsv-art] [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13

Star Brilliant <> Sat, 11 August 2018 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7979C130EA7; Sat, 11 Aug 2018 15:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3BaFZRjWJZvC; Sat, 11 Aug 2018 15:58:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5240C130E66; Sat, 11 Aug 2018 15:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nmMZDJ5mAi8wL41EeDSBqUqqV8XUDNCC23Qdv3WB1bA=; b=L8kQPBpZqAOT/vpqU5wAQP0ZQOBime3FeH7IKp67k5NNB1JFFzj1+J3JV/TpZe5f5EQshVlOf9KLjlW7FIs0Xjqlq/q89SkON0W2ZcRXtfUaPsIrMd0o3diTWZCY5+q1m8UPduN0xX7fWj92YrqSA94gowGIEPPV7N3C4i14zQTMU02coJtFL32vE4xdm7HIMzL985osJ/FaJidapTtvVjlmS38oMsJ3GYqYxoKYFEA3dNChhbp8andgxAeqIXp/tzKHpjVh1u5j1xeHRjhvp2D77ToWoIRMpiBhrcZHOYxSizXJOLIDPnCmPQJXs2yhabbpFrf1AySCLS0mJYMoSQ==
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1059.14; Sat, 11 Aug 2018 22:58:47 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1059.14 via Frontend Transport; Sat, 11 Aug 2018 22:58:47 +0000
Received: from ([fe80::8514:9a20:4e1c:783d]) by ([fe80::8514:9a20:4e1c:783d%3]) with mapi id 15.20.1017.022; Sat, 11 Aug 2018 22:58:47 +0000
From: Star Brilliant <>
To: Fernando Gont <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13
Thread-Index: AQHUMUlhaDwSy0sptEW0dunH9M5M5KS7KvSO
Date: Sat, 11 Aug 2018 22:58:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-incomingtopheadermarker: OriginalChecksum:C5112A405350CFB317DED646B0A409C3281A592E5DDF4F41D9D5D873D25B84A5; UpperCasedChecksum:33E28FD45CA8979727CAF65B463DBDA2247244BFC70546C54406FC543AA919BE; SizeAsReceived:7353; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ZxYXnT8uXioYZpHvBMTmQOiNxjD0gpKhoEJoRXa1He1YlSecDpWIPw==]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3NAM01HT113; 6:KlC40OXpNb//b1up9gYQ+Cz1fRObP4/s9SL16tUjVigGI3AMrWKl7Ujg0cP5WGqV+Cya/ZsvsiITfK15jm1vYd2bnh7MCncff3rF+AHGWCJApkkcJEkrZpK8/Qpfq2HOeRNFtxMhPXGhobtKgQx9otbVkonJKKUqSZREObRO3YpWjf0PIk4lYSPycG77LxG5f3LB7l/RPB7kQGg3xUszFWmk9uFij5lvtquhxtm5qE5mMWonOXEkwZGUDEhSW8nuWoNSzd2sBpse7aWp2JpbTYlWWHcXfb0iqAVkHrRvyLiLByfOpxsmXhqKS/F968VLaUJdaigtQv8SHPemV6OdWqfbPfdBwBrC5CzQFrofacdpsBre2k/EGmUggszNRK2bSo5v9E8SJF27l/+rtk528niAVTp7v4sGvcLjaUgV+AfN/d0Vhwb4ZS3grh1WO48IopNtZn/bVfHSj33++wnvZA==; 5:yCF8TTaB2u4EHJ1hSTft+l+1OqKF8Th2VipgFsViBrcmfTZUY/aLMuKl1sMNNaFfU+gcSkijWjan5/BmwPmm2JPuA82cxd/dEhOBS85FQJDgtY1SyvjPqyauFkWQklGscm9tlnRVVE+kenFmdrQwMdZZg7/eGqzgfYn5P+4JDDI=; 7:ca7oBrHKZckWuE+/rDgbnlU4j1vOiCt6HjzITpO33GDHjEazpEncnd8LSx95daWfDtPROszDF8uRCEwTm/hbkR/7XlTc3SLR0FouZAgkULGHC9Ibl/sPryUiwWA41d4o1Twv1vDnk1Ng9bRQArv6e48oy+PuoFhx8ERs5yhtvQFNqURBeGKSZjwDBxi2YbVgBSrqbiAQHhWMGWlwjjFO5kAhJtZuSGhpD4Pkb9i8j9cQ1yAL9dU7tlpNE+P+Y+D8
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BN3NAM01HT113;
x-ms-traffictypediagnostic: BN3NAM01HT113:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BN3NAM01HT113; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT113;
x-forefront-prvs: 0761DE1EDD
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(43544003)(25786009)(5250100002)(4326008)(68736007)(83332001)(2900100001)(73972006)(55016002)(97736004)(20460500001)(14454004)(6306002)(56003)(229853002)(6246003)(9686003)(966005)(86362001)(6436002)(104016004)(2501003)(82202002)(14444005)(256004)(486006)(476003)(54906003)(110136005)(53546011)(6506007)(5660300001)(11346002)(8936002)(8676002)(99286004)(7696005)(76176011)(106356001)(46003)(105586002)(74316002)(305945005)(81156014)(87572001)(446003)(33656002)(102836004)(6346003)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT113;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-message-info: EQa1GG7HKtsV9EsfCG3FQx8+RzHzG+s37NJZ8n8JFtDw3M5WXq48ltr1xWQcrehOmyuDTwoonr8rIEBURTElIxm6KLbST3bTel7HWMRkKJdwGkkKmQVQrEMnoX1yCICJp4911HdBx+cAuu45kPgJaSaoJXn2N2TpUdZmqqxGr+QtIYsEP09Tux1Pw9PF9xAENMqykS9KSU46y4k0NFbwz4DGDskIbbtWfLuL7hOsFrQ=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d44a50c-fc30-4a00-906f-08d5ffddfeca
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2018 22:58:46.9135 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT113
Archived-At: <>
Subject: Re: [Tsv-art] [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Aug 2018 22:58:52 -0000

Hello Femando and the mail list,

Thanks for your review!

I would like to answer some of the questions based on what the contributors had discussed before.

Paul Hoffman is the core author, so if I made a mistake, please consider his answer as the authoritative.

On Sat, Aug 11, 2018 at 6:00 PM Fernando Gont <> wrote:
> * Page 5:
> >  Using the GET method is friendlier to many HTTP cache
> >  implementations.
> Could the queries really be cached for the POST case?

Yes, they can.

>From RFC 7231: "In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD."

But GET is friendlier than POST, because of the fact most ISP's transparent proxy or cloud WAF systems do not cache POST.

> * Page 15:
> > It is the choice of a client to either
> >    perform full DNSSEC validation of answers or to trust the DoH server
> >    to do DNSSEC validation and inspect the AD (Authentic Data) bit in
> >    the returned message to determine whether an answer was authentic or
> >    not.
> Relying on the DoH server for DNSsec validation does not seem like a good idea.
> You want DNSsec to be end-to-end.

We discussed about this paragraph before. The problem depends on how you deploy DoH services.

1) For most people's needs, the users grab a list of DoH servers from the Internet and configure their systems to use the DoH servers. These public servers are untrustworthy. So the users need to validate DNSSEC at their end.

2) A web-based application using DoH with a pre-configured server maintained by the application author. Then the server has the same trust level as the JavaScript code that validates the records. If anyone does not trust the server, they should not use the web app. In addition, by checking the records on the server, we can save some bandwidth for mobile users.

3) A dedicated enterprise cloud environment with hundreds of machines, serving trillions of requests per day. The administrator would want to offload the DNSSEC check to the gateway to reduce service latency, improve cache hit-rate, reduce intra-AS bandwidth cost, and to increase service quality.

4) A resource-constrained device (some Arduino or ESP8266 or other IoT-like things). You will want to delegate the check to your PC as long as the PC can be trusted.

Conclusion: People use DoH in different ways. Sometimes it is better to "give the user more choices, but make the default choice secure".
Therefore, we have the text "It is the choice of a client to either trust or distrust".

> * Page 15 (Security Considerations):
> DoH essentialy switches from a connection-less transport (UDP) to a
> connection-oriented one (TCP). This means that now the server should take care
> of all state-exhaustion attacks against TCP (e.g., take a look at:
> Defending
> against such attacks maybe non-trivial. This should at least be mentioned in
> the security considerations.
> * Page 16:>
> >    HTTP [RFC7230] is a stateless application-level protocol and
> >    therefore DoH implementations do not provide stateful ordering
> >    guarantees between different requests.
> Are you meaning that requests that are pipelined could be responded in
> different order? Something else?

The DNS wire protocol is not always a single query-and-response model. Some functions (e.g. zone transfer) require multiple messages to be sent and received. As already stated in the text elsewhere, DoH does not support this kind of functions (at least not in this version).

> * Page 16:
> >    A DoH server is allowed to answer queries with any valid DNS
> >    response.  For example, a valid DNS response might have the TC
> >    (truncation) bit set in the DNS header to indicate that the server
> >    was not able to retrieve a full answer for the query but is providing
> >    the best answer it could get.  A DoH server can reply to queries with
> >    an HTTP error for queries that it cannot fulfill.
> Why should this happen? Why not encode this information in the encoded DNS
> response (in wire format)'

If you are asking about "an HTTP error", here is the explain:

1) Some errors indicates a problem happening on HTTP layer, not DNS layer.
For example, 302 Redirection, 404 Not Found, 401 Unauthorized

2) Sometimes it is technically impossible to reply with an encoded DNS response.
For example, the web server crashed, throwing a default 500-504 error page

DoH is a double-layered protocol. It is intuitive that each layer may break, resulting with an error that represents that layer. (Additionally, since DoH runs on TCP/IP, a DoH server can even reply with an icmp-port-unreachable error.) Layered error is the nature of Internet protocols.

If you are asking about the TC bit, this happens in many situations. One cause is broken TCP on the authoritative server, which happens quite frequently with anycast servers.