Re: [Doh] WGLC #2

"Hewitt, Rory" <rhewitt@akamai.com> Wed, 23 May 2018 16:18 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 58F01127241 for <doh@ietfa.amsl.com>; Wed, 23 May 2018 09:18:41 -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 qezWshYiWTBx for <doh@ietfa.amsl.com>; Wed, 23 May 2018 09:18:39 -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 04C7512711D for <doh@ietf.org>; Wed, 23 May 2018 09:18:38 -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 w4NGH0c1008966; Wed, 23 May 2018 17:18:37 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lbJoTC0Gdl5SydJqk5w0XBrO9jMQLDHRH6+XxLuvWkg=; b=YzkW/oynqoPXFzCe1DRTzsX+zRGgqP3MJL2S/eLPxJW/PR/4/i7byEu/wBGgBLo7aEQV KjgAXSt0A4TDyy2v716XuRl6lU9dG9kqGpSVXMlgQWjCFfHsyqaKoMx6Rxs0RyGnvdn7 PNBImbYG8AEVt4rEUxU8fRxpjNmAhHBd7qjHDucZTTCfAUgzDXULcp0fo+r6UnbqU/aK Cw0B18LCbgyIo4SLrCMhAMbftwHn/e7ONzbk4LZGqOcq/7ksjF9xHckKY5SabkYQIzJy AwSzqz660NT95p6QTyXjpttlrPb7yksr4lqbN8pAftiEuby3fBUDTeJBaOs54PEaR666 1Q==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2j4u75u20d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 17:18:37 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4NGGjg6014231; Wed, 23 May 2018 12:18:36 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j2f8vt7pq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 12:18:36 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 May 2018 11:18:35 -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; Wed, 23 May 2018 11:18:35 -0500
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Sara Dickinson <sara@sinodun.com>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [Doh] WGLC #2
Thread-Index: AQHT74Bupf/j2QbeDU2bbLl5BLZf8aQ6piLwgAGUPYCAAUmG4A==
Date: Wed, 23 May 2018 16:18:35 +0000
Message-ID: <189a46786d574c79af469c77717ad624@ustx2ex-dag1mb3.msg.corp.akamai.com>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com>
In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.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.19.113.121]
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_003A_01D3F277.05FCA5F0"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_06:, , 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-1805230161
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_06:, , 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-1805230161
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/qZgOS6kIutnL858g6DTHVsVmLpw>
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: Wed, 23 May 2018 16:18:42 -0000

> However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

Oh, that sounds like an excellent idea to me - I'd just really prefer to have all the "security considerations" stuff be in one place (Section 9) and ideally non-normative. But there should certainly be references to that section in many other places in the document.

Thanks,

Rory

-----Original Message-----
From: Sara Dickinson [mailto:sara@sinodun.com] 
Sent: Tuesday, May 22, 2018 8:37 AM
To: Hewitt, Rory <rhewitt@akamai.com>
Cc: DoH WG <doh@ietf.org>
Subject: Re: [Doh] WGLC #2



> 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.


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


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.

Sara.