Re: [MLS] Use Cases for avoiding Forward Secrecy

Sean Turner <> Thu, 01 March 2018 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFF8512EB6B for <>; Thu, 1 Mar 2018 09:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 bC8xrXysXAQ0 for <>; Thu, 1 Mar 2018 09:06:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7307812EB6C for <>; Thu, 1 Mar 2018 09:06:13 -0800 (PST)
Received: by with SMTP id a23so8450446qtn.0 for <>; Thu, 01 Mar 2018 09:06:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7QI/az2/LxKPj3N+EP0C9brfwHBCWnfqYxioMyMUd4=; b=SyYYTr3PWlv/FBSyxTz2rEA7kS5eeeGQMXe/15Qqy10lXIVjC+mELDjvh78SWmV/1X +fMOVcYqC6Ajk/rBW79kvnSuO8EgPEfFchZ1614WSK3BBkEJZk4AKp62BxfsxSmizlH2 kppG0R9MJWU8z5mzKvff6gJ1Gv++fDBsm4qUg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7QI/az2/LxKPj3N+EP0C9brfwHBCWnfqYxioMyMUd4=; b=iCnqVAkPA28KO/MIr4p5TCDFWAAZ7ak2Iw7UV51VDmi8VMI6nLf0fGNoSqPD1XQXyP Ft6tZqhD1Bu6EWNm0h+86g5PLLcV78YIZ2sQoqQqGaddL3GNzqrLfdawUq2dnSxCvLVY Ng4HpyCF4HUxCLBgLT2SVVbBvMf369sDF9vRzDpZDDPlowJg2zCPWuW0MQ6LABAnUq2E Tx2Gn6WagDJWksiLygRnjbOs2JhE9Nc6AMDmG6e47+rP+ADB0opwJS/0VoWwzOZZTdrW VlVLh66T5JI1Uojf62TOZnC06Ovagkk8F8N1zAx3REyqbNtdto7CTJ/LMEFW7UxRqgg5 02Ew==
X-Gm-Message-State: AElRT7Gx7UY8PpopKDGPMx0THwL4rqRINOb1C2YtTRo1mB82EpxGhk6I Rg9i6A6Bgk3B6Io8HhtXkEeHdA==
X-Google-Smtp-Source: AG47ELv9XfgGCDmmWm38ZokuGuM2+W6U8UxWaidUYZnZEkz9ZzMmTObN/BASuD6icjfe1Cy9AXKOjg==
X-Received: by with SMTP id a43mr4126364qta.311.1519923972411; Thu, 01 Mar 2018 09:06:12 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id g54sm3242296qtk.43.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 09:06:09 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner <>
In-Reply-To: <>
Date: Thu, 1 Mar 2018 12:06:08 -0500
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Jon Millican <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2018 17:06:27 -0000

Jon thanks for bringing us back on topic.


> On Mar 1, 2018, at 11:59, Jon Millican <> wrote:
> If the question is about whether MLS should support forward secrecy in the first place, I think consumer E2E messaging applications provide a good use case for this. The threat model that we tend to take here is that the user has limited trust in the service provider. In this situation, the security properties provided by TLS are almost moot, as TLS only protects you as far as the service provider anyway.
> Ephemerality is a very common property in such apps, with the explicit goal that messages not be accessible after a certain period. Even without ephemerality, I believe that most messaging support message deletion. In such situations, forward secrecy is very desirable, as it ensures that if keys or any device state do leak at any moment (be it from an exploit, somebody imaging a device, or a temporary bug in the app itself), users’ old messages can at least remain secret, even if the provider had retained all of their ciphertexts. This also leads to a similar case for Post-Compromise Security, in that secrecy can be recovered even after any sort of key leakage: although in this case the argument applies even when no messages are ever deleted.
> On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" < on behalf> wrote:
> On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <> wrote:
> Generally, I think the right answer to these, however, isn't to modify the messaging protocol but rather to add that functionality on the messaging app over the top. That also is a much easier way to do new device history sync
> This is similar to the approach used in some email environments.  The email message is decrypted for reading, and then encrypted in a separate archive key for storage.
> Russ
> ​It is a valid approach and it might be the right approach.
> ​
> ​But what we have right now is a rather complex proposal that may or may not be correct and may or may not be addressing the real requirements and may or may not be addressing them in the most straightforward fashion.
> So far I have seen a lot of defensive responses and one individual whose behavior was bullying. Now the fact that I cannot be bullied out of my opinions does not make ​the experience of people making personal attacks any more pleasant for me. 
> More importantly, I am concerned that what has been more or less explicitly stated is 'we have our proposal and if you don't like it then bog off'.
> I don't think that language encourages honest debate about the limitations of the proposal or identifying the flaws. 
> I would much rather the IETF endorse no proposal than one that only navigates the process because a group of bullies shouted down anyone who was critical of it. We saw that happen with DANE we saw it happen with CBOR. CBOR does work but the consequence of shutting down the voices saying that we needed a binary format that precisely matches the semantics of JSON is that we had to spin up a separate COSE working group to repeat the work of JOSE rather than simply apply the encoding.
> The assumption of most here is that the requirements are easy and the cryptography is hard. That is precisely the wrong way round. If we really understand what the requirements are, the cryptography follows almost directly. It is getting to the understanding of the requirements that is the hard part.
> _______________________________________________
> MLS mailing list