Re: [Add] meeting hum: should the IETF take up this work?

"STARK, BARBARA H" <bs7652@att.com> Tue, 23 July 2019 22:46 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 A6F65120956 for <add@ietfa.amsl.com>; Tue, 23 Jul 2019 15:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 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, 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 gPuXg81hS6OY for <add@ietfa.amsl.com>; Tue, 23 Jul 2019 15:46:10 -0700 (PDT)
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 626261203C2 for <add@ietf.org>; Tue, 23 Jul 2019 15:46:10 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6NMjbHl030681; Tue, 23 Jul 2019 18:46:09 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2txaya8fc8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 18:46:09 -0400
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 x6NMk7HH005346; Tue, 23 Jul 2019 18:46:08 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6NMk6Aj005318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2019 18:46:06 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 76924400A010; Tue, 23 Jul 2019 22:46:06 +0000 (GMT)
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30485.vci.att.com (Service) with ESMTPS id 618E54009E84; Tue, 23 Jul 2019 22:46:06 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 18:46:05 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Rob Sayre' <sayrer@gmail.com>, "'add@ietf.org'" <add@ietf.org>, 'Barry Leiba' <barryleiba.mailing.lists@gmail.com>
Thread-Topic: [Add] meeting hum: should the IETF take up this work?
Thread-Index: AQHVQaN87GveYlF1D0yqei+aqr3W5abYxQJA
Date: Tue, 23 Jul 2019 22:46:05 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E23910C@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com>
In-Reply-To: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.223.206]
Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E23910CGAALPA1MSGUSRBF_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1906280000 definitions=main-1907230232
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/NbTBaxHawI3B7U5MtYYp2sXt6sU>
Subject: Re: [Add] meeting hum: should the IETF take up this work?
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: Tue, 23 Jul 2019 22:46:13 -0000

That’s like saying IETF should never have published BCP 38. What is BCP 38 (or any other BCP), if not policy?
IETF absolutely is the right place to discuss BCPs related to technology that has the ability to massively impact the traffic patterns of the Internet and impact (in a very negative way) the experience of all users of the Internet. I’m *not* saying that it *will* have such a negative impact. But it absolutely has the ability. And it’s this *potential* that has all the network operators very worried.

The Internet ecosystem is built on the idea that the various participants can generally trust one another to participate in a way that benefits the Internet and its users.
I don’t believe that any of the application developers participating in IETF want to damage the Internet or have a negative impact on users’ experiences.
And I very much trust and like the people from Mozilla and Google and Cloudflare. They’re all super nice people who are great fun to drink beer with.
But I don’t think they have the operational experience/knowledge to fully understand what might happen in various access networks (especially mobile networks) if they started defaulting all their application users to DNS servers outside the local (ISP, enterprise, university, etc.) network.
The IETF is a place where we can and must have this discussion, so all parties can participate in understanding and mitigating the potential harm.

I’m also trying to understand why there seems to be resistance to providing ISPs with advice on deploying DoH. Who does it hurt to provide such advice, and why should it be improper for IETF to provide advice on deploying a protocol it has published? [Advice on how to deploy is absolutely a form of “policy”.]
And why should an ISP DoH resolver or using regular DNS not be considered valid “choices” for a user to make?
Barbara

From: Add <add-bounces@ietf.org> On Behalf Of Rob Sayre
Sent: Tuesday, July 23, 2019 6:09 PM
To: add@ietf.org; Barry Leiba <barryleiba.mailing.lists@gmail.com>
Subject: [Add] meeting hum: should the IETF take up this work?

Hi,

The IETF shouldn't take up work in reaction to non-technical (aka "policy") concerns about imminent deployment of an approved RFC. In this case, it's DoH (https://tools.ietf.org/html/rfc8484<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8484&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=k1e1muHdqm-ONwR45wiuv8wXcq1yvfPjFbBIMZURbwM&s=JuF6FZ_JnOj3uIC39JSKJtDfgM-xXTh2hTl8LzaNwPY&e=>).

Mozilla's presentation accurately stated that DNS is no longer an effective control surface. It can't be, given that HTTPS is ubiquitous, and one can use it to tunnel any protocol.

thanks,
Rob