Re: [Add] [Ext] Updated charter proposal for ADD

"STARK, BARBARA H" <bs7652@att.com> Wed, 15 January 2020 21:00 UTC

Return-Path: <bs7652@att.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1395120911 for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 13:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 mwlJlT1MpzLl for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 13:00:48 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 06D6B12090B for <add@ietf.org>; Wed, 15 Jan 2020 13:00:48 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00FKtUnl040715; Wed, 15 Jan 2020 16:00:45 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2xj4y9s3ay-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 16:00:44 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00FL0fjf031851; Wed, 15 Jan 2020 16:00:43 -0500
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00FL0ZJE031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jan 2020 16:00:36 -0500
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id DE936400B576; Wed, 15 Jan 2020 21:00:35 +0000 (GMT)
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30488.vci.att.com (Service) with ESMTPS id B0AA7400B573; Wed, 15 Jan 2020 21:00:35 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.148]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Wed, 15 Jan 2020 16:00:33 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Rob Sayre' <sayrer@gmail.com>, 'Andrew Campling' <andrew.campling@419.consulting>
CC: 'ADD Mailing list' <add@ietf.org>
Thread-Topic: [Add] [Ext] Updated charter proposal for ADD
Thread-Index: AQHVy9lrH/Jj4q+ZTEW79nweBNTbH6fsdWOAgAAEV4D//7eF0A==
Date: Wed, 15 Jan 2020 21:00:32 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <AD6E599F-96E8-44FC-8A05-8BFD2F659129@icann.org> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <CAChr6SzcuomCFisPhLHYfQGzbR2=yYhtsGHV8+kd5gCdJn+ABA@mail.gmail.com> <LO2P265MB05730A944404EFD86DF99E8CC2370@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CAChr6SzygCAMGUXmOL9Hb_w5CgjeFK30KodystPYPt4jD6Fkeg@mail.gmail.com>
In-Reply-To: <CAChr6SzygCAMGUXmOL9Hb_w5CgjeFK30KodystPYPt4jD6Fkeg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.79.220]
Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611537457D1GAALPA1MSGUSRBF_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-15_03:2020-01-15, 2020-01-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 clxscore=1015 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001150158
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/cqsFxj6g3aX6bST2RUqkEiBt16A>
Subject: Re: [Add] [Ext] Updated charter proposal for ADD
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 21:00:53 -0000

On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling <andrew.campling@419.consulting<mailto:andrew.campling@419.consulting>> wrote:
On Wed, Jan 15, 2020 at 19:24 Rob Sayre <sayrer@gmail.com<mailto:sayrer@gmail.com>> wrote:
> Right now, my DNS server is 192.168.86.1, and encrypted DNS seems designed to bypass it.

Well, a lot of networking products (both consumer and corporate) have an unencrypted DNS server on a private IP.

I was wondering how the certificates would be constructed if they wished to offer DoH or DoT. I know public services are able to get certificates with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering how private networks will offer encrypted DNS, and whether the debate around the security considerations is important.

thanks,
Rob

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5280-23section-2D4.2.1.6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=8_yvv1il3zewjGy7Q4S4OtQitnmASPvjF6La_TDH_6U&s=DIByZeZTbnVQz-bhge3oVFvDzYJTHKdgueM0_z-8W7s&e=>

<bhs> Discussions I’ve had with people so far have been along the lines of (1) we’re not aware of any user-friendly/easy way to get a certificate into consumer routers that will be ok’ed by a CA in browsers’ trust stores, (2) the user experience of doing https to a consumer router from a browser is pretty horrible and scary, (3) some of these routers (e.g., Netgear) don’t even allow users to change what the router sends in DHCP/RA (it’s always the router’s private IP address; but the user can change what recursive resolver the router then uses), and (4) many people are unconvinced that the threat of compromise inside the home network is worth the effort and negative user experience.</bhs>