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

Fernando Gont <fgont@si6networks.com> Sat, 11 August 2018 23:19 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB0124BE5; Sat, 11 Aug 2018 16:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 YkOCgN27LCQT; Sat, 11 Aug 2018 16:19:48 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBF2127333; Sat, 11 Aug 2018 16:19:48 -0700 (PDT)
Received: from [192.168.1.250] (unknown [109.103.90.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A23D18250A; Sun, 12 Aug 2018 01:19:46 +0200 (CEST)
To: Patrick McManus <mcmanus@ducksong.com>
Cc: tsv-art@ietf.org, draft-ietf-doh-dns-over-https.all@ietf.org, DoH WG <doh@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> <CAOdDvNrnoFmg0m36L=kSSS3k1xU46AOCA0dAUgnQWyB79jNwww@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <90445a8e-be3f-8752-c8ee-6e021c621ed5@si6networks.com>
Date: Sun, 12 Aug 2018 01:19:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAOdDvNrnoFmg0m36L=kSSS3k1xU46AOCA0dAUgnQWyB79jNwww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/1YPvCGjYCbqA_vMneePHkF2PvZI>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-doh-dns-over-https-13
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Aug 2018 23:19:51 -0000

On 08/11/2018 09:20 PM, Patrick McManus wrote:
>     * 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.
> 
> 
> my understanding is that giving the client the choice between doing
> DNSSEC validation and trusting the recursive to do so is standard DNS
> practice.

What I had in mind when making this comment is this: There seem to be
anycast resolvers implementing DoH (e.g., CLoudflare's and others, if I
understand correctly). Giving them the responsibility for DNSsec
validation would seem to me as giving them way too much power (i.e.,
what if they were compromised and/or went evil?)




>     * Page 15 (Security Considerations):
> 
>     DoH essentialy switches from a connection-less transport (UDP) to a
>     connection-oriented one (TCP).
> 
> I disagree a bit. It adds a third TCP based DNS based approach to the
> DNS over TCP and DNS over TLS approaches already standardized so it is
> not breaking new ground in that sense.

To put it in a different way:

* What would be the impact if an attacker were to DoS TCP-based
resolution in the traditional case? (i.e., while UDP-based resolution
still works)

* What would be the impact if an attacker were to DoS (HTTPS/)TCP-based
resolution in the DoH case?

If the impact were the same, then just say that, and no need to worry.
But my understanding is that in current deployments you normally only
fall back to TCP when the UDP response was truncated, whereas with DoH,
you rely 100% on TCP.



>     This means that now the server should take care
>     of all state-exhaustion attacks against TCP (e.g., take a look at:
>     https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf
>     <https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf>).
>     Defending
>     against such attacks maybe non-trivial. This should at least be
>     mentioned in
>     the security considerations.
> 
> DoH seeks to use HTTPS substrate best practices in order to inherit the
> well known properties and defenses of HTTPS. The first sentence of the
> security considerations tries to say this "Running DNS over HTTPS relies
> on the security of the underlying HTTP transport." I don't think it
> makes sense to have each foo-over-http consider the baseline
> considerations separately.

I don't mean you need to elaborate on how to defend it. JUst noted that
if you completely get rid of UDP-base resolution, then the TCP one (in
this case DoH) becomes even more critical, and the impact of a DoS
against TCP-based resolution is higher. And defending a stateful
protocol like TCP against resource exhaustion attacks is non-trivial.


>  
> 
>     * 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?
> 
> 
> one of the relevant things http means when it says it is stateless
> (which iirc is the first sentence of 7230) is the requests themselves
> can also be reordered by intermediaries or even routed onto different
> connections.. some may hit various caches and not even be placed on the
> connection. sometimes the 'intermediary' is the library or javascript
> engine you are using - DoH is meant to be expressable at the semantic
> layer of bodies and headers. This particular point was raised in
> conjunction with dnsop's session signal draft which requires a stateful
> DNS transport.. HTTPS is stateless message based (despite being layered
> on TCP) and therefore we want to be clear DoH won't work for building a
> session layer. (that draft is coordinated).

Maybe I'm a bit confused. If, on the same connection, I send a request
to resolve "A" and subsequently a request to resolve "B", the result of
the later might come before than the result of the former? (I'm trying
to understand what the "ordering guarantees" that are not provided with
DoH).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492