From nobody Tue Oct 19 08:35:26 2021 Return-Path: X-Original-To: e2ee@ietfa.amsl.com Delivered-To: e2ee@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136BC3A0BDF for ; Tue, 19 Oct 2021 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 aeYKv3T5EGXE for ; Tue, 19 Oct 2021 08:35:18 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 6268D3A0BDB for ; Tue, 19 Oct 2021 08:35:15 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id b12so323379qtq.3 for ; Tue, 19 Oct 2021 08:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language :references:to:from:in-reply-to; bh=HEH1+pU6MyW5CUJuMlaWZu4oHg1P9eYKQsLn+o2XHBg=; b=VdoBDdKnLnE5g6MT2dRjXB+5pHvwgn1zycjwN/a0L3u3JWFOZnfgnUsec0TbNE6/G+ 1jl+guWOEShwmFqLGXmJZrRkkw6RLsNKJkPmYIPKdQOGEU+F1MbazXZz/qYG903sMLb6 1DmKoBpaamc+zmG+qMex18wU26iudxqcBqRKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:references:to:from:in-reply-to; bh=HEH1+pU6MyW5CUJuMlaWZu4oHg1P9eYKQsLn+o2XHBg=; b=P2QqEVsbgyRqKNBgXdW9KzwBIXkIndUr/fpe+vuHqKcOO2yfxwB5+BUSDRgwyoSk2h BuoJB5J8M0ZC9jZZkI9Q2BpjfbKKvofKZyj3ams5NMxu8k/NUi/FObqOXn+Ilpc+aEYI hpyprAjVNtQdcUda6Jias/XN0sGXPtSELldSyeoEm1aAL58vmWBEQRxJaD7LsEFSquWU ffwE8kIyTM50pvNvdrCX/o/IzkULCCcmEpWJOLBPkwxdw8XA9Dd/tV7gVsZhyw7wgs+7 +cBqLAjr3CdB2tZ4vbNqB/9EdpVpaRk2KmeW/sjiOKx1yKlBNadShJSz0fBsi9MD+fwU MfWQ== X-Gm-Message-State: AOAM533hMeHZJ4ZHSF0cs7imFSevVYiWb+y+EIrA+190aKY2ZdaUMpB8 +VIxW3KKOTzYUF0uMwfbntSy/XutZYRCrNZO X-Google-Smtp-Source: ABdhPJzXgTIyHXOrxGkC7qWRGb0MPyO7TK1NbXlcEOiyCPjnPGeslr9uxhQ1IJJYpLdnfRPH6rCQ7A== X-Received: by 2002:a05:622a:1aa5:: with SMTP id s37mr717757qtc.410.1634657713767; Tue, 19 Oct 2021 08:35:13 -0700 (PDT) Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id x15sm1729942qkp.113.2021.10.19.08.35.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 08:35:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------i4cpDBQb000NDlw3QZ40WRYk" Message-ID: <82e7cf51-e53c-f01f-ffc3-db4d8197032a@cdt.org> Date: Tue, 19 Oct 2021 11:35:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0 Content-Language: en-US References: <0311a1ff-8ff9-d50f-db51-b6a4ca5e521c@cdt.org> To: e2ee@ietf.org, Adrian Farrel From: Mallory Knodel In-Reply-To: <0311a1ff-8ff9-d50f-db51-b6a4ca5e521c@cdt.org> X-Forwarded-Message-Id: <0311a1ff-8ff9-d50f-db51-b6a4ca5e521c@cdt.org> Archived-At: Subject: [E2ee] Fwd: Thoughts on draft-knodel-e2ee-definition X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of the definition of end-to-end encryption." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:35:23 -0000 This is a multi-part message in MIME format. --------------i4cpDBQb000NDlw3QZ40WRYk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, For the purposes of documenting progress on this draft, I'm forwarding this exchange to the list. Please feel free to comment, -Mallory -------- Forwarded Message -------- Subject: Re: Thoughts on draft-knodel-e2ee-definition Date: Fri, 7 May 2021 10:35:55 -0400 From: Mallory Knodel To: adrian@olddog.co.uk, draft-knodel-e2ee-definition@ietf.org Hi Adrian, Thanks very much for this early review! And apologies for taking so long to respond. More: On 2/23/21 5:46 AM, Adrian Farrel wrote: > Hi, > > My immediate thought when I saw your Abstract was, "What is an end?" > > So, congratulations on the valiant attempt in 2.1. However :-) > > I think you need to recognise two things... > > 1. A user is generally assumed to be a human being. You say, "It is now > widely accepted that the communication system itself begins and ends with > the user [RFC8890]. We imagine people (through an application's user > interface) as components in a subsystem's design." And that makes me think > that e2ee means user-to-user encryption, but (subtly) that is not what you > mean because you do not expect the user to type encrypted emails. I think > the thing that might help tease this out is to mention "communication > subsystems". That is, the data that is passed by the combination of > the user > and their applications to the communication subsystem should already be > encrypted. > > That said, I am not sure where something like IPsec sits in that model. > IPsec is part of the communication subsystem, but can clearly sit on the > user's device. Are you saying that IPsec is not a tool for e2ee? We pulled out a new section on end point, though it's hard to do without toggling back and forth between the relationship with the other end point, eg the e2e principle! I focus here on why we need to understand user expectations, a later section already. So thanks for contributing to the thinking around that. But I also put in your point about IPSec-- do we want to make sure our definition carries water for e2ee supporting protocols? IPSEc might also be solved by worrying about tunnels or no tunnels... > 2. You are, I think, missing the concept of tunnels. Tunnels have ends. > Tunnels are used to carry trusted traffic over untrusted environments. > Tunnels have "users" that are normally processes. Encryption on tunnels is > hugely important to how the Internet works. Now, that may not be what you > want to talk about in your document, and that's OK, but the feel > (partly by > you talking about end-to-end, and partly by the long preamble about BGP in > 2.1) is that it is in scope. Wondering if Fred or Olaf could jump in? I think I would say tunnels are indeed out of scope because it's transport encryption, but you're right that we talk about BGP. It's only in an attempt to elucidate the end point and e2e principle. Thoughts from my co-authors on squaring this circle? > > As an aside, I find section 4 to be mistitled. I think "desire" would be a > better word than "expectation". Unless you phrase this as "users have a > right to these expectation". Indeed, if a user truly expected things like > the provider being trustworthy, they would be far less inclined to use > e2ee: > it is the absence of guarantee of meeting any of these expectations that > drives the necessity of e2ee. Again-- it's now much more obvious why we need this section. I think we have to keep it somewhat rigorous, where desire is not as such more than expectation, and also it's increasingly an industry term in, say, the W3C. We're putting out a -01 in MLS, so please we welcome reviews there! Or here: https://github.com/mallory/e2ee/blob/main/draft-e2ee.md -Mallory > Anyway, just thinking. > > Adrian > > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------i4cpDBQb000NDlw3QZ40WRYk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi all,

For the purposes of documenting progress on this draft, I'm forwarding this exchange to the list.

Please feel free to comment,

-Mallory



-------- Forwarded Message --------
Subject: Re: Thoughts on draft-knodel-e2ee-definition
Date: Fri, 7 May 2021 10:35:55 -0400
From: Mallory Knodel <mknodel@cdt.org>
To: adrian@olddog.co.uk, draft-knodel-e2ee-definition@ietf.org


Hi Adrian,

Thanks very much for this early review! And apologies for taking so long to respond.

More:

On 2/23/21 5:46 AM, Adrian Farrel wrote:
Hi,

My immediate thought when I saw your Abstract was, "What is an end?"

So, congratulations on the valiant attempt in 2.1. However :-)

I think you need to recognise two things...

1. A user is generally assumed to be a human being. You say, "It is now
widely accepted that the communication system itself begins and ends with
the user [RFC8890]. We imagine people (through an application's user
interface) as components in a subsystem's design." And that makes me think
that e2ee means user-to-user encryption, but (subtly) that is not what you
mean because you do not expect the user to type encrypted emails. I think
the thing that might help tease this out is to mention "communication
subsystems". That is, the data that is passed by the combination of the user
and their applications to the communication subsystem should already be
encrypted.

That said, I am not sure where something like IPsec sits in that model.
IPsec is part of the communication subsystem, but can clearly sit on the
user's device. Are you saying that IPsec is not a tool for e2ee?

We pulled out a new section on end point, though it's hard to do without toggling back and forth between the relationship with the other end point, eg the e2e principle!

I focus here on why we need to understand user expectations, a later section already. So thanks for contributing to the thinking around that.

But I also put in your point about IPSec-- do we want to make sure our definition carries water for e2ee supporting protocols? IPSEc might also be solved by worrying about tunnels or no tunnels...

2. You are, I think, missing the concept of tunnels. Tunnels have ends.
Tunnels are used to carry trusted traffic over untrusted environments.
Tunnels have "users" that are normally processes. Encryption on tunnels is
hugely important to how the Internet works. Now, that may not be what you
want to talk about in your document, and that's OK, but the feel (partly by
you talking about end-to-end, and partly by the long preamble about BGP in
2.1) is that it is in scope.

Wondering if Fred or Olaf could jump in? I think I would say tunnels are indeed out of scope because it's transport encryption, but you're right that we talk about BGP. It's only in an attempt to elucidate the end point and e2e principle.

Thoughts from my co-authors on squaring this circle?


As an aside, I find section 4 to be mistitled. I think "desire" would be a
better word than "expectation". Unless you phrase this as "users have a
right to these expectation". Indeed, if a user truly expected things like
the provider being trustworthy, they would be far less inclined to use e2ee:
it is the absence of guarantee of meeting any of these expectations that
drives the necessity of e2ee.

Again-- it's now much more obvious why we need this section. I think we have to keep it somewhat rigorous, where desire is not as such more than expectation, and also it's increasingly an industry term in, say, the W3C.

We're putting out a -01 in MLS, so please we welcome reviews there!

Or here: https://github.com/mallory/e2ee/blob/main/draft-e2ee.md

-Mallory

Anyway, just thinking.

Adrian


-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------i4cpDBQb000NDlw3QZ40WRYk-- From nobody Tue Oct 19 08:44:31 2021 Return-Path: X-Original-To: e2ee@ietfa.amsl.com Delivered-To: e2ee@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F233A0062 for ; Tue, 19 Oct 2021 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 xRMaI8jz1lBg for ; Tue, 19 Oct 2021 08:44:23 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 447BC3A00D2 for ; Tue, 19 Oct 2021 08:44:23 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id n2so353246qta.2 for ; Tue, 19 Oct 2021 08:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:from:to :references:subject:in-reply-to:content-transfer-encoding; bh=70zVKVbphcvqruDr6cchvltF4dnd9VI8ohAVqpuEN3Y=; b=Kli4hvGTZMdETa/Zw0XBhkSURCZuZWqxKwnnbncUo15dtkmS8d9txf/6ZLxkQpFJvo ZqXFrLcyTKWiwoaCymKAIxduYTy9xFcRhPaAhmIKXVJ/hlbuoyk5LeG2bpKkhstWb/O0 mp7rk2vMfw2zX9z9BVpU5jB6K7FMI0l4STdaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:to:references:subject:in-reply-to :content-transfer-encoding; bh=70zVKVbphcvqruDr6cchvltF4dnd9VI8ohAVqpuEN3Y=; b=HufQO10sKkeeoWSkLzOKDnnAmpzimwTo1ncBFpw9MSXLzC4jlVIlMZ83pPavlEscfx v6kw+/Ilr/dXiHCJb2GlSkhWmmw4h5ZLsQFKQe9gdlchctg77/dAC5e7IsYa2y50qer7 /kTwZ03qedgon2cGcAHfeLvVZivDFT9D/yJ6Hn16gbc9biUM5u/AEkv+Y0OrBHU+xCsL 3Fx7wx5PqACsveSUQ9o4abDVy+BYPDmWJgxbbRKhYUPPHkMlTOyccAwvPMxbJHb+Yqtj JE9+elbOVHbXWWatkkJ6n2FnAywGyefENUfUXry6nd5lqTI8g9k75410fLZhSofM361Q R0qQ== X-Gm-Message-State: AOAM533/gmeulK8/zxnNAuFh/rnYtwWq7jCujhKmbJmaD5UfbBgQ3k67 9eYZb0VygYwY676NU3WFS527QKpkcDh177lv X-Google-Smtp-Source: ABdhPJwjtrWfwn46xjdHdSUOWY3lQ7pqHYGMSL5Q1mLgTL5oCso/wM6m4qHYBReEnypyKNNPipbt6w== X-Received: by 2002:ac8:47d4:: with SMTP id d20mr779549qtr.210.1634658262105; Tue, 19 Oct 2021 08:44:22 -0700 (PDT) Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id o13sm8230979qkl.102.2021.10.19.08.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 08:44:21 -0700 (PDT) Message-ID: Date: Tue, 19 Oct 2021 11:44:21 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0 Content-Language: en-US From: Mallory Knodel To: Matthew Finkel , e2ee@ietf.org References: <20210729141230.p62bwxrh6shysjkq@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [E2ee] Reducing Plaintext Metadata in E2EE Systems X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of the definition of end-to-end encryption." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:44:28 -0000 Hi Matthew, I added a section under Optional/desirable features that says: Metadata obfuscation: Steps should be taken to minimize metadata such as user obfuscating IP addresses, reducing non-routing metadata, and avoiding extraneous message headers can enhance the confidentiality and security features of E2EE systems. -Mallory On 7/29/21 10:27 AM, Mallory Knodel wrote: > Thanks a lot Matthew, > > I agree that this should be a goal. Not all of the features should or > could be part of every e2ee system, but the draft should demonstrate > the "trajectory" of where the technology goes ideally. > > Please do create a PR, I would be happy to review and merge. > > -Mallory > > On 7/29/21 10:12 AM, Matthew Finkel wrote: >> Hi all, >> >> This draft is very valuable, thanks to the authors for writing it. I'd >> like to call more attention to the importance of reducing plaintext >> metadata. The current draft contains: >> >>     Existing protocols are vulnerable to meta-data analysis, even though >>     meta-data is often much more sensitive than content. Meta-data is >>     plaintext information that travels across the wire and includes >>     delivery-relevant details that central servers need such as the >>     account identity of end-points, timestamps, message size. Meta-data >>     is difficult to obfuscate efficiently. >> >> The phrasing of this paragraph leads me to wonder if obfuscation of >> metadata should be included as a desirable feature. I don't mean to >> imply it's possible to eliminate leaking all metadata in all E2EE >> systems, but there is often some low-hanging fruit, like IP addresses or >> non-routing metadata, that an E2EE system can try to protect or >> obfuscate; e.g., MASQUE/OHTTP/Tor for IP addresses, and [0][1] for >> protecting some extraneous message headers. I can open a PR if this is >> helpful. >> >> Thanks, >> Matthew Finkel >> >> [0] >> https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers >> [1] https://signal.org/blog/sealed-sender/ >> -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Tue Oct 19 08:58:48 2021 Return-Path: X-Original-To: e2ee@ietfa.amsl.com Delivered-To: e2ee@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D073A0949 for ; Tue, 19 Oct 2021 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 FMWIE3WAOSki for ; Tue, 19 Oct 2021 08:58:41 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 2DC893A093A for ; Tue, 19 Oct 2021 08:58:41 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id i1so380619qtr.6 for ; Tue, 19 Oct 2021 08:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to; bh=w+KyGPyxoUEWj2fObKIIIBCK1hTcUHG1k32147r7H7Q=; b=Nan8VLuWp0qGA8UECz83zoHEBjcMrCR5ptbHjrMj/OsZFuZSkMrn6Qv7itBKbIoNZk AKOaN0rOpfoQN6NUA3XZiQv8L5B763ZxRM1bUvFuJcG5egK2h1CroaoMqxE/UahojNOq LMpD+8HVMlnlrraFJMbDD2eNRwyVu4css7Tig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to; bh=w+KyGPyxoUEWj2fObKIIIBCK1hTcUHG1k32147r7H7Q=; b=LDbGnmls1DKfrqKGK3PzPov6ocm8gSZxccTvSd2fXxAW7NjlVNz9grcMWoJxkw2XbC pU586OW1k85glRYUWsCZ7m3E1414SBI8u85HKYI25+9As8Tx7NKQOXSGJFoAwLReqRz6 v3ldY0aTvzHxqksydVDa3n1Y8eWrXj3PzMBBsSMLcN9NtoqIR6BEWkpwYFoiA4SD9V+v YaoQthyB1PgvCXxhALCEAtIb7glB5RM7+KQeNfntGdvd0MVFDhstrwPIPBprsR53VAa3 hwYgeotS7wy30Qxv9uAHXmgfrqiRrUUznMhuwfltLpXXI2UkKNlL0aeJxbjIfwjJVZEp IIQA== X-Gm-Message-State: AOAM530HtWrvzcD2D/nc8WE26LP9pDoYS1PZs46HeMjTTzYcOds4mD9j 6U4Oo+Pfy3Pq9aVimbbbkP+0CQ== X-Google-Smtp-Source: ABdhPJz9D0nK24pb4bSwCml9KzbykHVVdpZ0ggcylmcjKqyYEwL5vVuFZkvyUOSdzGWdkHuFQOUvcA== X-Received: by 2002:a05:622a:ce:: with SMTP id p14mr862457qtw.164.1634659119770; Tue, 19 Oct 2021 08:58:39 -0700 (PDT) Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id p11sm3661651qtw.60.2021.10.19.08.58.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 08:58:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------8xRSNsdP0UmjxhlRJcuCWkdm" Message-ID: <4bf8dcc0-ac1e-5a01-e5cb-926ca68d9149@cdt.org> Date: Tue, 19 Oct 2021 11:58:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0 Content-Language: en-US To: Eric Rescorla , e2ee@ietf.org References: From: Mallory Knodel In-Reply-To: Archived-At: Subject: Re: [E2ee] [Secdispatch] Comments on draft-knodel-e2ee-definition-02 X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of the definition of end-to-end encryption." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:58:46 -0000 This is a multi-part message in MIME format. --------------8xRSNsdP0UmjxhlRJcuCWkdm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eric, Thanks for this review. I've moved discussion from secdispatch to the new list. Some responses: On 7/26/21 7:07 PM, Eric Rescorla wrote: > > Specifically, it seems to me that it's quite hard to talk about E2EE > as an abstract property, because what's E2EE in one context (my TLS > connection to Gmail) is not E2EE in another context (the email that I > am reading that was sent to Gmail). I think what I would do instead > is: > We're aiming for both ends to be people, not services. > 1. Provide a generic definition of what E2EE encryption means >    assuming the endpoints are defined (something like 3.1.) > By generic do you mean "textbook" or "formal"? It's built up to in 2.3, but we've attempted to bring it forward in the abstract. > 2. Examine some specific cases of system types, such as >    (1) network connections (e.g., TLS) (2) e-mail and (3) messaging >    such as MLS and describe what we should view as the endpoints >    and the limitations of trying to provide E2E in those >    contexts. > 2 and 3 seem within scope. If we go the route of identifying system types I'd like to add video/synchronous streaming to the list. > I would also note that there are other ways to be E2E that > are not just "E2E encrypted". For instance, DNSSEC provides > end-to-end authentication/integrity. Another example would > be "E2E" voting systems. > I don't think these are in scope. > > OVERALL > It seems to me that the most difficult problem here is that being > E2EE isn't an absolute property but one that applies with respect > to a certain set of endpoints. As an example, if I use HTTPS to > search with Google, that's arguably E2E encrypted to Google. If > I used HTTPS to read my email, though, we don't think that's E2EE > (absent S/MIME, obviously). So I think you need to treat this more > of a relation and then talk about some common cases and who we > should view as the communications endpoints. > > >    End-to-end encryption (E2EE) is an application of cryptography in >    communications systems between endpoints.  E2EE systems are unique in >    providing features of confidentiality, integrity and authenticity for >    users.  Improvements to E2EE strive to maximise the system's security >    while balancing usability and availability.  Users of E2EE >    communications expect trustworthy providers of secure implementations >    to respect and protect their right to whisper. > > This last sentence seems weirdly hortatorial. I would stick to > the technical points. > We include this last section on users because I think the formal definition (section 2) and the functional definition (section 3) need to consider what the user expects. > > DETAILED > S 2.1. >    However despite the nuance for engineers, it is now widely accepted >    that the communication system itself begins and ends with the user >    [RFC8890].  We imagine people (through an application's user >    interface, or user agent) as components in a subsystem's design.  An >    important exception to this in E2EE systems might be the use of >    public key infrastructure where a third party is often used in the >    authentication phase to enhance the larger system's trust model. >    Responsible use of of public key infrastructure is required in such >    cases, such that the E2EE system does not admit third parties under >    the user's identity. > > I don't understand this point at all. The third parties aren't > communications endpoints. It's incredibly common to have "e2e" systems > which have third parties such as CAs. > If not "third party" for key servers, what could we say here? > >    We cannot equate user agent and user, yet we also cannot fully >    separate them.  As user-agent computing becomes more complex and >    often more proprietary, the user agent becomes less of an "advocate" >    for the best interests of the user. > > This seems like it needs to be supported, or perhaps just omitted. > This gets at what I mean but it focuses on browsers: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3827421. > > S 2.2. > >    identity and end identity.  This creates a tree hierarchy with the >    end user as the root at the top, and all potential end points being >    under their direct control, without third party access.  As an > > This seems far more strict than is possible. Consider the case of > a piece of software which allows for remote updates. Does that > mean it is not capable of doing E2EE? Even if we assume BT and > reproducible builds, it still would not meet this definition > because there is third-party access. > Update doesn't sound like "third party access" to messaging functionality to me. > > S 2.3. > This seems oddly detailed. The question of whether authentication > is symmetric or asymmetric or whether there is a ratched doesn't > define if something is E2EE. > >    The adversary successfully subverts an end-to-end encrypted system if >    it can succeed in either of the following: 1) the adversary can >    produce the participant's local state (meaning the adversary has >    learned the contents of participant's messages), or 2) the states of >    conversation participants do not match (meaning that the adversary >    has influenced their communication in some way).  To prevent the >    adversary from trivially winning, we do not allow the adversary to >    compromise the participants' local state. > >    We can say that a system is end-to-end secure if the adversary has >    negligible probability of success in either of these two scenarios >    [komlo]. > > I'm not sure if this is intended to be a formal definition, but > it seems to me that it has a number of edge cases which are > problematic: > > 1. Consider the case where I persuade you to install a new E2E >    messenger and then send you a message. At this point, I know >    your state, but presumably I have not violated the defn. > > 2. Consider the case where A sends a message to B but I succeeed >    in blocking that message by (for instance) jamming B's network. >    In this case, the states don't match, but again we wouldn't >    say E2EE was violated. Chelsea-- thoughts? > > > S 3.1.1. > I of course agree with these features, but I feel like they > need to come with some sort of definition of the endpoints > and who it is you trust. To take some examples: > I think that we are only considering ends as people, which is how it should read in the abstract and first section. > - I think we agree that TLS between me and Google is E2EE, >   right? But actually, with Google I connect to GFE which >   then decrypts the data. > > - I think we would also agree that TLS between me and Google >   is not E2EE if there is a MITM proxy. But what feature >   out of this CIA list is it missing? > > - When I connect to a site which is fronted by a CDN, >   is that E2EE? Maybe? > > > S 3.1.2. > I feel like the / in "optional/desirable" is doing a lot of work > here. There are contexts in which "deniable" is important but > also ones in which "undeniable" is important! More generally, > Availability, FS, and PCS seem desirable whether we are end-to-end > or not. > Agree! I'd like a better title for that section. > S 3.2. > I would strike all of this. It's too specific to a particular > set of systems and not really helpful to a definition. > It helps to define the trajectory of where development might go. Solving those hard problems might not be featurified yet, but it should be! > S 4.1. > I agree that "a conversation is confidential" is a good thing > to happen, but it's out of step with the rest of this document > to root it in 7624 or human rights. Let's just stick to > technical points here. > Let's keep it for now because it's the best section we have for the user expectations section. We can consider later if the third piece of the definition trifecta is going to work ultimately. > > S 4.3. >    message is sent to the recipient" [GEC-EU].  Third party access also >    covers cases without scanning - namely, it should be possible for any >    third-party end point to access the data regardless of reason. > > I assume you mean "not"? > > Thanks! -Mallory > > > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------8xRSNsdP0UmjxhlRJcuCWkdm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Eric,

Thanks for this review.

I've moved discussion from secdispatch to the new list.

Some responses:

On 7/26/21 7:07 PM, Eric Rescorla wrote:

Specifically, it seems to me that it's quite hard to talk about E2EE
as an abstract property, because what's E2EE in one context (my TLS
connection to Gmail) is not E2EE in another context (the email that I
am reading that was sent to Gmail). I think what I would do instead
is:

We're aiming for both ends to be people, not services.
1. Provide a generic definition of what E2EE encryption means
   assuming the endpoints are defined (something like 3.1.)

By generic do you mean "textbook" or "formal"? It's built up to in 2.3, but we've attempted to bring it forward in the abstract.
2. Examine some specific cases of system types, such as
   (1) network connections (e.g., TLS) (2) e-mail and (3) messaging
   such as MLS and describe what we should view as the endpoints
   and the limitations of trying to provide E2E in those
   contexts.

2 and 3 seem within scope. If we go the route of identifying system types I'd like to add video/synchronous streaming to the list.

I would also note that there are other ways to be E2E that
are not just "E2E encrypted". For instance, DNSSEC provides
end-to-end authentication/integrity. Another example would
be "E2E" voting systems.

I don't think these are in scope.

OVERALL
It seems to me that the most difficult problem here is that being
E2EE isn't an absolute property but one that applies with respect
to a certain set of endpoints. As an example, if I use HTTPS to
search with Google, that's arguably E2E encrypted to Google. If
I used HTTPS to read my email, though, we don't think that's E2EE
(absent S/MIME, obviously). So I think you need to treat this more
of a relation and then talk about some common cases and who we
should view as the communications endpoints.


   End-to-end encryption (E2EE) is an application of cryptography in
   communications systems between endpoints.  E2EE systems are unique in
   providing features of confidentiality, integrity and authenticity for
   users.  Improvements to E2EE strive to maximise the system's security
   while balancing usability and availability.  Users of E2EE
   communications expect trustworthy providers of secure implementations
   to respect and protect their right to whisper.

This last sentence seems weirdly hortatorial. I would stick to
the technical points.

We include this last section on users because I think the formal definition (section 2) and the functional definition (section 3) need to consider what the user expects.


DETAILED
S 2.1.
   However despite the nuance for engineers, it is now widely accepted
   that the communication system itself begins and ends with the user
   [RFC8890].  We imagine people (through an application's user
   interface, or user agent) as components in a subsystem's design.  An
   important exception to this in E2EE systems might be the use of
   public key infrastructure where a third party is often used in the
   authentication phase to enhance the larger system's trust model.
   Responsible use of of public key infrastructure is required in such
   cases, such that the E2EE system does not admit third parties under
   the user's identity.

I don't understand this point at all. The third parties aren't
communications endpoints. It's incredibly common to have "e2e" systems
which have third parties such as CAs.

If not "third party" for key servers, what could we say here?

   We cannot equate user agent and user, yet we also cannot fully
   separate them.  As user-agent computing becomes more complex and
   often more proprietary, the user agent becomes less of an "advocate"
   for the best interests of the user.

This seems like it needs to be supported, or perhaps just omitted.

This gets at what I mean but it focuses on browsers: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3827421.

S 2.2.

   identity and end identity.  This creates a tree hierarchy with the
   end user as the root at the top, and all potential end points being
   under their direct control, without third party access.  As an

This seems far more strict than is possible. Consider the case of
a piece of software which allows for remote updates. Does that
mean it is not capable of doing E2EE? Even if we assume BT and
reproducible builds, it still would not meet this definition
because there is third-party access.

Update doesn't sound like "third party access" to messaging functionality to me.

S 2.3.
This seems oddly detailed. The question of whether authentication
is symmetric or asymmetric or whether there is a ratched doesn't
define if something is E2EE.

   The adversary successfully subverts an end-to-end encrypted system if
   it can succeed in either of the following: 1) the adversary can
   produce the participant's local state (meaning the adversary has
   learned the contents of participant's messages), or 2) the states of
   conversation participants do not match (meaning that the adversary
   has influenced their communication in some way).  To prevent the
   adversary from trivially winning, we do not allow the adversary to
   compromise the participants' local state.

   We can say that a system is end-to-end secure if the adversary has
   negligible probability of success in either of these two scenarios
   [komlo].

I'm not sure if this is intended to be a formal definition, but
it seems to me that it has a number of edge cases which are
problematic:

1. Consider the case where I persuade you to install a new E2E
   messenger and then send you a message. At this point, I know
   your state, but presumably I have not violated the defn.

2. Consider the case where A sends a message to B but I succeeed
   in blocking that message by (for instance) jamming B's network.
   In this case, the states don't match, but again we wouldn't
   say E2EE was violated.
Chelsea-- thoughts?


S 3.1.1.
I of course agree with these features, but I feel like they
need to come with some sort of definition of the endpoints
and who it is you trust. To take some examples:

I think that we are only considering ends as people, which is how it should read in the abstract and first section.


- I think we agree that TLS between me and Google is E2EE,
  right? But actually, with Google I connect to GFE which
  then decrypts the data.

- I think we would also agree that TLS between me and Google
  is not E2EE if there is a MITM proxy. But what feature
  out of this CIA list is it missing?

- When I connect to a site which is fronted by a CDN,
  is that E2EE? Maybe?


S 3.1.2.
I feel like the / in "optional/desirable" is doing a lot of work
here. There are contexts in which "deniable" is important but
also ones in which "undeniable" is important! More generally,
Availability, FS, and PCS seem desirable whether we are end-to-end
or not.

Agree! I'd like a better title for that section.
S 3.2.
I would strike all of this. It's too specific to a particular
set of systems and not really helpful to a definition.

It helps to define the trajectory of where development might go. Solving those hard problems might not be featurified yet, but it should be!
S 4.1.
I agree that "a conversation is confidential" is a good thing
to happen, but it's out of step with the rest of this document
to root it in 7624 or human rights. Let's just stick to
technical points here.

Let's keep it for now because it's the best section we have for the user expectations section. We can consider later if the third piece of the definition trifecta is going to work ultimately.

S 4.3.
   message is sent to the recipient" [GEC-EU].  Third party access also
   covers cases without scanning - namely, it should be possible for any
   third-party end point to access the data regardless of reason.

I assume you mean "not"?


Thanks!

-Mallory


  




_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------8xRSNsdP0UmjxhlRJcuCWkdm-- From nobody Tue Oct 19 10:54:08 2021 Return-Path: X-Original-To: e2ee@ietfa.amsl.com Delivered-To: e2ee@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C324E3A08ED for ; Tue, 19 Oct 2021 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 ko6_FobQxgpF for ; Tue, 19 Oct 2021 10:54:01 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 7EB543A08EB for ; Tue, 19 Oct 2021 10:54:00 -0700 (PDT) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4HYhFL26nrzDrhG; Tue, 19 Oct 2021 10:53:58 -0700 (PDT) X-Riseup-User-ID: 59CBEEC4919343F3AC686D688485E7764818AF1B5AE29BA1F23CDC91072BDA6E Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4HYhFF5vd5z1yW8; Tue, 19 Oct 2021 10:53:52 -0700 (PDT) Date: Tue, 19 Oct 2021 17:53:46 +0000 From: Matthew Finkel To: Mallory Knodel Cc: e2ee@ietf.org Message-ID: <20211019175346.jum267c5wwz7syyc@localhost> References: <20210729141230.p62bwxrh6shysjkq@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [E2ee] Reducing Plaintext Metadata in E2EE Systems X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of the definition of end-to-end encryption." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 17:54:06 -0000 Hi Mallory, That's great, thank you! I apologize for dropping this. Thanks, Matthew On Tue, Oct 19, 2021 at 11:44:21AM -0400, Mallory Knodel wrote: > Hi Matthew, > > I added a section under Optional/desirable features that says: > > Metadata obfuscation: Steps should be taken to minimize metadata such as > user obfuscating IP addresses, reducing non-routing metadata, and avoiding > extraneous message headers can enhance the confidentiality and security > features of E2EE systems. > > -Mallory > > On 7/29/21 10:27 AM, Mallory Knodel wrote: > > Thanks a lot Matthew, > > > > I agree that this should be a goal. Not all of the features should or > > could be part of every e2ee system, but the draft should demonstrate the > > "trajectory" of where the technology goes ideally. > > > > Please do create a PR, I would be happy to review and merge. > > > > -Mallory > > > > On 7/29/21 10:12 AM, Matthew Finkel wrote: > > > Hi all, > > > > > > This draft is very valuable, thanks to the authors for writing it. I'd > > > like to call more attention to the importance of reducing plaintext > > > metadata. The current draft contains: > > > > > >     Existing protocols are vulnerable to meta-data analysis, even though > > >     meta-data is often much more sensitive than content. Meta-data is > > >     plaintext information that travels across the wire and includes > > >     delivery-relevant details that central servers need such as the > > >     account identity of end-points, timestamps, message size. Meta-data > > >     is difficult to obfuscate efficiently. > > > > > > The phrasing of this paragraph leads me to wonder if obfuscation of > > > metadata should be included as a desirable feature. I don't mean to > > > imply it's possible to eliminate leaking all metadata in all E2EE > > > systems, but there is often some low-hanging fruit, like IP addresses or > > > non-routing metadata, that an E2EE system can try to protect or > > > obfuscate; e.g., MASQUE/OHTTP/Tor for IP addresses, and [0][1] for > > > protecting some extraneous message headers. I can open a PR if this is > > > helpful. > > > > > > Thanks, > > > Matthew Finkel > > > > > > [0] https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers > > > [1] https://signal.org/blog/sealed-sender/ > > > > -- > Mallory Knodel > CTO, Center for Democracy and Technology > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > -- > E2ee mailing list > E2ee@ietf.org > https://www.ietf.org/mailman/listinfo/e2ee