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

Alec Muffett <> Fri, 30 July 2021 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15B743A188D for <>; Thu, 29 Jul 2021 20:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m_NGuUdBhEg4 for <>; Thu, 29 Jul 2021 20:30:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1A483A1887 for <>; Thu, 29 Jul 2021 20:30:45 -0700 (PDT)
Received: by with SMTP id az7so8145747qkb.5 for <>; Thu, 29 Jul 2021 20:30:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pglpITiNICAdRdkFRb9/F9uGEhuZ+MpwbW0xhgtTgb0=; b=Oq07cTNCDe9hyHSdbRzBMMZ5aMYoKvkqU0dmfivg9AkzEY8GqBwHBiKwoum9uOCsxs PBOvHS1noSJvG1XZGYP70sR9Cug371b9J2qY6AF1k2cD5wRbIR9WsAh0aPrpCmexm2pO gH4r/qbf9MB5cWJHgaZDHfdBSbwIbcGm2Dl5JxgdGXbnKC3udpKRp7HlRdgDQz0mKW8u kt7lfKsmyqOcw1TwLIuGWRqnuISImpzoQhjH8ica84Qp8VyUI20QNZXf1GcSnEM+3tc7 VUuTffy7RDD1r6MnkXmlX2ne0U8ADB2/h1TZ32bU2BFiuFw53VXJpRMZCY1NvSm5jlB1 mIIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pglpITiNICAdRdkFRb9/F9uGEhuZ+MpwbW0xhgtTgb0=; b=XUAD3m4e2+mcjV7fIRhFGEsZIXLSXUDtDUb1NkM1ka/OX3Y8HxS+6r5QRp6oQTMmiY HSegbBog84sB3KqOnVPNSyfp8UHKbjcrni0AoQVjuWkVLJbllZ/OjDSfWcoimeUblijY qv1nhBtEk91Jxj6HB9D1Et0DTp3JpTncq49KpH4UhDeSCrAB7wnXuuqBzlmN4ZfR7xhM 1FU9qBGyAzVRa8RGbmydM0K4mc53JskEEtBDH45lIn1e4I2YmALlZel//sNGNP4ykUHI 8P2jE57UpHepaDOS7HD/rsqzrqNmZ+trdENp2eGyHFxPhy82j/wktBjqO8KFPZeKliCU +HNA==
X-Gm-Message-State: AOAM530Eykj0JWp/4SSq/8nkyqyeJ4zWsSuKW+4zxr9Ub6b5ihTUuv6a NZfV0Y8n2Uo2q1k1Z2aJUQm7FC5/MX0mdS91taboO0x7fJqLbQ==
X-Google-Smtp-Source: ABdhPJyUiQabI6/6g2cF8WczOVBSFpOoTZF1w6D31VvGEQMNdLcTjyzq5iNXTXQZyRPY8JqELwPZfHizx9dUpnhfns4=
X-Received: by 2002:a37:b703:: with SMTP id h3mr336681qkf.240.1627615843646; Thu, 29 Jul 2021 20:30:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Fri, 30 Jul 2021 04:30:07 +0100
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="00000000000031016905c84ed8fb"
Archived-At: <>
Subject: Re: [CFRG] A Duck Test for End-to-End Secure Messaging: "Video Deck" on YouTube
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 03:30:51 -0000

On Fri, 30 Jul 2021 at 04:02, Martin Thomson <> wrote:

> Hi Alec,

Hey Martin - thank you for your thoughtful and considered response.  I am
about to turn in for the night (4am, ick) but wanted to quickly spin a
couple of comments back to you in case they unblock other questions you
might have.

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

I am thinking broadly along the same lines, though I see 1..6 as the most
skippable.  Posting the video beforehand, de-stresses a lot of that concern
for me.

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

I've learned to scope small and then expand: messaging without access to
retrospective history is a moderately well-defined app space.

If I were to exhibit hubris and claim that this test was a fit test for
some, huge broad spectrum of solutions, then I might end up having to
address questions about websites sending javascript to sframes, in the
process grandfathering in a huge space of browser-related behaviours that
may differ wildly from my well-explored, mostly-understood space.  I would
be deeply content to solve the problem that I am equipped to address, and
then let some more energetic bright spark take it forward into other
domains. :-)

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.

I prefer to keep slide 38 because it reinforces what IETF said in RFC2804,
viz: that IETF should *not* be saying what happens upon clients.

Quote: "The IETF, an international standards body, believes itself to be
the wrong forum for designing protocol or equipment features that address
needs arising from the laws of individual countries"

For "equipment", I nowadays read "apps on phones".  So, curiously, I
believe that you're agreeing with me?

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.

...and that's why I scoped it to E2E-Secure Messenger applications. :-P

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 is well-covered (if slightly dated) in the Clark/Blumenthal paper, but
yes, the TCB is no longer a static beast, it contains dynamic
dependencies on your app-writers, app-stores, device-platforms and whatnot.

Back in the old days, the worst we had to worry about in dynamic
dependencies was DNS Spoofing, ARP-Cache poisoning, and bogus patches,
surely? O tempora…

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

Concur.  There's a lot of work TBD, and so far I am doing it solo.

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.

I would be delighted.  Talk more in the morning?