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

Peter Saint-Andre <> Fri, 30 July 2021 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5393F3A152C for <>; Fri, 30 Jul 2021 16:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RypW1mC4Mgsj for <>; Fri, 30 Jul 2021 16:01:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0EFA3A1516 for <>; Fri, 30 Jul 2021 16:01:46 -0700 (PDT)
Received: by with SMTP id y4so11022245ilp.0 for <>; Fri, 30 Jul 2021 16:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9rGGmsHGE5xqEvXDHnuv+IHiJf2EkJVIWaJv5t6qDUI=; b=DLk82aDWNrbv2KYgsCCuaFMtbyFIbtPqheZdAoJdLqxsj9MzfQUM+3nI8OcqIZ1auA 7kaQZUUs1MXybVhPYRQA81JJd8quLq4Cl+vmOqLwANbDZgi+ITU8NoGAnh0VwxEf0+CH TywI7jtvg+EQ8XzqTAmCuTJZM27IfnYYMNqL8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9rGGmsHGE5xqEvXDHnuv+IHiJf2EkJVIWaJv5t6qDUI=; b=IA1N9CXAecT9yeSPL6h7lO0EOGlpL9jVs3c2OoJNwZ2k7hPCHjeK1d5rDtnFfp/oFl 5MF8PgWl/MQ1d+QW5dp78gEzM6qcxgBoNzAgqdVxaJCl6ApaNyzPzN4woulg4KMjn0Wv ugqPrCmoTEzoDa7Nj5RB+w5xWs6wFus9/Os2PcrKhFcnx87PdOm9kZgL38sMgF28dMx5 nyYAsWpe4qgiLGy7hlSXsStpMS9rAQ+PUyv1UiIx5QK65KPrrfvvEV4KQhEbekehoGhl TEec5MNX4qdOOh4te/7pr4CWekG6xXxgJ4OVoPPm4LVSRXVm3aBWuWBTkdbKNkLSuuZY H9cw==
X-Gm-Message-State: AOAM531FhDm1YbdvWOR8tB+YI0aPWVKCkI8gtqJlx87Tz7T4TccWhSfv 9N8Iba7fekvf1AKFRRtsLMNDXQ==
X-Google-Smtp-Source: ABdhPJwjzwG7tZXSdod7Qr9YfhnwH2Beywrtqz92U593ul//tTnmA+ICLbzetRpx/AD467mPEfBkhw==
X-Received: by 2002:a92:c5c5:: with SMTP id s5mr3281719ilt.271.1627686105571; Fri, 30 Jul 2021 16:01:45 -0700 (PDT)
Received: from dragon.local ( []) by with ESMTPSA id j6sm1878676iop.2.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 16:01:45 -0700 (PDT)
To: Martin Thomson <>,
References: <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Fri, 30 Jul 2021 17:01:43 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 23:01:52 -0000

On 7/29/21 9:02 PM, Martin Thomson wrote:

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

It might be prudent for this document to mention less centralized
architectural models (and examples other than Signal, WhatsApp, and the
like). For instance, most modern XMPP clients implement OMEMO [1] for
end-to-end encryption and XMPP-based projects like Snikket [2] are
making it much easier for people to deploy XMPP services under their own