Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 22 March 2022 09:24 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672A83A0D1C for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 02:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OW0wUEHjpQ6B for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 02:24:28 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE433A0E0D for <secdispatch@ietf.org>; Tue, 22 Mar 2022 02:24:08 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id v14so13965826qta.2 for <secdispatch@ietf.org>; Tue, 22 Mar 2022 02:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=c5N0NFFON577ABuqthrUTRQ/1wIe9Az19iBTRpFogVw=; b=aQ7N+YBn8HOQeScSWknKX1hA/YxkZojvdVPu3oZ4iBgTJlSmOzzvtnMzKvVcaXyQ27 +ngrS11Kb9rt9TyvF0rD09dIJIgJ2O7zs0iCfrfclYxrmOuezaLHPdGQm/p7LYS4czSC 1gXW+3iSZLhCNj7Y+ry/d+mTk7VlfdE/6dDzbywZGZzY9BTD1qDCoFddUcTL1gXfj3MT GVOEcI4dg3MQq0DnJc6fZdYgBNnL+ukHoygC5ruMmmEKoya1R9/Qyv9e4g7cGZyObdO5 t/i36gSxQgTaiiKXE0KlsJq19Bj8brYLuxSWCLFC0Fo4j3Riwnf2corirxpWTuclkQxW p4ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=c5N0NFFON577ABuqthrUTRQ/1wIe9Az19iBTRpFogVw=; b=JxhwSRJLNmVlit7utD21WyjAxYiqy3fYy5v/SCZKzoFY8fKGZvxupNazYxE9dCel0G 1vmClQLUmAihd2a27qY2WsP1ddNbUCImuo27kSDelO3d56aDQV4LXZO4xElnWJAwhtuo N3RRC6w/qTVh5byADhvmQvZpQYWOuCrfzJYEaZw6FCY4JQrXZE0c4DNqiun7CU8ndBB2 CZ4aWcB2WHhIP8zDXjKCzHwvU7WOYKLT6DkCdxxV4N16Tf/oRefQT7h7ZoiYavaWQo8N FWZaenAb5cL0PV3T5W/QqxuNc6tilAh+ys9Mohp3l/MAM+FMGzsmeYm/0eqRJpkW0sPb oK5g==
X-Gm-Message-State: AOAM531nSD1LkQEV7swtNgU4Uo289E9Re6Ln8MtAGjZT6n91B7qlS1x4 r2Qb8jyo993xSyb3cbVTSs4rL92W7WU13A==
X-Google-Smtp-Source: ABdhPJxH5LGOummgWWe62bDGAAiQknV2lOSjrLWCR3dyBERBIpbjw9D281GP915jqS1NokT9EonBEg==
X-Received: by 2002:ac8:5a4c:0:b0:2e1:ce81:bfde with SMTP id o12-20020ac85a4c000000b002e1ce81bfdemr19670037qta.446.1647941046663; Tue, 22 Mar 2022 02:24:06 -0700 (PDT)
Received: from smtpclient.apple (146-115-101-80.s7246.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.101.80]) by smtp.gmail.com with ESMTPSA id g4-20020ac87d04000000b002e06b4674a1sm13556080qtb.61.2022.03.22.02.24.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 02:24:06 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Tue, 22 Mar 2022 05:24:05 -0400
Message-Id: <940DBC69-34CA-41EC-ACEB-E3E562772038@gmail.com>
References: <29ED5EBE-D5B5-435A-B32D-10BE19513A25@mnot.net>
Cc: Andrew Campling <andrew.campling@419.consulting>, David Schinazi <dschinazi.ietf@gmail.com>, secdispatch@ietf.org
In-Reply-To: <29ED5EBE-D5B5-435A-B32D-10BE19513A25@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: iPhone Mail (19D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/q4INKxQht6pyTFCXCb40XYDnlYg>
Subject: Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 09:24:34 -0000

Mark,

Sent from my mobile device

> On Mar 21, 2022, at 10:17 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> I'm not going to be at SECDISPATCH, so I'll make my comments here.
> 
> First, a general comment. Andrew, you seem to be forming a habit of relying on 8890 to get air time for your arguments. That RFC's focus is on encouraging the IETF community to consider the impacts of its actions elsewhere. The only place it privileges those already active here is when it talks about civil society organisations' ability to act as a channel for engaging the broader Internet community. I don't believe you're acting in that capacity here. 
> 
> I.e., your arguments should stand on their own -- invoking 8890 doesn't reinforce them.
> 
> Now, regarding the draft -- draft-campling-ech-deployment-considerations seems to assume that the *only* viable way to scan for viruses, impose parental controls, or control access to resources is by having a network element impose it without coordination. Your draft supports this by noting that transparent proxies are used because they're easier to administer than on-endpoint software -- a viewpoint which privileges administrator convenience and cost over user safety,  and ignores other options.

No hat - 

Are there more options than Safe Browsing and endpoint solutions? There are DNS based solutions, but if DoH forces you to go to a dedicated DNS server you don’t get that filtering. It’s more helpful if the alternative options are spelled out as well as how solutions are used. Closing a security gap before other solutions are viable or in place will only exacerbate the very real problems faced by organizations and their users experiencing attacks including random ware.

Best regards,
Kathleen 

> 
> The underlying problem is that such "transparent proxy" services are unauthenticated -- they rely on the user understanding that the network is going to perform these services, and accepting their imposition. They're also disproportionate, giving complete access to all data flows and capabilities on the connection.
> 
> Performing these tasks in this fashion allows not only legitimate authorities to impose them, but also illegitimate attackers. As such, they're inappropriate for deployment on the Internet, and that's why we're seeing efforts like ECH -- use of this data and the associated control channel without explicit user authorisation is not "permissionless innovation" (as your draft states), it's an open door to abuse. Put bluntly, you (as a network operator) don't have a right to "innovate" with my data (as a user) -- especially without my permission.
> 
> This doesn't reduce the urgency of meeting those goals for some users, but it does mean that they need to be met without endangering security and privacy for all users on the Internet, even if that has historically been the path of least resistance.
> 
> It also doesn't mean that the path forward will be easy. What's required is a discussion and implementation of interfaces for offloading these functions from operating systems, applications, and IoT devices -- potentially to somewhere else on the network -- in a way that maintains users' autonomy, privacy, and security, and in a proportional way (i.e., only as much access to data as required to fulfil the task). That is difficult not only because of the inherent user interface subtleties and potential for abuse/hijacking, but also because there is little current coordination or convergence at that layer.
> 
> The IETF has a very clear responsibility to assure that the protocols it ships are secure -- hence, ECH. It *could* have a role to play in responsibly offloading these functions, especially where the work intersects protocol design. There is also other work to be done that's squarely outside our scope. I'd suggest that you and your co-authors focus on assisting those positive, forward-looking efforts rather than trying to stop ECH deployment.
> 
> Cheers,
> 
> 
>> On 17 Mar 2022, at 7:38 pm, Andrew Campling <andrew.campling@419.consulting> wrote:
>> 
>> Hi David
>> Thank you for your interest in the draft.  You’re right to highlight the benefit of privacy but, as you will see when you read the draft, we highlight a range of issues that can reasonably be considered as being in the interest of end users such as security, cost and complexity.
>> 
>> Focusing specifically on privacy, it is of course more complex than encryption.  For example, as noted in the draft, by removing an indicator of compromise (the SNI data), a user may be at greater risk of attack from malicious content or simply by surveillance by badly behaved client software.  
>> 
>> RFC 8890 highlights the importance of multistakeholder input in order to understand the potential trade-offs between competing factors that may impact end users.  This is an instance where such engagement would be beneficial as it will no doubt highlight other considerations to take into account.
>> 
>> As you conclude, let’s discuss it at Secdispatch but I believe that debate will be more useful if we avoid using such a narrow interpretation of end users' interests.
>> 
>> Andrew
>> 
>> From: David Schinazi <dschinazi.ietf@gmail.com>
>> Sent: Thursday, March 17, 2022 1:01 am
>> To: Andrew Campling <andrew.campling@419.consulting>
>> Cc: secdispatch@ietf.org <secdispatch@ietf.org>
>> Subject: Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session
>> 
>> Hi Andrew,
>> 
>> (I'm writing as an IAB member, but not representing the IAB)
>> 
>> Your understanding of IAB document RFC 8890 is incorrect. Encrypting the TLS Client Hello is performed to protect end users. In particular, it is an example of Section 4.2 "Creating User-Focused Systems" as it brings control over information sharing closer to the end users. Additionally, ECH was the product of Section 4.3 "Identifying Negative End-User Impact" as we have seen abuse of user information caused by networks observing the SNI. That section additionally references RFCs 7258 and 7624 which clearly lay out the dangers of cleartext information and the user benefit of encryption. If you'd like more information on the IAB's position on this topic, we also released the following statement: <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>.
>> 
>> You're welcome to raise your concerns about ECH, but they are in the opposite of the spirit of RFC 8890. Let's discuss your draft at secdispatch, but I can't imagine it progressing with such a clear misunderstanding of RFC 8890.
>> 
>> Thanks,
>> David
>> 
>> On Wed, Mar 16, 2022 at 9:15 AM Andrew Campling <andrew.campling@419.consulting> wrote:
>> I would like to request some time to dispatch draft-campling-ech-deployment-considerations at IETF 113.  The draft is intended to inject additional detail about deployment considerations relating to Encrypted Client Hello by including observations on current use cases for SNI data in a variety of contexts.  In the spirit of RFC 8890, we believe that end-user needs to be taken into account in protocol development and we hope that this document is one small step in that process. 
>> 
>> 
>> Andrew
>> 
>> 
>> _______________________________________________
>> Secdispatch mailing list
>> Secdispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdispatch
>> _______________________________________________
>> Secdispatch mailing list
>> Secdispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdispatch
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch