Re: [Doh] WGLC #2

Mateusz Jończyk <mat.jonczyk@o2.pl> Tue, 22 May 2018 17:29 UTC

Return-Path: <mat.jonczyk@o2.pl>
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 A3569128961 for <doh@ietfa.amsl.com>; Tue, 22 May 2018 10:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 flAQwtmknz9V for <doh@ietfa.amsl.com>; Tue, 22 May 2018 10:29:37 -0700 (PDT)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 136021201F8 for <doh@ietf.org>; Tue, 22 May 2018 10:29:36 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 20122 invoked from network); 22 May 2018 19:29:34 +0200
Received: from agsm225.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.225]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 22 May 2018 19:29:34 +0200
From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <mat.jonczyk@o2.pl>
To: DoH WG <doh@ietf.org>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com>
Openpgp: preference=signencrypt
Message-ID: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl>
Date: Tue, 22 May 2018 19:29:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GBrV3V0HorEJC8naajqj8604mmzk9Azla"
X-WP-MailID: 5da07bdb2d87ee14e75629eb8e632510
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000000 [gSO3]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/eT3R4qtROJVKQzd8U_HZHbsaqlc>
Subject: Re: [Doh] WGLC #2
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: Tue, 22 May 2018 17:29:40 -0000

W dniu 22.05.2018 o 17:37, Sara Dickinson pisze:
> 
> 
>> On 21 May 2018, at 21:41, Hewitt, Rory <rhewitt=40akamai.com@dmarc.ietf.org> wrote:
>>
>> I know I brought this up in
>> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agreed to
>> leave it, but I see that Mateusz subsequently brought it up in
>> https://www.ietf.org/mail-archive/web/doh/current/msg00557.html...
>>
>> I would really like to see Section 4 (Selection of DNS API Server) moved to be
>> within Section 9 (Security Considerations), perhaps as a subsection (9.1:
>> Selection of DNS API Server)
> 
> The reason I think it is useful to have Section 4 is that Section 6.3 (Server Push) discusses which URI’s pushes should be accepted from and so is implicitly talking about which servers to use. However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

I would argue that section 6.3 "Server Push" is poorly written and needs to be
clarified. I have asked several questions about it in the past:
	https://www.ietf.org/mail-archive/web/doh/current/msg00558.html
in order to better understand it. (I would like to thank Patrick McManus and Ben
Schwartz for explanations I received.)

I propose that it should be rewritten simply to:

	A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}}
	Section 8.2) whose pushed request URI does not match the configured DNS
	API server.

> 
> 
> 2 other comments:
> 
> 1) I previously asked if this spec required that a DNS API Sever should only be used if authentication of the TLS connection was successful. I got conflicting answers from Paul and Martin (‘No we can’t say that’ vs ‘authentication is critical and implicit’) and don’t see anything in this version that resolves this. I know there is other work attempting to address this issue (and more) but the lack of clarity in this document on the topic is still an issue for me. I’d still like to see a single sentence that either
> - makes clear the requirement (preferable) or
> - states that this is out of scope

It may happen that the DNS API server is running on a local home router and uses
a self-signed certificate. (I have talked about running a local DNS API server
on a home router before.)
I suppose that in this case the certificate could be supplied as part of a
configuration.

> 
> 
> 2) “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.”
> 
> What does authenticity mean here - data integrity or DNSSEC authentication? If it is the latter I would argue to remove it because DNSSEC and transport choice are orthogonal.

I suppose that it means here data integrity: the server can provide bogus
responses to DNS requests and strip DNSSEC information.

> 
> Sara.

Greetings,
Mateusz