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

"Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de> Thu, 16 August 2018 07:44 UTC

Return-Path: <ietf@bartschnet.de>
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 E64C4130EF7 for <doh@ietfa.amsl.com>; Thu, 16 Aug 2018 00:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de
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 3_t_JvBwfT7B for <doh@ietfa.amsl.com>; Thu, 16 Aug 2018 00:44:31 -0700 (PDT)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 E07ED130E7E for <doh@ietf.org>; Thu, 16 Aug 2018 00:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:To:Subject:content-disposition; bh=M9ks4aKqPtSJ8x2VMoNj3YlZWgPLNCTkrQAtwYt1bsA=; b=Sg4r9og/fiiylwCdu9A/nru0d9 nMroRgb2+/WeSaGULMkb1DzeF413+8JZkOktTHRYPFA0+wPADMaRXFZETQeahvyOg0yoYSAEiE7GX Ex771gzSHkESjVz2Xbo1nln9kYBC8jF7fvKZ3EI6Wj0jBPwEZa0PLuOBBheMfYTQetd79G2YTIFbp 5NDfFTZTtJ/+UsIDFCb01129aX1U9sv29ulLiBrwb7V5OZllSxufHwgvIbnH4f1gYvnEf6pRIP/xz P70XCN9tlRivhHI8thdY86Dh7UMFnOYdnbci/8tckhqr7s9OGtJzcxWH4VnCM4DxEjYZzdpYU5BT4 XqetAoVN3SGnmntviAi2O5tQ1OUqb2yz1t98blup93upuYtFYnTDg17lC3XHi26KQVYP83IoRf1L6 gjqdDluMAUna7veMeNYV2ErFxUtIanUZYWMyesjlFYM7RnsYDuCtJU+V9g/VSEDXuIlHXxxZM6w9H 5HZNe3HQ1UwbKMceTMQgoya/eZOCJyDGPAY0ckKjkYiTQbqwrNRCJraM0kGqvOr3IHfY25Gp2qTPP iFHmuFEpbiLjruzyQldhzQevJ0H8w71uDEBAkZZtzRhPl+QKlP+1z6wPcDi4FPYyE/mxBplCt+hfD Zdr6ItkQFuvHI7MyB/Ylpz++d0pvRj4tjL3fUKOPs=;
Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqCxH-0001oF-WC with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 09:44:29 +0200
To: doh@ietf.org
References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> <BYAPR19MB2248B13FC643D6B7321169BE943B0@BYAPR19MB2248.namprd19.prod.outlook.com> <508cc0f8-4826-ac8c-f52f-704a02f0bb9a@si6networks.com>
From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de>
Message-ID: <f784272a-ab00-8808-40d2-6fcd13257afb@bartschnet.de>
Date: Thu, 16 Aug 2018 09:44:26 +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: <508cc0f8-4826-ac8c-f52f-704a02f0bb9a@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/NDMlnCLslEGATPTS0sxccZvAEzw>
Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13
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: Thu, 16 Aug 2018 07:44:35 -0000


Am 12.08.2018 um 01:34 schrieb Fernando Gont:
> Hello,
> 
> Thanks for the response. Inline....
> 
> On 08/12/2018 12:58 AM, Star Brilliant 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.
>>
>> 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.
> 
> This is the scenario I was assuming, for which it seemed a bad idea to
> ahve the DOH server do DNSsec validation. Anyway to clarify this so that
> others do't fall into the same assumption?

I suggest to add something like "the AD-bit MUST NOT be used if the upstream resolver is not under control of the client operator" (please, find some better wording).

Renne