Re: [MLS] Functional Definition of End-to-End Secure Messaging

[Raphael Robert <[e-mail]>]

> On 7. May 2021, at 14:13, Alec Muffett <[e-mail]> wrote:
> 
> Hey Raphael!
> 
> Those are great questions, and I have already updated the draft to address the latter one, but will paste the explanation here, too.
> 
> On Fri, 7 May 2021 at 09:40, Raphael Robert <[e-mail] <mailto:[e-mail]>> wrote:
> Thanks for sharing!
> You mention the prior art by Knodel et al. at the end and I’m wondering if it wouldn’t be a better starting point for discussion? 
> Especially since it has the advantage of building upon notions that are well-defined and established in the industry.
> 
> I feel that there need to be two separate approaches; draft-knodel-e2ee-definition-00 focuses deeply upon platform "goals" qualitative provision of end-to-end encryption solutions, rather than to specify what is necessary for an end-to-end secure (via client-server-centric encryption, or otherwise) messenger solution to be worthy of the (currently ill-defined, but widely used) terminology.  It describes "scanning" rather what the effects of "scanning" would look like; it describes "not allowing pattern inference" but remains open to someone redefining what "inference" means, as opposed to leveraging "indistinguishability" for a concrete definition. 

I agree that the two drafts a quite different. Yours is much more specific in certain aspects. And this is where it also gets tricky :)
Dave has a good point that it might not be straight forward to have a “one-size-fits-all” model. draft-knodel-e2ee-definition-00 is much broader could certainly be expanded to include more precise definitions to illustrate the more abstract notions. Just having fixed set of precise criteria sounds nice in terms of simplicity but might simply prove to be insufficient to capture all valid use cases.
In either case, having a document that can be used as a checklist to determine with absolute certainty whether a system is end-to-end-encrypted or not sound like a dangerous endeavour. Given the complexity of the subject, the answer cannot always be binary.

When you say “ill-defined, but widely used terminology”, what exactly are you referring to? Statements in the press? What exact problem needs fixing here? Having a bit more context on that would certainly help with the overall assessment. Maybe we are just talking past each other.

> 
> There is a lot of overlap, but in the end https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5 <https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5> leaves the applied definition of E2E-Encryption somewhat open, whereas draft-muffett-end-to-end-secure-messaging-00 is essentially a long and nitpicky way of saying "If you're gonna call something end-to-end secure, here is what 'end' means, and you will need to respect your ends."
> 
> Obviously with enough discussion and rewriting it would be possible to somewhat merge the two documents, but since they take separate routes towards addressing the matter, I am inclined to see both go forward and see how their utility compares.
> 
>  
> I’m also still struggling with your definition of a “backdoor” in 4.4:
> ...
> You previously mentioned that intent is hard to measure and I agree with that. But I’m quite convinced a design or implementation flaw shouldn’t be called a “backdoor” until there is sufficient proof of intent. If you call it a “backdoor” right from the beginning, most people will assume that intent was there.
> This would be very discouraging for everyone who contributes to E2EE protocols, because it introduces the risk of being stigmatised as someone with (criminal) intent just because an honest mistake was made. Long story short, I strongly reject that notion of a “backdoor” for being intimidating.
> 
> 
> I hear that you are worried about pejorative stigma of terminology, so let me share the rationale that I've just added to the draft:
> 
> In software engineering there is a perpetual tension between the concepts of "feature" versus "bug" - and occasionally "misfeature" versus "misbug". These tensions arise from the problem of [DualUse] - that it is not feasible to firmly and completely ascribe "intention" to any hardware or software mechanism.
> The information security community have experienced a historical spectrum of mechanisms which have assisted non-participant access to PCASM. These have variously been named as "export-grade key restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and Meltdown), "law enforcement access fields" (Clipper), and "key escrow" (Crypto Wars).
> All of these terms combine an "access facilitation mechanism" with an "intention or opportunity" - and for all of them an access facilitation mechanism is first REQUIRED.
> An access facilitation mechanism is a "door", and is inherently [DualUse]. Because the goal of E2ESM is to limit access to PCASM exclusively to a defined set of participants, then the intended means of access is clearly the "front door"; and any other access mechanism is a "back door".
> If the term "back door" is considered innately pejorative, alternative, uncertain constructions such as "illegitimate access feature", "potentially intentional data-access weakness", "legally-obligated exceptional access mechanism", or any other phrase, all MUST combine both notions of an access mechanism (e.g. "door") and a definite or suspected intention (e.g. "legal obligation").
> So the phrase "back door" is brief, clear, and widely understood to mean "a secondary means of access". In the above definition we already allow for the term to be prefixed with "intentional" or "unintentional".
> Thus it seems appropriate to use this term in this context, not least because it is also not far removed from the similar and established term "side channel".
>  
> ...and to call out that last point, I find it particularly interesting to compare "back door" to "side channel"; to me, neither are particularly stigmatic until combined with an adjective to describe "intent".
> 
> I have a back door in my house.  It's not inherently evil.

Whoever built the back door to your house hopefully did so with full intent :) This is precisely where I see the problem: doors are mechanisms built with full intent to enter a building/room. If the building/room can also be entered because the walls were not made thick enough (intentionally or unintentionally), we wouldn’t call this a door. So only when there is a strong suspicion of intent (preferably evidence), something should be called a door. I simply cannot convince myself that a door can be something that is built unintentionally. Hence the risk of stigma.
But maybe I just have an unusual understanding of what a door is. I would love to hear other opinions on this.

Raphael

>  
>     - alec
> 
> -- 
> https://alecmuffett.com/about <https://alecmuffett.com/about>
>