Re: [CFRG] A Duck Test for End-to-End Secure Messaging: "Video Deck" on YouTube

Martin Thomson <mt@lowentropy.net> Fri, 30 July 2021 03:02 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E133A178F for <cfrg@ietfa.amsl.com>; Thu, 29 Jul 2021 20:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=RUXqaUvw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XM0s35ZN
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 LVwUIC0horGb for <cfrg@ietfa.amsl.com>; Thu, 29 Jul 2021 20:02:37 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0833A178E for <cfrg@irtf.org>; Thu, 29 Jul 2021 20:02:37 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0C96A5C00EB for <cfrg@irtf.org>; Thu, 29 Jul 2021 23:02:33 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Thu, 29 Jul 2021 23:02:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=G2kOMlJ1/FRezrBRnbnB6AIJqzSgHVk 5I0r3XZAlkVM=; b=RUXqaUvwgy2xz463p3fZ/yOn0I2N9v2OyMoshxEv5IKsV+h 7S0pqCwGdua2j/xdmUpFCdRj3wZrqcgOEarHGsxc/1fpTUOO1YZLJPEUCxMluZXY qmQfxu5ZJBMKF7Q5/lYaWkDLZnKaQzow/ZMfMaQFwciUGYQs66sZDVLodnWLjpm1 02OGxO4lf2idsSTKtKfUdDuT7HlDlJet+2n35Gr6K5CMPwA5P1AvZh7uNnh80Xmn f8W3aphu0/kAPB0Vu/T7o6TACRdKx+aVQ7LLX41TwASlFhM5tn8Z55o+4UIcj42G CsVif5o66AFGM5Jxrf3TbWgNd138BEpOhwsVEPQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=G2kOMl J1/FRezrBRnbnB6AIJqzSgHVk5I0r3XZAlkVM=; b=XM0s35ZNrhj2dgLDWtDFRp OSwqoUdnaArOUDunTbnWBQUjenxjaHg3B96bMaWdr7r/44ffsAJrKpejLMwESntf QSxFcSuua9Vd+qK7aBFpwT6DWy7OJTjGqbio/F6XMCOuoIvgiMdK7ZgRIddpnqzf RneLDGK6sFAcyPNIXmPufOp8l7cZJCNh+1liZKSmlEfhnRp/nl2N7viAouMZ6Jl7 KAuEjzBYIRT1pNpg/ML84ZzSZJz6+SXWGv8ISGhNLsmGGVNc5wQhPMDz8fxt6fw6 //Nij37WLQQLRJRb72sHrF/pewJIrzV4n6n3JMQ/9jkg1U/ZnR80vl3Bd7mwS9YA ==
X-ME-Sender: <xms:yGsDYZNHDJP-MtraaLX_VK85aesZU1vdOBuA3QKNFjirQYL0Lg6jMA> <xme:yGsDYb-nAmJ0mA-aRjYfxEkGT0FFcLvWMxjlwwjRqEuGTy623KA5QcHIIW1A6pz1g ubGNwqOAG_XVeuq4gI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeggdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepleeuteejheehhfelfeetff eikeektdduledtueeujeejjeekudekheehvdffffegnecuffhomhgrihhnpeihohhuthhu sggvrdgtohhmpdhivghtfhdrohhrghdpghhithhhuhgsrdgtohhmpdgrlhgvtghmuhhffh gvthhtrdgtohhmpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:yGsDYYReS1t6T__ZSw-RYXusP6dIaI3jTZPYGqE6MOL9z3uFXZN0pA> <xmx:yGsDYVtClXTyyafzK5Uczf8Qy5PTtgf5totYnNwIDf6MFJQxufUWpg> <xmx:yGsDYRfHUg87A5HhmzSJYe478RbVL2gcNIM3qHbOJZJp5GCVZKZEjA> <xmx:yWsDYbrxmMaXQTTDOXu6szY3gkS15YQy5dQMw6DL74oxfT_eai7Pew>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A291E3C0471; Thu, 29 Jul 2021 23:02:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54
Mime-Version: 1.0
Message-Id: <dbe856cb-34ec-4f52-b849-5c696f574dc9@www.fastmail.com>
In-Reply-To: <CAFWeb9LrJZcMw-8nfwkwsJ-0uZCwPqe4TviAbLPZHDjeSJZbmA@mail.gmail.com>
References: <CAFWeb9LrJZcMw-8nfwkwsJ-0uZCwPqe4TviAbLPZHDjeSJZbmA@mail.gmail.com>
Date: Fri, 30 Jul 2021 13:02:04 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: cfrg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/3HyACdtNcf512Qe0pNRIXqkyhpk>
Subject: Re: [CFRG] =?utf-8?q?A_Duck_Test_for_End-to-End_Secure_Messaging=3A_?= =?utf-8?q?=22Video_Deck=22_on_YouTube?=
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 03:02:43 -0000

Hi Alec,

Thanks for putting this together.  It's an excellent presentation.  (Though I do encourage you to try to avoid playing a video if you can manage to be available for the meeting.)

When I first saw your slides, I was concerned about the large number of them, but your video laid those concerns largely to rest.  Perhaps in the interest of brevity and conciseness, you could skip the Nit (1-8) slides and just reserve them as backup material in case of questions.  That seems to be about half of your talking time in the video and would let us focus on your key point.

I do think that this is the right test.  It's clear and understandable and captures what I think is the essence of the problem -- at the right level.  Mostly...

Three high-level points that I think we need to have clear answers to:

1. Your restriction of this to messaging only is, I think, the only thing I truly disagree with in terms of high level goals.  I believe that this test applies equally well to all forms of communication.  Messaging is a very important use case, but I don't see how this test would not apply to anything the IETF produces (RFCs 1984, 2804, 3552, 7258, and more being all consistent with the concept as you define it).

2. I like that this doesn't try to mandate policy either.  It should not.  It doesn't attempt to say that the IETF needs to produce e2e protected protocols.  That's why I think we should avoid talking about what happens on the endpoints in this work.  I think that it would be a bad idea to enter that space.  In your presentation, Slide 38 in particular steps over that line and I would skip straight to 39.

3. The hard one.  This test depends on some very key assumptions about the nature of the endpoint TCB.  Let me give you an example: there are claims that sframe produces e2e protection (see the working group of the same name for reference).  In that design, web sites send javascript to endpoints that is executed by a browser.  The javascript, not the browser, is responsible for encryption, decryption, and key management.  If we consider the javascript as part of the TCB, then your definition applies; if we do not, then it all breaks down.

This last item highlights a general problem: in many messaging systems, the software that provides protection, the servers, the key management, the authentication systems, and even the protocols involved are all under the control of the same entity.  That entity is generally not included in the set of intended recipients, but they clearly have the power to access the content of messages, should they modify the necessary components.

You do address this in the sense that you assume the RFC 3552 condition that the endpoint is not compromised.  I think it is worth recognizing that e2e protections like this are often voluntary on the part of system designers.  When they are voluntary, there are still benefits, but not necessarily guarantees.  Often this also relies on operational security practices to provide real outcomes, like ensuring that the team that looks after the servers that forward messages do not have the means to push client updates or to make changes to authentication servers.  

This was not historically as much of an issue if you assume standardized protocols and independent client implementation, but it is a real concern here.  Either way, making a better distinction about what the TCB is can be critical to understanding where the lines are.   As I hinted at, the TCB also extends beyond the client as it often includes external dependencies for things like trust anchors.  That too will need to be acknowledged and handled carefully.

(To answer my own question from before, I tend to think that sframe as described above does not fit the definition on these terms, but it could with some minor adjustments. To be clear, we're working on those too.)

I have some concerns about the document as it is.  I think we should concentrate on these high-level topics first.  I'd be happy to contribute to work in this area.

Thanks again,
Martin

On Fri, Jul 30, 2021, at 11:42, Alec Muffett wrote:
> Hi All,
> 
> I will be presenting "draft-muffett-end-to-end-secure-messaging" 
> tomorrow at the CFRG meeting*, but my slide deck is packed, it will be 
> late in the evening in the UK, I'm sleep-deprived from a new baby, and 
> my experience of Meetecho so far has involved rather a lot of lag.
> 
> So I thought I would put in some effort up-front and entirely spoiler 
> myself. Attached is a YouTube video with my entire slide deck for 
> tomorrow, and voiceover, running for 9:42s, so at least in theory it is 
> possible for me to run to time.
> 
> https://www.youtube.com/watch?v=QmL9HYywrHg
> 
> I am sharing the video openly, and depending on "tech" I may try 
> showing it tomorrow, reusing the audio, or else I may attempt to "wing 
> it" and repeat it verbatim, live; but if you're enthusiastic about the 
> draft, you're hereby invited to prep your slings and arrows by watching 
> the video beforehand.
> 
> Datatracker: 
> https://datatracker.ietf.org/doc/draft-muffett-end-to-end-secure-messaging/
> Github: 
> https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/
> 
> Best wishes, and I welcome your feedback.
> 
>     - alec
> 
> * https://datatracker.ietf.org/meeting/111/materials/agenda-111-cfrg-04
> 
> --
> https://alecmuffett.com/about
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>