Re: [MLS] Use Cases for avoiding Forward Secrecy

Dave Cridland <dave@cridland.net> Thu, 01 March 2018 09:35 UTC

Return-Path: <dave@cridland.net>
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 66D9A12DA40 for <mls@ietfa.amsl.com>; Thu, 1 Mar 2018 01:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 tj_FEuAFXa45 for <mls@ietfa.amsl.com>; Thu, 1 Mar 2018 01:35:35 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7895E12D86A for <mls@ietf.org>; Thu, 1 Mar 2018 01:35:35 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id t204so7808433lff.9 for <mls@ietf.org>; Thu, 01 Mar 2018 01:35:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ntYC2j9rXYY3E8Ho1/qbPeTpZQDtSlVzUO9Ak17XaDw=; b=eh32YyWYnFYcdyNZMEhJVsY0UDuCRHvLiA9sbVb53lUs8uXEoEa0Y+SxlnXMrEJ3VJ Cj+w19PaNHhYOE3LaK259jQpOE9Wz/mvgATAVeihRCsp1ytoj0b5ilCU76sqRZcjLdvo wryj2ZKNeGVOqprJBheqY5CbScxdaiYAFm0fA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ntYC2j9rXYY3E8Ho1/qbPeTpZQDtSlVzUO9Ak17XaDw=; b=snBKGN8bHqe8WQ79WP6+DN4GLYVpsDP+3f9ycB8C+BNWuCsmXVSu+nFZphkJvRLfBY XTXvhx/w525izpsfVQkwnhrGwB/GUUzAVBaIcJ5JSa9en2/Jk7N7eYx0LJskL8Ga0eJL XLThZGi+ZAbqKjZiH8x3UU9kZHcVYGlAaRHGGty52tAQ/ONEF1Iq7IexDsn5kX38ZrSc N/0lpA+S1kADTAbtBKBXEvyHBHFUVFX3Jlwwlfog18SIbkQo6FQB5KIYoGffgRSTE03r 9+V7e3nPkF53SDnZaX4pV2VaMSQkbGnVYkv34Zz0zAvJOjHIr3eQk24MQxgD3tPR4Q76 L1Ew==
X-Gm-Message-State: AElRT7Hmybn7QvTbFxmYL5EiNpzgrPljV0l0fz43JE8DcjHxdIBynYq7 C4VKxVM0QjTilWJot4xKgjKtvcjz8zUozyyqH2SlJw==
X-Google-Smtp-Source: AG47ELuqciF4ih0Q/ypJ46gbsNyt0rrGHSwQ0UrEf8ByFk2TXU/BiHXbiHCTrGp/uLYTLZ4ehhGZNUleFxlJXAFKZh8=
X-Received: by 10.25.228.18 with SMTP id b18mr876985lfh.61.1519896933565; Thu, 01 Mar 2018 01:35:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.179.26.8 with HTTP; Thu, 1 Mar 2018 01:35:33 -0800 (PST)
In-Reply-To: <20180228234104.14fde460@T-200>
References: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com> <f10d4e2c-7b4c-b841-eadf-056e1729c713@cs.tcd.ie> <CAMm+LwjJxdTJcPBCNh3JsjDeWODFuS3FwUPz_ztvzKpkU7X8DA@mail.gmail.com> <20180228222800.0a978ded@T-200> <CAMm+LwjGfQj2K1krkKMfL3ZwBj0XCXK7VTkfmRDTt4d18MOk3w@mail.gmail.com> <20180228234104.14fde460@T-200>
From: Dave Cridland <dave@cridland.net>
Date: Thu, 01 Mar 2018 09:35:33 +0000
Message-ID: <CAKHUCzx_w9HwSEABci5m3M-SUU-T1KPcnn=7f0+MHR_e4jjo6g@mail.gmail.com>
To: Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
Cc: mls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/raUPjgs9eq5HLx5-01HL-Ne5upc>
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: Thu, 01 Mar 2018 09:35:37 -0000

On 28 February 2018 at 23:41, Dennis Jackson <dennis.jackson@cs.ox.ac.uk> wrote:
> The discussion on PFS has been done to death, both on the TLS mailing
> list and in numerous other places and I would hate to see us repeat it
> for little gain. In the end, TLS 1.3 mandates that PFS be used in
> every connection. I find it hard to imagine that MLS will aspire
> to a weaker security goal than TLS, but as you say, it is for the
> group to decide.

FWIW, I'm assuming that communication security will always have FS.
That's highly desirable in all the markets I work in, although some
don't use TLS to provide it.

So I assume that MLS operates over links secured by TLS (or equivalent).

However, when your protocol is being used to, for example, coordinate
blue light, or MEDEVAC, or whatever, then the integrity of the
archived communications turns out to be quite important.

Dave.