[MLS] Message Protection

Richard Barnes <rlb@ipv.sx> Wed, 27 June 2018 00:38 UTC

Return-Path: <rlb@ipv.sx>
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 28BEA127332 for <mls@ietfa.amsl.com>; Tue, 26 Jun 2018 17:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 8NsvDIG987sy for <mls@ietfa.amsl.com>; Tue, 26 Jun 2018 17:38:55 -0700 (PDT)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 E3474130E70 for <mls@ietf.org>; Tue, 26 Jun 2018 17:38:54 -0700 (PDT)
Received: by mail-ot0-x22b.google.com with SMTP id d19-v6so304643oti.8 for <mls@ietf.org>; Tue, 26 Jun 2018 17:38:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=cMCr4s0iEPTek8+cik9V+hW9coAlJFH/eFW8AsaF0dY=; b=f1NLB4f0H1epntDDSvRpJY9IHFsJD5ePyOM4puzE7F2ZyxkUaPvD7aLB6hNwezDter 7tXA6waKRDiDywk7y5VTZkAhS1mDSU3dt8iQPCHaxUM6BqyiRFPNNTWcydo5VzGWCbbp 6Bl6Isk5JEBROP/eFG+0keESRnlzhwiQ9EPfR4Fy2EMMsvt2Shlh4vK/NeaOzvnAKEOe KlppDzRBP5K4rE5WIWX67el/YJPib7865N4Fvd3XyxKQqfL0s1ElRC14z1qCePoikzBb BClkmwjbzPS6w8Bg+NahxjZdqypXasImNtsWtBvgNbmG4F9bIX7wJ1pStJNPGBzlWYR1 VrQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cMCr4s0iEPTek8+cik9V+hW9coAlJFH/eFW8AsaF0dY=; b=gNqZiNTucUCZVWYNzVjkXRlK4aHHr/lwClyo9zH3XSpAeOLx4VzP6k7IQJm+rQCjuy R8aFBZoRIvqayAKWjCQQy4/fHlanL1NIVIIXBCIJfEo/YeyX9TGIOJuxl+cQuP8gJJuG KZgm4ClURxdsuOGLqy/icLery5KE5AsAaVcm//wNUeehR9s5pw7UhdSZ7+4WqrVZvfXL 25s28phMg1TT5yHOEtjDiPkvb4l8jOcuZnCtOh8lBRzOy/IklUGlDwA8bDAd6BQ4liD3 IskZ/Y8y6PMGG0Xk950puFu5gy5OCYsxzoUc6k8/3gn+o9F+9uffETsaAa43VPo5K2U7 GmxA==
X-Gm-Message-State: APt69E251W9AyB7ytRQ49sRy1/FBvnb2AfbSdccKEQHsqqmPyH4rwm2r 8ryQMowEzHHrwQGhNVbArYfEL/SrvBaxIwZeN5kSUfY33MA=
X-Google-Smtp-Source: AAOMgpfSiF6haJdzevFPNh6GtHiPTEcZPWuYVEQkydP/4Ya/YAnLEfAZemCVvH6BM9sPlMo7FR23vU7QljUtfQ6SKAM=
X-Received: by 2002:a9d:55d7:: with SMTP id z23-v6mr2303010oti.271.1530059934006; Tue, 26 Jun 2018 17:38:54 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 26 Jun 2018 17:38:42 -0700
Message-ID: <CAL02cgREuhjySYZXmhaE3RuF3fZ5iwCgyW2ChtgwPYhDgdaYUQ@mail.gmail.com>
To: mls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000da1413056f94d629"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/sb5DGV3oJtjBkC9eIVAyh3iJJT8>
Subject: [MLS] Message Protection
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.26
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, 27 Jun 2018 00:38:59 -0000

Hey all,

One of the things we kind of waved our hands about in the charter and
current protocol draft is message protection.  That is, the idea of
specifying a concrete syntax for using the keys we negotiate using MLS to
actually protect content.

This is a simpler problem than key exchange (since you've already
established a group key), but it still has some nuances that matter to the
overall security story, so it seems worth writing some things down:

- Content encapsulation (e.g., what nonces / AAD you use with AEAD)
- Key schedule, i.e., how message keys are derived from the group key
- ACK / NACK / replay
- Transcript integrity (?)
- Expiration times (?)

What's missing here?

As far as getting something done: My MLS bandwidth is probably going to be
consumed with the key exchange protocol.  Is there someone who would like
to take a stab at writing a message protection specification?  Either as a
new draft or as a section in the protocol draft.

Cheers,
--Richard