Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD

"Winfield, Alister" <Alister.Winfield@sky.uk> Wed, 15 January 2020 16:29 UTC

Return-Path: <Alister.Winfield@sky.uk>
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 05269120841 for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 08:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk
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 dTg9U33Thsr8 for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 08:29:32 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130071.outbound.protection.outlook.com [40.107.13.71]) (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 E3B91120839 for <add@ietf.org>; Wed, 15 Jan 2020 08:29:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kJ3s8mIZb5Ksx4BQy6ZQBDMbyxbt2DGmy3JlqeNevuSf7+HmiZskv9ZZNRUJ/YSQI6t//tKawAgWYNt8E16VFxic92JYat8MnxBf6yqM2A9cigITHJtg5w4hwT/Tx9y+pPTfVnlrMoYLw1LPP4028qTE0Qw4/sObhkNUWYqnJZrOpbTdFKKA6NYf6yf7eGnZdM612S0FQXc5oL8BQF2llwAoKkG221cKonOihHnRK6DCB3uEBhAPa0PyZKdm9EKs08OKxBkWipGWYgH7zNE2Iq2W9lSmTWKPBWm24c0zi6JDwIgnCY2EoeiCnaSMlBAzghpyweIBWVvRwTgyLTvAQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KH4HcB4HlZ8wjS9svRErkykD1v/WagMIBGVWcfb78qQ=; b=iAsLaHGkDz35tdPPLOCdbi66yMBzZFyY0DvZK9W/DvQ/SqIUEqr/X3AqrERmAzQh8yv5NaFCWU5w3bywCRjtanqJg3FGJdLT/29tj2kKXO7zXThzviINJKbzgMLxUoYqTQDRVqn4bTD2T/eOjwN3oYRnlrBUE5pU7ng/GbX8JzcHf/1RqDEDViDdSonegQgoYi7UuMuj8IKiwmdfWJl/42Mwo6m0DDp568R5MuDsfpFmct/YZbOtgD49bBE8LK30FSSA14532R/hUIFlV+6LbrOQ4gLinYlzVKCncYlypYUT/f2fi+5RLxSeqSLOpa0c8Zak7BaiSJ9pYGF4k3sFCA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KH4HcB4HlZ8wjS9svRErkykD1v/WagMIBGVWcfb78qQ=; b=JIzx+6YKGL43YqneFuXe4JA85IcZxfkddakGu5sIxDSqQwr8JZs/sCITb2odIcDa835Z0638KAjIjUn5uR+NdddsUcI2akCvcDRCoXJHHajWuEb1vEvBk5G886eLPfnMAtn0znPmWypKd7SPqDceaPvHKtE6N081EoCU6SAfDSA=
Received: from DB8PR06MB6521.eurprd06.prod.outlook.com (52.135.60.13) by DB8PR06MB6474.eurprd06.prod.outlook.com (52.135.61.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 16:29:29 +0000
Received: from DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886]) by DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886%6]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 16:29:29 +0000
From: "Winfield, Alister" <Alister.Winfield@sky.uk>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: "Deen, Glenn (NBC Universal - Guest)" <Glenn.Deen@nbcuni.com>, Alissa Cooper <alissa@cooperw.in>, Ted Lemon <mellon@fugue.com>, ADD Mailing list <add@ietf.org>, "\"Mirja Kühlewind (IETF)\"" <ietf@kuehlewind.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD
Thread-Index: AQHVxz9JmWuBpd+SzUuSPFqRPFm94qfquN6AgAARY4CAASkkgA==
Date: Wed, 15 Jan 2020 16:29:28 +0000
Message-ID: <E78736F8-2126-4237-84AD-0FCDCC86F6DE@sky.uk>
References: <AC40F2B0-ABBE-494D-AFBC-42BB840D2A89@nbcuni.com> <CAHbrMsBqnemZKYwDvzXfGZ4iYp1bw31_FjWGj9igMYHUszjGQA@mail.gmail.com> <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com>
In-Reply-To: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk;
x-originating-ip: [78.86.25.108]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 02874bb8-c83f-465e-11d2-08d799d817fa
x-ms-traffictypediagnostic: DB8PR06MB6474:|DB8PR06MB6474:
x-ld-processed: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237,ExtAddr
x-microsoft-antispam-prvs: <DB8PR06MB64741998C4C1AD82F0F3A045E3370@DB8PR06MB6474.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(189003)(199004)(5660300002)(316002)(53546011)(66946007)(66476007)(66556008)(6486002)(4326008)(110136005)(54906003)(71200400001)(64756008)(6506007)(8676002)(66446008)(2906002)(33656002)(76116006)(91956017)(8936002)(86362001)(36756003)(2616005)(81166006)(478600001)(186003)(966005)(6512007)(66574012)(26005)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR06MB6474; H:DB8PR06MB6521.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lCjgQGkWqRp9meSCs8hik4eFwDyF4Xou5xfNZuvQJ1OlPEDI715KnEYuyFVUBJyCvSivNjoFuuQ+MKyG8dBVBY1WQk36kMA5JoK9Wvpb5aPOmKkZ1mBXwfMcgTq8Tn4RJBei1RBLMzJxPV4nP/izZ5ObYrs8WQaTVj4ypHsNtIRY4kh3uCjnIWaPP8SGN/Cv9tIWYDR1G/ZnMuTtL7Ie5lEaOQ6BFs/pH4ZEf56Zz22iAj/KHFttGvpnO/SSfpJWbN91POJWNmY7ukK2CpH4eVDKja7q5iyyQ0ct4wZsOXw6tm9MZFRTZ1gWPcoDlCOeZD7Unycqg/7UXovcU2K2NQo+qyKvSeRLzjCAptG8HDK9S6bExRMblhp2ktR6dcAzayglgJrhFaW3ZqbGYU4/LyJ1N1G0zTnk5yKv0iDorPbfc5FeeRuQBUbGQf7ZuuVf1LlXSbIfgDOn/RA6C5q2DMfDeTr5eeeUmR9qCogBpuCYIiGYPwNyJtMtnnYwjkfyJ6iwSkGIfKCLrNFl/ugM6w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E78736F82126423784AD0FCDCC86F6DEskyuk_"
MIME-Version: 1.0
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 02874bb8-c83f-465e-11d2-08d799d817fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 16:29:28.9697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Euf/iHIgr+chLwZyXP+ZSYQIsI3yC4ZN/K1tAGfssaK4K78adfi585W+D95aatPKSdpr77AYlA0xp3q164O11A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR06MB6474
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/QDwcmGx-pxwf_jws9Wjcv3QneY0>
Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD
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 16:29:36 -0000

I see this revision as good progress and support this charter proposal.

Alister Winfield.

From: Add <add-bounces@ietf.org> on behalf of Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Date: Tuesday, 14 January 2020 at 22:46
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: "Deen, Glenn (NBC Universal - Guest)" <Glenn.Deen@nbcuni.com>, Alissa Cooper <alissa@cooperw.in>, Ted Lemon <mellon@fugue.com>, ADD Mailing list <add@ietf.org>, ""Mirja Kühlewind (IETF)"" <ietf@kuehlewind.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [EXTERNAL] Re: [Add] A proposed charter for ABCD

Hi Ben,

As a note, Glenn and I worked on a revision of this today that I have sent out to the list that should cover most of your comments.

Anything specifically naming "policy" has been removed throughout the charter proposal. We did toss around the idea of "resolver behavior" but ended up being a bit more general in referring to information about the resolver, that can be used in resolver selection. The main goal here is to provide a communication mechanism in the IETF spec for properties that describe what a resolver will serve, the most concrete example of which is information about serving split DNS names. This communication mechanism could be used for "policy" or "behavior" information, but that would certainly be out of scope for this working group.

With regards to the text for "security properties", this mainly came from boilerplate security charter text. I don't read that as necessarily ruling out opportunistic use of encryption as a strategy, but any communication of explicit information between two parties (servers and clients in this example) should be specified to be secure. I would argue that just trying DoH to a given address does give you the security properties of HTTPS when you use that; but that's also not any new protocol mechanism.

Best,
Tommy


On Jan 14, 2020, at 1:43 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:bemasc=40google.com@dmarc.ietf.org>> wrote:

Thanks for attempting a consensus charter, Glenn.  Some comments inline.

On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com<mailto:Glenn.Deen@nbcuni.com>> wrote:
...
> Proposed Working Group Charter
...
>
> Network operators that start offering DNS encryption on their servers
> need a way to indicate this support to clients. Beyond support for
> encrypted DNS, local networks may also have policy about the use of DNS
> to non-local DNS servers. Communicating such network policy to clients
> would allow clients to make more informed decisions about which DNS
> servers to use.

I feel strongly that we should avoid "policy" in the WG scope text.  We appear to lack a shared understanding of what this word means, and it is the focus of much conflict here.  Including it here seems like a recipe for confrontation within the working group.  I also don't think it's necessary for almost any of the goals mentioned on this list: we can rephrase in a way that is both clearer and more broadly acceptable.

In this case, I would suggest: "... servers need a way to indicate this support to clients.  Clients may also be able to make better decisions about which DNS servers to use if they can learn more about the resolution behaviors of each server.".

> The Adaptive DNS Discovery (ADD) working group will define mechanisms and
> protocols to:
...
> - allow network providers to communicate DNS policy to clients,
> including information about locally-accessible names;

In this case, I would rephrase as "... communicate information about resolver behavior to clients, including ....".

...
> Any mechanisms that specify interactions between clients and
> servers must provide the security properties expected of IETF
> protocols, e.g., confidentiality protection, integrity protection,
> and authentication with strong work factor.

This appears to rule out opportunistic upgrade to DoH, as well as the entire RESINFO framework adopted by DNSOP.  Personally, I don't think "the security properties expected of IETF protocols" are compatible with most of the use cases we've discussed, including the ones mentioned in this charter text.  I think we would be better off flipping this to explicitly focus on opportunistic protocols, and promise to document appropriate guardrails against improper reliance on security properties that are not provided.

While opportunistic security is not to be relied on for crucial security properties, I think opportunistic privacy (against a passive adversary) is valuable and worth including in the working group's scope.  Also, opportunistic upgrade would give clients a clear indication that they are speaking directly to a modern resolver, allowing them to rely on modern DNS features.  In the absence of such a signal, clients cannot rely on any DNS features beyond basic A/AAAA queries, due to the lingering deployment of buggy resolvers, forwarders, and middleboxes.  I know that this has been a major factor in popular clients' decisions not to make use of EDNS, DNSSEC, and other modern DNS features.
--
Add mailing list
Add@ietf.org<mailto:Add@ietf.org>
https://www.ietf.org/mailman/listinfo/add

--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to phishing@sky.uk as attachments. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD