Re: [MLS] Use Cases for avoiding Forward Secrecy

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 28 February 2018 21:16 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A3124BE8 for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 13:16:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 A5GAazrV_obx for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 13:16:30 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555F51201FA for <mls@ietf.org>; Wed, 28 Feb 2018 13:16:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00E08BE2F; Wed, 28 Feb 2018 21:16:27 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpvdlVLYojcq; Wed, 28 Feb 2018 21:16:25 +0000 (GMT)
Received: from [10.200.0.239] (unknown [193.180.218.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75C2ABDF9; Wed, 28 Feb 2018 21:16:25 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1519852585; bh=0jBJXs6Z62yuzYZw3Oaxt62QT1N2H63C5KKh15Id+xM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DVsuwycTpyfDB/STssHripZw5AAfQd+hZkvGrdWCfkyX5yPevOQ9N7GXRWArTauez e5IaN39howUrLuVkbnw37ebJwriOmVl4a694wNJneKBRe9oR/dXcNqyWqxX4F4Yekx kf02qEiRx02AACGJ9LXrH706J600pL5J1uDILh+k=
To: Dave Cridland <dave@cridland.net>, mls@ietf.org
References: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <f10d4e2c-7b4c-b841-eadf-056e1729c713@cs.tcd.ie>
Date: Wed, 28 Feb 2018 21:16:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B1kKW3RVGPOYQybvujMoLCapPyOhqvnQo"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0jz1ZWQe8SYsU83mhQNCmYeFc0Y>
Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2018 21:16:32 -0000

Hiya,

On 28/02/18 17:14, Dave Cridland wrote:
> Given the latter, for example, I could not use an MLS-based system to
> discuss a tax problem with the authority, and since I'm unlikely to
> have a SAKKE-based messaging client, I'm unlikely to have encrypted
> messaging to my tax authority at all - which seems signficantly worse
> than merely having no Forward Secrecy.

Sorry, why is transport layer security not sufficient between you
and your tax authority?

I'm unclear as to why the security guarantees (aimed for) between
groups of people ought be reduced in order to meet the goals of
securing communications between a person and a service provider.

I do agree that it'd be good if a user of some application could
add a new device and still see old messages, but I'm not at all
clear that's that significant (for the crypto) since people will
always need to have some kind of fallback to handle cases where
they've lost state.

S.