Re: [MLS] Use Cases for avoiding Forward Secrecy

Phillip Hallam-Baker <> Thu, 01 March 2018 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E55712EB1F for <>; Thu, 1 Mar 2018 08:34:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cncGN8cr0dxu for <>; Thu, 1 Mar 2018 08:34:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 866EB12EB08 for <>; Thu, 1 Mar 2018 08:34:32 -0800 (PST)
Received: by with SMTP id t185so4907633oif.6 for <>; Thu, 01 Mar 2018 08:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dIpz3B7sOd3J1W+n9W5yzZ4wlN1xpQtgssgCcVIkD0U=; b=W/HO8v/9ssya+MfmUH1dkIUSklKu0+s2pZBW5/ktSZ9bU3vgPzulI//pnRRZpdGWIo WLViAHhjRCjvfbhK3fHbDMc7sczX8RYD1gFqnpIpMoDVEMMSPnmA23JkiPNH3Xl0y7QC YHDCe1gDzSAiO7gsY0yvO01ZOaPrKPaxAz6+iohjJ8Wm3sw/ibVmeXt/xH6XZ7UPyxEv 0W+d6ehNxJhdRbDMBoq1tLfv82ncpMDSM8z85H/GwmegyUwUivX9gIF1UWXRCVduvEaC J8enN8r6U3wON8OcYVrq/1Mbx6tJ9uVe5NOiHdi/TM7Jaro8Ob1X42iEmPBlvTf9hBNb ewCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dIpz3B7sOd3J1W+n9W5yzZ4wlN1xpQtgssgCcVIkD0U=; b=CJhDN8+MiED5+MpOr+JEOYxy11QjhSyOVJgHT9x1gs8w48EpvbLh7Qamf6dKETFLBZ ljsiCB7zf4ducxbIIcRuvIKhk28JU6e4jpAyTi2vY4maDg8PFQNQODYVk71W9ry9IwSt GjGd4uLGB/XD4fzQOqCuFRZyXPdj0BjIUZmz1cDpnnCjAZ/BL49ARU/srISLW3VGNjNM iL6jTdxC9h8+0YR8EbMVjvuds0MIHFGQgJQwFT9Ka3BnigIM5Gy2zQr2wuxt/RnA3kIp F6ESMR3i+iBSpSdnZ+pGe1x412pGKhmu6ZheT8YEhbZALteC7fMMOnsfLgONwmVtGZNi VG8Q==
X-Gm-Message-State: APf1xPCFrtFdujwSU9QGfK6aVbEMhRc+tu0cbiMcAYVNqKTZsWlr8fip oj3/yRX36faf/0f8DmwYFyWLPNSoBoHnm9v7EdM=
X-Google-Smtp-Source: AG47ELsir8SGcvKrpqVQDpREpCJ7AOe9Irncsq2Nh133Xl075aouTUUQ/+xgSembwwgIOeX9yj/ZIrO3+UORCs4rXho=
X-Received: by with SMTP id e68mr1690766oig.34.1519922071685; Thu, 01 Mar 2018 08:34:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Mar 2018 08:34:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Phillip Hallam-Baker <>
Date: Thu, 1 Mar 2018 11:34:31 -0500
X-Google-Sender-Auth: 4K8azi3mps1Xtu0X7RzQ284aWM8
Message-ID: <>
To: Russ Housley <>
Content-Type: multipart/alternative; boundary="001a113cdb042b4ec205665c6f22"
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 16:34:34 -0000

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.