IETF Logo Mail Archive

Re: [Doh] DNS API server trust

"Hewitt, Rory" <rhewitt@akamai.com> Fri, 11 May 2018 16:36 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 D7A9112E8DF for <doh@ietfa.amsl.com>; Fri, 11 May 2018 09:36: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 KBCpYfCIoJpy for <doh@ietfa.amsl.com>; Fri, 11 May 2018 09:36:40 -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 7FE021242F7 for <doh@ietf.org>; Fri, 11 May 2018 09:36:40 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4BGWA7U012926; Fri, 11 May 2018 17:36:39 +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=Z+xZYcJXgHqjmSH4kuvUPIcqA3fLxBYBA4MIv7tez2A=; b=htY/hs+wQMzSzBYPbahvbzO/69LNK4Vx7rYSUIASQ2KbrEuhAYqBpg8cS1Ojp74AygSF Z7h9IYX+Se84vy/hst8/N2YB4I1FfnwlBPymeJKoVNsIZBhvAoGQLDkVihPKQK2UEwS3 sRRFDeFPW/6IJeY60OIOTK9lvcgETiOlMHA2naq7monugly/QPyz4uTx/55xdKmAIXjw t6N9boE6+4384TnHQ3oqdJHZO4AF6On09H5TTM6mTgk4whlaopVlCzIsn6hfvbhPu6vd yzhs2SdWeL1bhk7Oj+gF/C4ucSiLZ+PdJp0cI/cP787pTRxeOTlCl8cgfVhqDk0qWYHy 2A==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2hvkwtbs0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 May 2018 17:36:39 +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 w4BGaDuc015650; Fri, 11 May 2018 12:36:38 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hs7xwrb40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 May 2018 12:36:38 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 11 May 2018 12:36:37 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Fri, 11 May 2018 12:36:37 -0400
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Mateusz Jończyk <mat.jonczyk@o2.pl>, DoH WG <doh@ietf.org>
Thread-Topic: [Doh] DNS API server trust
Thread-Index: AQHT6Q0d2tinDQH0hESb5MHUwz2GD6Qqubiw
Date: Fri, 11 May 2018 16:36:36 +0000
Message-ID: <d11ae6d29d274b57bfd7d31f9f679d4d@usma1ex-dag1mb3.msg.corp.akamai.com>
References: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl>
In-Reply-To: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl>
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.112.238]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_04B6_01D3E90B.8DB49310"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-11_07:, , 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=856 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110157
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-11_07:, , 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=792 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110156
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/2g6KJFtSRyBNU_fvLJTw9d2PtxY>
Subject: Re: [Doh] DNS API server trust
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: Fri, 11 May 2018 16:36:42 -0000

Hey Mateusz,

Just as an FYI, I'm a he 😊

Rory

-----Original Message-----
From: Mateusz Jończyk [mailto:mat.jonczyk@o2.pl] 
Sent: Friday, May 11, 2018 2:47 AM
To: DoH WG <doh@ietf.org>
Subject: [Doh] DNS API server trust

Hello,
There was an interesting discussion on a Github pull request
	https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174

It was discussed whether there should be an absolute requirement which servers the client can use, i.e. the following text:

	In the absence of DNSSEC information about the authenticity of responses
	a DNS API server can give a client invalid data in responses. A client
	MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use
	DNS API servers specified using mechanisms such as explicit
	configuration. This does not guarantee protection against invalid data
	but reduces the risk.

User roryhewitt opposed this wording, He or She argued that usage of MUST is unsuitable as it is used here to describe policy, not a mechanism.

I would side with His / Her. The concern is merely theoretical at the time being as there is currently no other way to obtain a DNS API server other then manual configuration (the usage of DNS responses obtained by server push is dealt earlier in the specification). I would claim that concerns "that DOH clients will spray queries to random webservers, or otherwise violate security common sense." (as Benjamin M. Schwartz put it) are unfounded.

The policy should probably be defined after DNS API server discovery will be standarized.

At the very least, I would lower the requirement from MUST to SHOULD here as trust is an intricate topic.

Greetings,
Mateusz Jończyk

v2.23.0 | Report a Bug | By Email