Return-Path: 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 30403130E15 for ; Tue, 28 Aug 2018 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WTpElhLatWoM for ; Tue, 28 Aug 2018 11:19:40 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42C6130E14 for ; Tue, 28 Aug 2018 11:19:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.53,300,1531778400"; d="scan'208,217";a="344000517" Received: from corp-nat.fw1.untrust.mtv2.mozilla.net (HELO [10.252.25.87]) ([63.245.221.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 20:19:36 +0200 From: Benjamin Beurdouche Content-Type: multipart/alternative; boundary="Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <77627DC5-FEB9-4EF9-B2BA-F8786DB22C4D@inria.fr> Date: Tue, 28 Aug 2018 11:19:34 -0700 To: ML Messaging Layer Security X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] Follow-up and moving forward on Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 18:19:43 -0000 --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Message Protection is one of the important parts of MLS that has = currently been left out of the specifications as we were focusing on the establishment = of a group secret. There are a few questions we now need to answer about message = protection: A. What does the Application Key Schedule look like. This the key point = of attention as it will influence: - Strength of the cryptographic security properties we typically get for = secrets and messages: FS and PCS; - Performance and complexity for communication/latency/storage; - Difficulty to prove the cryptographic security properties we want with = the tools that currently exist; - Difficulty to implement securely. B. Encryption algorithms and traffic analysis protection I expect these aspects to be less controversial in the sense that there = is nothing new here, modern protocols use AEAD primitives such as AES-GCM and = Chacha20Poly1305. We also have to deal with nonce-reuse protection. The idea of this email is not to debate the details now but to make = progress on what is missing in the draft. Overall, I believe that we need to move forward towards MLS being = "feature complete", which is an important step in our process. --- I have been working on some initial text [0] for message protection, = with input from Richard, Karthik and Ekr. Assumptions in that text are, in my opinion, reasonably conservative and = I believe it could be merged as an initial text. As I said at the IETF meeting, we believe multiple variants of the = Application Key Schedule are possible: 1. a per-participant chaining of the Application Secret (hash forward = the secret and derive new keys/nonce per App message) 2. a group chaining of the Application Secret (under the same epoch = secret, each sender hash forward the current group Application Secret) 3. no chaining of the Application Secret (each sender update leaf to get = a new Epoch Secret, Application Secret and AEAD keys for each message) each having a different security/async properties. The PR [0] suggest the use of the classical per-participant chaining = with as it is a reasonably well-known construct. I also didn=E2=80=99t recall any specific opposition to that = scheme from the meeting. The PR also proposes that padding the plaintext of Application messages = SHOULD be done to at least provide some minimal protection of the plaintext length against traffic = analysis; one of the two mandatory-to-implement AEAD constructions MUST be used. Signatures are the way to authenticate a participant in the existing = draft, and I didn=E2=80=99t change that as we can revisit separately. The signature is included in the plaintext for = privacy as there is an implicit weak group membership property provided by the existing design: only legitimate = members of the group can decrypt the Application message (because only they can compute the current AEAD = keys) and look at the *optionally signed* Application message plaintext. --- When we have a base design that is good enough, we can then start = looking at formal security analysis of the composition between the Group =E2=80=9CKey" Establishment = mechanism and the Message Protection proposed mechanisms. After speaking with many people offline, it feels like it would be a = good solution to merge this PR as a first step so that we can start working on sub-components separately. *In no way I feel that the choices for this PR should be the definitive = ones for MLS.* I can make sure to adjust the PR if there are strong opinions on why we = shouldn=E2=80=99t merge something. What do people think and would the mailing list be ok with proceeding = this way ? : ) Best, Benjamin [0] https://github.com/mlswg/mls-protocol/pull/54 = --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

Message Protection is = one of the important parts of MLS that has currently been
left out of the specifications as we were focusing on the = establishment of a group secret.

There are a few questions we now need = to answer about message protection:

A. What does the Application Key = Schedule look like. This the key point of attention as it will = influence:
- Strength of the cryptographic security = properties we typically get for secrets and messages: FS and = PCS;
- Performance and complexity for = communication/latency/storage;
- Difficulty to = prove the cryptographic security properties we want with the tools that = currently exist;
- Difficulty to implement = securely.

B. = Encryption algorithms and traffic analysis protection
I expect these aspects to be less controversial in the sense = that there is nothing new here,
modern protocols = use AEAD primitives such as AES-GCM and Chacha20Poly1305.
We also have to deal with nonce-reuse protection.

The idea of this email = is not to debate the details now but to make progress on what is missing = in the draft.
Overall, I believe = that we need to move forward towards MLS being "feature = complete",
which is an important step in our = process.

---

I have been working on some initial text [0] = for message protection, with input from Richard, Karthik and = Ekr.
Assumptions in that text are, in my opinion, = reasonably conservative and I believe it could be
merged as an initial text.

As I said at the IETF meeting, we = believe multiple variants of the Application Key Schedule are = possible:
1. a = per-participant chaining of the Application Secret (hash forward the = secret and derive new keys/nonce per App message)
2. = a group chaining of the Application Secret (under the same epoch secret, = each sender hash forward the current group Application Secret)
3. no chaining of the Application Secret (each sender update = leaf to get a new Epoch Secret, Application Secret and AEAD keys for = each message)
each having a different = security/async properties.

The PR [0] suggest the use of the = classical per-participant chaining with as it is a reasonably = well-known
construct. I also didn=E2=80=99t recall = any specific opposition to that scheme from the meeting.

The PR also proposes = that padding the plaintext of Application messages SHOULD be done to at = least
provide some minimal protection of the = plaintext length against traffic analysis; one of the two
mandatory-to-implement AEAD constructions MUST be = used.

Signatures= are the way to authenticate a participant in the existing draft, and I = didn=E2=80=99t change that as we can
revisit = separately. The signature is included in the plaintext for privacy as = there is an implicit weak group
membership property = provided by the existing design: only legitimate members of the group = can decrypt
the Application message (because only = they can compute the current AEAD keys) and look at
the *optionally signed* Application message = plaintext.

---

When we have a base design that is good = enough, we can then start looking at formal security analysis
of the composition between the Group =E2=80=9CKey" = Establishment mechanism and the Message Protection
proposed mechanisms.

After speaking with many people = offline, it feels like it would be a good solution to merge this PR = as
a first step so that we can start working on = sub-components separately.
*In no way I feel that = the choices for this PR should be the definitive ones for = MLS.*
I can make sure to adjust the PR if there are = strong opinions on why we shouldn=E2=80=99t merge something.

What do people think and = would the mailing list be ok with proceeding this way ? : )

Best,
Benjamin

[0] https://github.com/mlswg/mls-protocol/pull/54


= --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30--