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

[Alec Muffett <[e-mail]>]

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]> 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.

There is a lot of overlap, but in the end
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.

    - alec

-- 
https://alecmuffett.com/about