IETF Logo Mail Archive

Re: [Doh] WGLC #2

"Hewitt, Rory" <rhewitt@akamai.com> Mon, 21 May 2018 20:41 UTC

Return-Path: <rhewitt@akamai.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 90D0612D881 for <doh@ietfa.amsl.com>; Mon, 21 May 2018 13:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 JLyBOz7AN85e for <doh@ietfa.amsl.com>; Mon, 21 May 2018 13:41:49 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9162D12D885 for <doh@ietf.org>; Mon, 21 May 2018 13:41:49 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4LKaW97018835 for <doh@ietf.org>; Mon, 21 May 2018 21:41:48 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=s5U0HIO4KwKCwC79xJcb/pBdkQ/MWnvkiQM45U9l+Ww=; b=J80Gv3RiQhEYoHJ9moy2KZK66RiINaWtDfZxXinG4kEqRYNs4WrV5Pub+240mf3wDwJl cxNE9UT3Ms5QBqzt6FFIZsApPFTcpJEWSFRiDpiPYzRXdFxxe8pGSBd5+majIsGof5A5 Smna1tOO4BD9rD9qyeuYK/dTPmikpWpoWIg5jCwPcN0sn15bszOQJdZY3RuHiqNN9+Ll QJEbjVYejarvbKTbU3vr9cBFFNSi0eoo1piO9JmYzJwxlyPlr2bVcVbBpPXeJ1G+NEvJ GNV5T1pKYQnmlLqyhOCNWM+nQhlbvm0wCScPd5cgJ5kyEX8ZU+A9yjKQJbDmKuAGPODZ mw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2j290cqpbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <doh@ietf.org>; Mon, 21 May 2018 21:41:48 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4LKaW4w017313 for <doh@ietf.org>; Mon, 21 May 2018 16:41:47 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j2f8u94tg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <doh@ietf.org>; Mon, 21 May 2018 16:41:47 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 21 May 2018 15:41:46 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1365.000; Mon, 21 May 2018 15:41:46 -0500
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: DoH WG <doh@ietf.org>
Thread-Topic: [Doh] WGLC #2
Thread-Index: AQHT74Bupf/j2QbeDU2bbLl5BLZf8aQ6piLw
Date: Mon, 21 May 2018 20:41:46 +0000
Message-ID: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.28.212.173]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0025_01D3F109.757B2240"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210245
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210245
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/5R8q61gL_F67s-kvn_58EDiibEA>
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: Mon, 21 May 2018 20:41:52 -0000

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) and have the normative MUST and SHOULD changed to 
be non-normative 'must' and 'should'.

Specifically, my concern (as voiced in /pull/174)  is that I don't believe we 
should be using normative terms outside of technical implementation details - 
as I said "typically a MUST/REQUIRED/SHALL specifies an action to take and 
there will be some obvious consequences for not taking that action (an error 
thrown). In this case, we're saying "You MUST check that the DNS server you 
want to connect to is trustworthy" without saying how they should do that. And 
since there will be no error message from an untrustworthy DNS server, how 
would they know? It feels like we're taking things that outside of the spec 
(whether/how to trust a DNS server) and making it part of the spec... "

Ben and Patrick may have had valid reasons for disagreeing with me, but as I'm 
not sure if anyone else saw it, I'd like to be sure it's true consensus.

This is the last time I'll bring it up, I swear...

Rory

v2.23.0 | Report a Bug | By Email