From nobody Fri Jun 1 10:22:34 2018 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D790B12D962; Fri, 1 Jun 2018 10:22:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, nick@cloudflare.com, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152787375281.15020.15432571968775450469.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 10:22:32 -0700 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 102 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:22:33 -0000 A new meeting session request has just been submitted by Nick Sullivan, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Nick Sullivan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 125 Conflicts to Avoid: First Priority: acme artarea cfrg dispatch iasa2 httpbis perc quic rtcweb saag secdispatch tls Second Priority: curdle dprive lamps sidr sidrops stir suit teep People who must be present: Eric Rescorla Sean Turner Cullen Jennings Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 26 17:39:00 2018 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 28BEA127332 for ; 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 ; 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 ; Tue, 26 Jun 2018 17:38:54 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id d19-v6so304643oti.8 for ; 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 Date: Tue, 26 Jun 2018 17:38:42 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000da1413056f94d629" Archived-At: Subject: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 00:38:59 -0000 --000000000000da1413056f94d629 Content-Type: text/plain; charset="UTF-8" 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 --000000000000da1413056f94d629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

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

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

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

What's missi= ng here?

As far as getting something done: My MLS bandwidth is proba= bly going to be consumed with the key exchange protocol.=C2=A0 Is there som= eone who would like to take a stab at writing a message protection specific= ation?=C2=A0 Either as a new draft or as a section in the protocol draft.
Cheers,
--Richard
--000000000000da1413056f94d629-- From nobody Tue Jun 26 17:39:37 2018 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 C6FA9130E70 for ; Tue, 26 Jun 2018 17:39:34 -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 zBmIcN5Ng-rS for ; Tue, 26 Jun 2018 17:39:33 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 2AA69127332 for ; Tue, 26 Jun 2018 17:39:33 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id d19-v6so305749oti.8 for ; Tue, 26 Jun 2018 17:39:33 -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=UFNZ/xMDtyIzltvRU6vlxP/JQiqgnjXiHVztmqjLEqo=; b=qAI0bXYWAgvJt+947oLE3pTmcBH9Dm8mrgFh5Y8IBdipWTm3z3svf3Jmq6OEjYB4Mx jkgu0RTyviTF9+j3rAIgh6CvbZcbt8/CWmaR7yfp05dXt7EM+ZW91tTqeK4A8ju/TLCz xUv6aGzlowGMCKLcEopdSXIvLc3u1lCtkLoyoY21Vb4q+VRHfSC/CWOg1lj4ri6H1Edz XcEX1z2ambMJWOjmHH2a+7XbNivEQXRwwNpnZE2xyBgBdFoRyp79++qA/PVg8EBZz3+q QNlIGVyEXKRT5oCjpHENtnBBkS0C0kztZgGWT07m6S89c5DQoLJPiMHT9pfe04s7nIX6 vXiw== 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=UFNZ/xMDtyIzltvRU6vlxP/JQiqgnjXiHVztmqjLEqo=; b=B7pT4rVvcDz6BQWpH+yV7ZCI6NiEZPNxJqasJ1AEPhH8p4w/+zmi5FaKrg9mmJ0yej +u6HoPFRH1Wa058B9+Ej1opYffK2v5t3UTGm6Y/OldPd4H2zscXCkXobIWwnKtfwwJSt kKYCzx44j9brinYKeka4QUFFzJp/OF3uYisNKSg2LZQCAZGtbMD2YyGV1hX5oy1wDibT du09TyClINepZUkucfJ/6I07z+aUZp+8iKnRHLCqsPd6ZuDT2hb46r+ECQbdsaStPruL FSM+WlV03uUHzxsI4UYyQX6b/gKZPiL43w/fLuseTlDeIZauQ3RQEkrg+G7g659I7aH6 36PQ== X-Gm-Message-State: APt69E3tgvh4d4QXXHFKd39Wgu7Lch/+lG8+qO/2omUKhRH7Cr48lEML Wb5+blH00pWA3EimZPYbIM97pyVjkAzXzMqA3PyQGW2e9IM= X-Google-Smtp-Source: AAOMgpfQ3zj8bXVAYMRoxiv5PBQXsNrmO0gV/dh4+UlMs737hp7urpO3/GCGDMFXxsb8AMSjrxAYMPZX7L3XEIYTsME= X-Received: by 2002:a9d:ac7:: with SMTP id 65-v6mr2344296otq.84.1530059972207; Tue, 26 Jun 2018 17:39:32 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Tue, 26 Jun 2018 17:39:21 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000002104d3056f94d93c" Archived-At: Subject: [MLS] Hackathon at IETF 102? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 00:39:35 -0000 --0000000000002104d3056f94d93c Content-Type: text/plain; charset="UTF-8" Hey all, IETF 102 is approaching in a few weeks, so I wanted to see if anyone would be interested in doing some work at the Hackathon. I would propose we focus on ART and TreeKEM. I'm planning to update the protocol draft before the deadline on Monday so that it has syntax for UserAdd, GroupAdd, and Update messages with both mechanisms (without all the authentication packaging for the moment). Given that syntax, we could verify at the hackathon that implementations could correctly generate and parse these messages, and we could do some basic performance testing to compare the two approaches. I've got both ART and TreeKEM implemented in JS (and could probably get C++ going as well), and would be up for implementing the syntax for the hackathon. Is there anyone else who wants to try getting interop? Thanks, --Richard --0000000000002104d3056f94d93c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

IETF 102 is approaching in a few weeks, so= I wanted to see if anyone would be interested in doing some work at the Ha= ckathon.

I would propose we focus on ART and TreeKEM.=C2=A0 I'm = planning to update the protocol draft before the deadline on Monday so that= it has syntax for UserAdd, GroupAdd, and Update messages with both mechani= sms (without all the authentication packaging for the moment).=C2=A0 Given = that syntax, we could verify at the hackathon that implementations could co= rrectly generate and parse these messages, and we could do some basic perfo= rmance testing to compare the two approaches.

I've got both ART = and TreeKEM implemented in JS (and could probably get C++ going as well), a= nd would be up for implementing the syntax for the hackathon.=C2=A0 Is ther= e anyone else who wants to try getting interop?
=C2=A0
Thanks,
--R= ichard
--0000000000002104d3056f94d93c-- From nobody Tue Jun 26 17:54:05 2018 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 D5A16130E70 for ; Tue, 26 Jun 2018 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 Qdye2bg6Yt1M for ; Tue, 26 Jun 2018 17:54:02 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 6F8C2130DD0 for ; Tue, 26 Jun 2018 17:54:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,276,1526335200"; d="asc'?scan'208";a="270045449" Received: from c-73-162-190-131.hsd1.ca.comcast.net (HELO [10.0.0.85]) ([73.162.190.131]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2018 02:53:58 +0200 From: Benjamin Beurdouche Message-Id: <772248D1-D5D3-4ACD-BFB4-E14AB92B26A3@inria.fr> Content-Type: multipart/signed; boundary="Apple-Mail=_0F06B002-7965-468B-A2F6-6E7A16665070"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 26 Jun 2018 17:53:55 -0700 In-Reply-To: Cc: ML Messaging Layer Security To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 00:54:05 -0000 --Apple-Mail=_0F06B002-7965-468B-A2F6-6E7A16665070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Richard, Hi all, > On Jun 26, 2018, at 5:38 PM, Richard Barnes wrote: >=20 > Hey all, >=20 > 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. >=20 > 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: >=20 > - 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 (?) >=20 > What's missing here? Maximum payload length and rekeying have been left out, and these are = very dependent on how often we roll the root keys. I believe we currently leave it to the application to decide when to = roll the keys, but obviously we must be very careful here=E2=80=A6 > 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. Hand waving here ! ;) My preference goes for most/all of that to be part of the protocol = specification... B. --Apple-Mail=_0F06B002-7965-468B-A2F6-6E7A16665070 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEuBxqANrVSPVBPOUAfmABPaR1P1QFAlsy4CMACgkQfmABPaR1 P1QGJQ//ZMLF4lTCZUj0aEZ0w7WyoO7CBVy2pWbro6MpgMMFWzDQycU+g35zm/UR 4VTJLKUggVObWbJBDC1h6KuMlQt7gmLKyD4t7eD60xvvRwbilHfVDJS0vn9FjHQa KTPlOKldVj5sGUWZROWXqQcS9qXvfiECA1R4lAXvEDJm4noTVghn7mm0BII+2JfE ufYVvIHl/PekxeVyguNoQ58I3JwLvz20K25xgGHLr5LC6sYqHz3yHxv2Yi3o4IsS YH06pt+ZzVY+QXrZO510+a9fG3ufsVW8Pt6Doo7chvDFTT+5zoyB7VS5QJhkCRO0 TbACwKCCFdocUE19yOXZo0ZaVaY+i12RZlfpkj5Wg6kZ1PQAMjzjdLtU8C358VGY A5ykC/8NnwwBPxLFPMvuJC3g+i7dmHr8FOQuY2HBBxk/QMrQBolLayxJhUKPNpGa dh0rhpLu6/tWW19JpBB3YQXtlfeSASBWi2ZyzCz+/891v8QJ8s6c2ZvX4skM28XW hZNAnFtnVfssm7fUsoaxe/ZJ2SkelNrT/BT1vF1diqjEI9ohkKzc9Qa/S9cUQPO7 iplZRUEk90ROXXILhI1WNqZJn+83C0vb9uDdRGb/JmTzaNaajUblIswg5+LRh8IO ayTvwD08gdX1fwutFCLS7QfaAmtZSjnmAAtmPRFdZxKkYwH7L3c= =txF5 -----END PGP SIGNATURE----- --Apple-Mail=_0F06B002-7965-468B-A2F6-6E7A16665070-- From nobody Wed Jun 27 14:36:13 2018 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 CC959130E36 for ; Wed, 27 Jun 2018 14:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 cy-Xr1b2vNjF for ; Wed, 27 Jun 2018 14:36:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90806130E34 for ; Wed, 27 Jun 2018 14:36:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7A717300A2A for ; Wed, 27 Jun 2018 17:36:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MqWPuWS7HvFQ for ; Wed, 27 Jun 2018 17:36:07 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 9296E30063A; Wed, 27 Jun 2018 17:36:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: Date: Wed, 27 Jun 2018 17:36:08 -0400 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:36:12 -0000 > On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: >=20 > Hey all, >=20 > 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. >=20 > 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: >=20 > - 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 (?) >=20 > What's missing here? If the tree produces a key and an identifier for that key, then the = protocol is straightforward. The key identifier could be derived from the key itself so that anyone = that knows the key also knows the identifier. prk =3D HKDF-Extract('mls-key-id' | tree-identifier, key) keyid =3D HKDF-Expand(prk, '', sizeof(keyid)) Russ From nobody Wed Jun 27 15:12:16 2018 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 B2A3D130E2C for ; Wed, 27 Jun 2018 15:12:14 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MFORjEQrjOpK for ; Wed, 27 Jun 2018 15:12:12 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 C3A98124BE5 for ; Wed, 27 Jun 2018 15:12:12 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id 18-v6so3325875oiq.6 for ; Wed, 27 Jun 2018 15:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d4EgJiBk1R8UALgWf8r9sA8pdUJL8tUlylSMeQgqF7s=; b=BlBo6yEzD+t5+wf8mPNuvWWE3RyIiiJFQD06yG4HUCmgajMBRfPCLLY5X9exqnMQk+ IFzl9m+NtniXNsiw3ssc/24HMi+xY/BkWDZ6tT2iXStbu+/TrTZ1p+T9DdbZLPhTHDBT GoSRVsQl8fHwxpd46EdB//CXVyl71DO6aou1l5B35EWFZrfmtVbI1HEwn0e3WBDMtr0y YmfXviWLzCoSUetxIG4Rqf40hUnFJodiIpMz8MIMJBWJUGhWvo3pLqL66DWHj/MnSqWE w1iA/jFQNxMgDYGKvjJZM8aMr/ai/Q10/im7Pn7EZvlDcNbBYmm/kdZXfdasmkTNADpD kh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d4EgJiBk1R8UALgWf8r9sA8pdUJL8tUlylSMeQgqF7s=; b=ULOAn4pb3ndP/ewueM/vJhpqGsbQTRxUruNqrWWrmRJ1iopuuC6+KLM/1OKX0ecMpl Yi4eiIjful9DmJ7MB2wEMmtlwlNEYhu2yecw5lqUZLo/P4W8yj++zDhwsvdIByyUH/gY laKmqjFkat+DVWyjMiOWyJrpm5A6K5CEsvDjdqt9J92GET6zWSP4PEaFbabOrKVV3vXL eQGgxB2lbQYPxM48VAUYPsxH7nuOFoXp86LnjFkdOgs6E+heUeoim4TTbYvUS5OZAWrQ wragjn2X9R9kki8V43cLv13WmO1AgfwkGLurCqL4lO2WlS0bFZx1H+GKvKAS6VL8UBkB cVsA== X-Gm-Message-State: APt69E3tlSrI9J/kf/fYSnZ2n6j135LLZxOYrT5Q0ty3uMlfX0iNU+fO NoxPi+a2McA3qe/vVBKml4H2jcahtTJEbAzd+3g= X-Google-Smtp-Source: AAOMgpfRzs5QVVcAuIkvCQyPbwGbabsVVZgJec5Y7QUiFvSEfVIZgcSLdhvRbtanTF+75SmSfcX+SdggnhU2MzVd5Vk= X-Received: by 2002:aca:745:: with SMTP id 66-v6mr4098627oih.295.1530137532125; Wed, 27 Jun 2018 15:12:12 -0700 (PDT) MIME-Version: 1.0 References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> In-Reply-To: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> From: Martin Thomson Date: Thu, 28 Jun 2018 08:12:04 +1000 Message-ID: To: Russ Housley Cc: Richard Barnes , mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 22:12:15 -0000 I was thinking that the nonce generation aspect would be worth looking into as well. If you crib from the TLS design, maybe you could have per-participant keys so that each can be independently responsible for ensuring nonce-uniqueness. Then they can use counters to avoid nonce reuse if they so choose. Otherwise, I was tempted to suggest AES-SIV or another nonce-reuse-resistant scheme, but there are fewer of those available than straight up AEADs. On Thu, Jun 28, 2018 at 7:36 AM Russ Housley wrote: > > > > > On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: > > > > 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? > > If the tree produces a key and an identifier for that key, then the protocol is straightforward. > > The key identifier could be derived from the key itself so that anyone that knows the key also knows the identifier. > > prk = HKDF-Extract('mls-key-id' | tree-identifier, key) > > keyid = HKDF-Expand(prk, '', sizeof(keyid)) > > Russ > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Jun 28 07:21:52 2018 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 68A3E130FFE for ; Thu, 28 Jun 2018 07:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] 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 58x46513y8uo for ; Thu, 28 Jun 2018 07:21:38 -0700 (PDT) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 B153E130DC5 for ; Thu, 28 Jun 2018 07:21:38 -0700 (PDT) Received: by mail-ot0-x243.google.com with SMTP id n24-v6so6311011otl.9 for ; Thu, 28 Jun 2018 07:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=saMqLyaRgMiA0NIQXR2/efgapysL/2cZI+QFIrhbxtE=; b=MWLmVidVr2tXqDuUKCagVLgi44RNIdHElRVBGNOIzOA+lC9JXkfdsv2B2BjKEyG9ai pTxFMxHxF/RZajU+J3BHWnUB4MUzrCR6jCRFcyrEpKPdOhzJ3BbfAl+AC0xLuE1HplJ1 94St130VPeUwhEqPET1Sp8U4aI5ywJvXTcLQ+CGLFLE1F9yaU918T1JXiD6KVPywKy7H N49qYa6komHc5vcU0fdMxkdnLV8fv/Cu5DFHY3SyqGt0UPdflsHFfMwNgdmv9Mt4pha1 gyHUs3621isWGKhGLCOYlJZt2JF/D8fzZPe7/eLiFcIjeGohMP/ZvnwLZciv02cN+6+1 8EMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=saMqLyaRgMiA0NIQXR2/efgapysL/2cZI+QFIrhbxtE=; b=DHFMUYy4BQk08/s6sMC8FPRUemFvnPRexATg6Uzn/bveoI3LDndI/KruF0OlEkrLF5 /pKfxyU/lpbL+xNFzugoJ7sGwaiKwPTSXpttd4NRgSQ0Y0CXoABu2CSKaEDYheTkA6Gp yMrCk50Jry6pdNspiSE5zBX2pwb45UDaT8ceY6mxWSX7dyVlHwOIY6DiOHdKzavDHl8u btFUsVd65J3aWhF1L2vIpuR+EVcqasm/EIvQCFA0HtYX1mqSqov7fbK4uuM2KBlNckjU w5N2RVUglvkRanAWG2OS2QjyqNqh4jZcu3MtMV8cVTd7hS8Ne7tgvIsLg6ZWSgDn/BJm /1eg== X-Gm-Message-State: APt69E1SBRqN0QJ3sqkq6eaGKRNC+Q39d1/9+5s+E/2hulkPlHf6cUZH 0SMNzicARZY/jY4JMUwXWjebk7yXLIij4DIUGJHJ/Q== X-Google-Smtp-Source: AAOMgpcJ7md0LayLzCL8I8xx/fyfesr3XWIZKBP/PipHE2M0Rvgj1NftmoO5QbusVeBqbz1mDb4KK9cYtgQZjq+Y+/o= X-Received: by 2002:a9d:2e47:: with SMTP id c7-v6mr6492510otd.383.1530195697925; Thu, 28 Jun 2018 07:21:37 -0700 (PDT) MIME-Version: 1.0 References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> In-Reply-To: From: Richard Barnes Date: Thu, 28 Jun 2018 07:21:21 -0700 Message-ID: To: Martin Thomson Cc: Russ Housley , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000031748056fb47379" Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 14:21:49 -0000 --000000000000031748056fb47379 Content-Type: text/plain; charset="UTF-8" Yeah, when I wrote "key schedule", I was envisioning things like deriving keys per-sender, or per-message-per-sender, hash-ratchet style. Since you can get some forward secrecy benefits that way if you delete older entries in the hash ratchets. On Wed, Jun 27, 2018 at 3:12 PM Martin Thomson wrote: > I was thinking that the nonce generation aspect would be worth looking > into as well. If you crib from the TLS design, maybe you could have > per-participant keys so that each can be independently responsible for > ensuring nonce-uniqueness. Then they can use counters to avoid nonce > reuse if they so choose. Otherwise, I was tempted to suggest AES-SIV > or another nonce-reuse-resistant scheme, but there are fewer of those > available than straight up AEADs. > On Thu, Jun 28, 2018 at 7:36 AM Russ Housley wrote: > > > > > > > > > On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: > > > > > > 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? > > > > If the tree produces a key and an identifier for that key, then the > protocol is straightforward. > > > > The key identifier could be derived from the key itself so that anyone > that knows the key also knows the identifier. > > > > prk = HKDF-Extract('mls-key-id' | tree-identifier, key) > > > > keyid = HKDF-Expand(prk, '', sizeof(keyid)) > > > > Russ > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > --000000000000031748056fb47379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, when I wrote "key schedule", I was en= visioning things like deriving keys per-sender, or per-message-per-sender, = hash-ratchet style.=C2=A0 Since you can get some forward secrecy benefits t= hat way if you delete older entries in the hash ratchets.
On Wed, Jun 27, 2018 at 3:12 P= M Martin Thomson <martin.tho= mson@gmail.com> wrote:
I was= thinking that the nonce generation aspect would be worth looking
into as well.=C2=A0 If you crib from the TLS design, maybe you could have per-participant keys so that each can be independently responsible for
ensuring nonce-uniqueness.=C2=A0 Then they can use counters to avoid nonce<= br> reuse if they so choose.=C2=A0 Otherwise, I was tempted to suggest AES-SIV<= br> or another nonce-reuse-resistant scheme, but there are fewer of those
available than straight up AEADs.
On Thu, Jun 28, 2018 at 7:36 AM Russ Housley <housley@vigilsec.com> wrote:
>
>
>
> > On Jun 26, 2018, at 8:38 PM, Richard Barnes <rlb@ipv.sx> wr= ote:
> >
> > Hey all,
> >
> > One of the things we kind of waved our hands about in the charter= and current protocol draft is message protection.=C2=A0 That is, the idea = of specifying a concrete syntax for using the keys we negotiate using MLS t= o actually protect content.
> >
> > This is a simpler problem than key exchange (since you've alr= eady 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 AEA= D)
> > - Key schedule, i.e., how message keys are derived from the group= key
> > - ACK / NACK / replay
> > - Transcript integrity (?)
> > - Expiration times (?)
> >
> > What's missing here?
>
> If the tree produces a key and an identifier for that key, then the pr= otocol is straightforward.
>
> The key identifier could be derived from the key itself so that anyone= that knows the key also knows the identifier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prk =3D HKDF-Extract('mls-key-id&= #39; | tree-identifier, key)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keyid =3D HKDF-Expand(prk, ''= , sizeof(keyid))
>
> Russ
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
--000000000000031748056fb47379-- From nobody Thu Jun 28 07:38:35 2018 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 2FC09130E8C for ; Thu, 28 Jun 2018 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4ZdsqefHT14s for ; Thu, 28 Jun 2018 07:38:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1B7130DCC for ; Thu, 28 Jun 2018 07:38:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 79FD6300A2F for ; Thu, 28 Jun 2018 10:38:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jODJ6oiDemXn for ; Thu, 28 Jun 2018 10:38:28 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 097943005D7; Thu, 28 Jun 2018 10:38:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: Date: Thu, 28 Jun 2018 10:38:28 -0400 Cc: Richard Barnes , mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 14:38:35 -0000 Martin: Each sender using a separate key seems pretty easy. The key can be = derived using the sender's position in the key or any other unique = identifier that comes natural in the messaging protocol. Russ > On Jun 27, 2018, at 6:12 PM, Martin Thomson = wrote: >=20 > I was thinking that the nonce generation aspect would be worth looking > into as well. If you crib from the TLS design, maybe you could have > per-participant keys so that each can be independently responsible for > ensuring nonce-uniqueness. Then they can use counters to avoid nonce > reuse if they so choose. Otherwise, I was tempted to suggest AES-SIV > or another nonce-reuse-resistant scheme, but there are fewer of those > available than straight up AEADs. > On Thu, Jun 28, 2018 at 7:36 AM Russ Housley = wrote: >>=20 >>=20 >>=20 >>> On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: >>>=20 >>> Hey all, >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> - 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 (?) >>>=20 >>> What's missing here? >>=20 >> If the tree produces a key and an identifier for that key, then the = protocol is straightforward. >>=20 >> The key identifier could be derived from the key itself so that = anyone that knows the key also knows the identifier. >>=20 >> prk =3D HKDF-Extract('mls-key-id' | tree-identifier, key) >>=20 >> keyid =3D HKDF-Expand(prk, '', sizeof(keyid)) >>=20 >> Russ >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls From nobody Thu Jun 28 08:12:06 2018 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 6FD67130DC8 for ; Thu, 28 Jun 2018 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=bMOxrULB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hUT6Dvij 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 yz_BtrHTYxsn for ; Thu, 28 Jun 2018 08:12:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C357130FF9 for ; Thu, 28 Jun 2018 08:12:01 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 79ABF21D26; Thu, 28 Jun 2018 11:12:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 28 Jun 2018 11:12:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject :x-me-sender:x-me-sender:x-sasl-enc; s=mesmtp; bh=gArDLShQBKKxqS LGOClye3NTwCzjEY2llGYXd180VwQ=; b=bMOxrULBMl8DgB8/M+SuO4aSv9ksam hprrZ0quheYpkHzDA7uwyihUQDIcJiLjmUGK4GIjpHUJZ13figj0vwxZTqwCKMn1 xniOTtoAfO2TL9SaQF+sJ0WrPskX1s8KTxU3PcIKf+wLeV0KO7EFPaxVIf6Fl+Sa XjUSTXRoyf5y8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gArDLShQB KKxqSLGOClye3NTwCzjEY2llGYXd180VwQ=; b=hUT6Dvijc1/LqO+bYiK3P2FVp /DRcmJhoZw1DLd3mVBLiqBfypbyQ/C++3bGRTUzmKy90wN1ZKxDMOGTntv8CdvdD pyQRay+h2FOhMQS3xxs+1OAaTwT66iW4MgDtTAAB9IPRjGJC6dOtPFcWsdddpPSl GL9iiqjhER5d0c1blCFxRuWz2pV3ay7s99kWOzvfg+ccLqTx6qN+V6EuBtN2bwwh HsRIrcmS4cLwrrZfMHID2NPIqpisZsbHZvyfz2exAPWzJlz0KR6W5vh3xV/QtWaD 75oAJhfZ0veNfPYaTg+wTdU3i8DMV7P2RVdEW/pstwgAyXcFtB9OsWYKrMKKQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AF5049E4B0; Thu, 28 Jun 2018 11:11:59 -0400 (EDT) Message-Id: <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" Cc: mls@ietf.org, scratch@virgilsecurity.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c In-Reply-To: <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> Date: Thu, 28 Jun 2018 16:11:59 +0100 References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 15:12:04 -0000 I've been chatting with Alexey at Virgil Security, who has started work on a PR [1] to add this form of key separation. I think we all liked this design; shall we figure out exactly how it works? I like the idea of symmetric key chains so that each message has a separate encryption key, as in Signal; that requires N and PN counters in the header to figure out which key to use, which I guess should go into the authenticated data. Note that this means that each message key is used once, which helps guard against nonce reuse. best, Katriel [1] https://github.com/ekr/mls-protocol/compare/master...Scratch-net:master On Thu, 28 Jun 2018, at 3:38 PM, Russ Housley wrote: > Martin: > > Each sender using a separate key seems pretty easy. The key can be > derived using the sender's position in the key or any other unique > identifier that comes natural in the messaging protocol. > > Russ > > > > On Jun 27, 2018, at 6:12 PM, Martin Thomson wrote: > > > > I was thinking that the nonce generation aspect would be worth looking > > into as well. If you crib from the TLS design, maybe you could have > > per-participant keys so that each can be independently responsible for > > ensuring nonce-uniqueness. Then they can use counters to avoid nonce > > reuse if they so choose. Otherwise, I was tempted to suggest AES-SIV > > or another nonce-reuse-resistant scheme, but there are fewer of those > > available than straight up AEADs. > > On Thu, Jun 28, 2018 at 7:36 AM Russ Housley wrote: > >> > >> > >> > >>> On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: > >>> > >>> 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? > >> > >> If the tree produces a key and an identifier for that key, then the protocol is straightforward. > >> > >> The key identifier could be derived from the key itself so that anyone that knows the key also knows the identifier. > >> > >> prk = HKDF-Extract('mls-key-id' | tree-identifier, key) > >> > >> keyid = HKDF-Expand(prk, '', sizeof(keyid)) > >> > >> Russ > >> > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Jun 28 23:36:48 2018 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 C73B3130DC4 for ; Thu, 28 Jun 2018 23:36:46 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QZk4QozzE9UF for ; Thu, 28 Jun 2018 23:36:44 -0700 (PDT) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 58B09130E06 for ; Thu, 28 Jun 2018 23:36:44 -0700 (PDT) Received: by mail-ot0-x244.google.com with SMTP id n24-v6so8818220otl.9 for ; Thu, 28 Jun 2018 23:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MCoN/mc97/HRnPnIQVshKZ+/l/gKdXk8wscqJFTpyb4=; b=KbU1X/tRvMvYu8EVbny7tx3hduPEQnp+x+Rar1xmY7hzVrEyKI4x3/6TzjkYqHynKl uz23y8g4YuIldmtAq5O792e3TjQsnJD79SO2RIP2HRQgHgHPUyL1WC9PeIuUnY2+f9M1 qqj8MXvAzUNNr5Pda8kjEBTSQ2+0Anwi5ajqJJHu0i0kwXfqdsR79XljJAz/joq2eMWU /5jiDsk8eyfk2bXtS+s/rZ3g080rnjtWQIJqz/WA8wYAeWRkTBi0aNwwGHCILBcpf0T/ wHleDSj1p4IVyD/mJttDQ8k5k6G1KgSWkSlqHS+wlREEMPnK3f/+UUNQe0xHc8o9dVV5 IV4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MCoN/mc97/HRnPnIQVshKZ+/l/gKdXk8wscqJFTpyb4=; b=tpykHICiIxhOI/px8s+B7kKXleudX1XZs1xuPT/2PjSJ4vykKm5DLYF+2/sDgxqbW4 iSvfv6x5A5J8o86V0FjkvRp3NFJ4GRorycXH8cf1E2/333g3QedcxK6Oi3C+60GyVdqe RHjfl4pyOBfOxqUWOuB8LNm6dMyaTPtJYQpEsgArpxR8VgDG9xfSlrE77GWwuW+VHrNi GZIc7Z+TaJ18KWt7ITbBT5h4YxZG7XUh1vJCNtEhqbpEUIRKsZaetu5YuCDWXxgzwMry qTxKZOfPs+hejfOaWj/yM+yDld12pOoYP8/N0kYCGv6iAnFmlc6xXtb8hkVM5rDVG2zf Xs+A== X-Gm-Message-State: APt69E0oANU4eeSWgA5JvY3ZjB3HMX3A+5OlMtRPs6g9JJcEgBXewV9Y ULyhkrEL2JTT3RPGs2DxfTIcQrJ2rkBxBm3FFPg= X-Google-Smtp-Source: AAOMgpe8r5iChAvVyT25/d0T+OUBCEVKJigSl+oIaLdl7kE+PfJFBzC15znvHBcZAR/BvR+xs9FFaNph3xu0+34SR20= X-Received: by 2002:a9d:3666:: with SMTP id w93-v6mr7502121otb.394.1530254203511; Thu, 28 Jun 2018 23:36:43 -0700 (PDT) MIME-Version: 1.0 References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> In-Reply-To: <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> From: Martin Thomson Date: Fri, 29 Jun 2018 16:36:33 +1000 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org, scratch@virgilsecurity.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 06:36:47 -0000 A few comments here (I'd comment on a PR if one existed :) Is "Contant" supposed to be the content of the message, a constant, or something else? Is "Msg" a label in the sense of the label passed to HKDF in TLS 1.3, or the the content of the message? Assuming the former, a 255 octet limit is probably plenty. You probably don't want to use the plaintext of the message for key derivation; then you won't be able to read messages out of order. Your PR-in-progress seems to imply that one use of HKDF is used. It might be best to have three derivations: one for the next key, one for the key, and another for the nonce. You don't seem to include the number of messages from the previous epoch in the counter. Is this just under the AAD? What happens if an endpoint doesn't send any messages in a given epoch? How is the count of messages from the previous epoch protected? (Sorry, too many questions. I'm sure that you'll sort most of these out.) On Fri, Jun 29, 2018 at 1:12 AM Katriel Cohn-Gordon wrot= e: > > I've been chatting with Alexey at Virgil Security, who has started work o= n a PR [1] to add this form of key separation. > > I think we all liked this design; shall we figure out exactly how it work= s? I like the idea of symmetric key chains so that each message has a separ= ate encryption key, as in Signal; that requires N and PN counters in the he= ader to figure out which key to use, which I guess should go into the authe= nticated data. > > Note that this means that each message key is used once, which helps guar= d against nonce reuse. > > best, > Katriel > > [1] https://github.com/ekr/mls-protocol/compare/master...Scratch-net:ma= ster > > On Thu, 28 Jun 2018, at 3:38 PM, Russ Housley wrote: > > Martin: > > > > Each sender using a separate key seems pretty easy. The key can be > > derived using the sender's position in the key or any other unique > > identifier that comes natural in the messaging protocol. > > > > Russ > > > > > > > On Jun 27, 2018, at 6:12 PM, Martin Thomson wrote: > > > > > > I was thinking that the nonce generation aspect would be worth lookin= g > > > into as well. If you crib from the TLS design, maybe you could have > > > per-participant keys so that each can be independently responsible fo= r > > > ensuring nonce-uniqueness. Then they can use counters to avoid nonce > > > reuse if they so choose. Otherwise, I was tempted to suggest AES-SIV > > > or another nonce-reuse-resistant scheme, but there are fewer of those > > > available than straight up AEADs. > > > On Thu, Jun 28, 2018 at 7:36 AM Russ Housley w= rote: > > >> > > >> > > >> > > >>> On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: > > >>> > > >>> Hey all, > > >>> > > >>> One of the things we kind of waved our hands about in the charter a= nd current protocol draft is message protection. That is, the idea of spec= ifying a concrete syntax for using the keys we negotiate using MLS to actua= lly protect content. > > >>> > > >>> This is a simpler problem than key exchange (since you've already e= stablished a group key), but it still has some nuances that matter to the o= verall 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 k= ey > > >>> - ACK / NACK / replay > > >>> - Transcript integrity (?) > > >>> - Expiration times (?) > > >>> > > >>> What's missing here? > > >> > > >> If the tree produces a key and an identifier for that key, then the = protocol is straightforward. > > >> > > >> The key identifier could be derived from the key itself so that anyo= ne that knows the key also knows the identifier. > > >> > > >> prk =3D HKDF-Extract('mls-key-id' | tree-identifier, key) > > >> > > >> keyid =3D HKDF-Expand(prk, '', sizeof(keyid)) > > >> > > >> Russ > > >> > > >> _______________________________________________ > > >> MLS mailing list > > >> MLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Jun 29 00:39:13 2018 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 B6244130E6A for ; Fri, 29 Jun 2018 00:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 4mxcxh_co1-E for ; Fri, 29 Jun 2018 00:39:09 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E84A130E09 for ; Fri, 29 Jun 2018 00:39:08 -0700 (PDT) Received: from BIGONE (unknown [176.226.241.68]) by VirgilSecurity.com (Postfix) with ESMTPSA id C8E9C105AA9916; Fri, 29 Jun 2018 03:39:06 -0400 (EDT) From: "Alexey Ermishkin" To: "'Martin Thomson'" , "'Katriel Cohn-Gordon'" Cc: References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> In-Reply-To: Date: Fri, 29 Jun 2018 12:39:04 +0500 Message-ID: <01e701d40f7c$430f3b20$c92db160$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLM+wAwts1qVAaFZnL+MDvDWV6A7AFj57CLAgaUFXIB7TBkbAEN949wAmCsBOaiPsZREA== Content-Language: ru Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:39:12 -0000 Hello, Alex here. Thanks for the comments, my reply below: Sorry for the typo, Contant == Constant. It's purely for domain separation. I'm not sure if nonce should be also derived as keys will be unique and used only once. It does not seem to affect security in either way. Signal is also using zero nonces for one time keys. As stated in the PR, each message includes 2 counters: 1) PN. Number of messages in previous epoch (can be zero) 2) N. Message number in the current epoch. Both of them are under AAD I think I'll add couple of amends and make a proper PR so that we could start a proper dialogue there -----Original Message----- From: MLS On Behalf Of Martin Thomson Sent: Friday, June 29, 2018 11:37 AM To: Katriel Cohn-Gordon Cc: mls@ietf.org; scratch@virgilsecurity.com Subject: Re: [MLS] Message Protection A few comments here (I'd comment on a PR if one existed :) Is "Contant" supposed to be the content of the message, a constant, or something else? Is "Msg" a label in the sense of the label passed to HKDF in TLS 1.3, or the the content of the message? Assuming the former, a 255 octet limit is probably plenty. You probably don't want to use the plaintext of the message for key derivation; then you won't be able to read messages out of order. Your PR-in-progress seems to imply that one use of HKDF is used. It might be best to have three derivations: one for the next key, one for the key, and another for the nonce. You don't seem to include the number of messages from the previous epoch in the counter. Is this just under the AAD? What happens if an endpoint doesn't send any messages in a given epoch? How is the count of messages from the previous epoch protected? (Sorry, too many questions. I'm sure that you'll sort most of these out.) On Fri, Jun 29, 2018 at 1:12 AM Katriel Cohn-Gordon wrote: > > I've been chatting with Alexey at Virgil Security, who has started work on a PR [1] to add this form of key separation. > > I think we all liked this design; shall we figure out exactly how it works? I like the idea of symmetric key chains so that each message has a separate encryption key, as in Signal; that requires N and PN counters in the header to figure out which key to use, which I guess should go into the authenticated data. > > Note that this means that each message key is used once, which helps guard against nonce reuse. > > best, > Katriel > > [1] > https://github.com/ekr/mls-protocol/compare/master...Scratch-net:maste > r > > On Thu, 28 Jun 2018, at 3:38 PM, Russ Housley wrote: > > Martin: > > > > Each sender using a separate key seems pretty easy. The key can be > > derived using the sender's position in the key or any other unique > > identifier that comes natural in the messaging protocol. > > > > Russ > > > > > > > On Jun 27, 2018, at 6:12 PM, Martin Thomson wrote: > > > > > > I was thinking that the nonce generation aspect would be worth > > > looking into as well. If you crib from the TLS design, maybe you > > > could have per-participant keys so that each can be independently > > > responsible for ensuring nonce-uniqueness. Then they can use > > > counters to avoid nonce reuse if they so choose. Otherwise, I was > > > tempted to suggest AES-SIV or another nonce-reuse-resistant > > > scheme, but there are fewer of those available than straight up AEADs. > > > On Thu, Jun 28, 2018 at 7:36 AM Russ Housley wrote: > > >> > > >> > > >> > > >>> On Jun 26, 2018, at 8:38 PM, Richard Barnes wrote: > > >>> > > >>> 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? > > >> > > >> If the tree produces a key and an identifier for that key, then the protocol is straightforward. > > >> > > >> The key identifier could be derived from the key itself so that anyone that knows the key also knows the identifier. > > >> > > >> prk = HKDF-Extract('mls-key-id' | tree-identifier, key) > > >> > > >> keyid = HKDF-Expand(prk, '', sizeof(keyid)) > > >> > > >> Russ > > >> > > >> _______________________________________________ > > >> MLS mailing list > > >> MLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls _______________________________________________ MLS mailing list MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls From nobody Fri Jun 29 00:57:43 2018 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 7D68112F295 for ; Fri, 29 Jun 2018 00:57:41 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jk2ndW0R6-Zz for ; Fri, 29 Jun 2018 00:57:40 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 D9179128BAC for ; Fri, 29 Jun 2018 00:57:39 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id f17-v6so9021615otl.7 for ; Fri, 29 Jun 2018 00:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7xEZMXd/yrNeNWH4UK0R4yGZn4CVrT9TzefhnlivuwQ=; b=XSUH8UpGSIq/z0ShQvGb11RYmYyjoZ2QTqmB6xlrqo+HneqW1yHZCHVNvtO45M1HXq glzy5JpI1u0SqTk/XU/U93dHzMesV8Q5l0chYYiHvWFxRa71jpjEpn/U7QTwffsPGJGJ mp4Xr3wh+92fxcsxgLeYFShlDPRUQsUcbYQarFRaLsfH5OF6SLWXfaici7/vUnX7YBBu KyGWy36UwKM9Juc97kKBjdc0aAoYmxEZiVRvhDmQ5lwT0j0c2uG20adQ0/gnxA+Vx5ZR VxCzZy3V4nDVXDnPNHPBzSdSJQgzhNkKMkI5A7UfaSlgjT/uGrlfhNhEGNZJD/2IZMz5 KYPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xEZMXd/yrNeNWH4UK0R4yGZn4CVrT9TzefhnlivuwQ=; b=BdZljtTa2iHyt7tWxQziqrfolhhX0GfJ1NWlnvmchjyr7K7Fyn0KcBqxIe5wtEFYQM lzQcB7xdQiodeYT4shXOgAr78pe8TBfRana73pbM8eKpzZUB0OnmtjXolX7eVt4Sdc76 Psydq3vkJ/9X9LwCMDv2msUNdqjk47xHBsNa8Pck54ylCacK0pAwdK53su09YXa7CIAl eP3pAbS3TY6EdV7kMxxoOxnMGipmOWI3kOAPh/TusBtmSElAmZSOy6IHAs9d+8+pItwc MK6DrWRqN8kazp5CBZGuVfNZvTnf6dhPK7GNbO6iV9g6AtQ6yKmeCbENmRCvE30s8v47 85Ng== X-Gm-Message-State: APt69E1WauxTH31mGoNNYa5Q6VTg5N89Bne4CXeb0XgUYzUfCVezMsDs vWNRHbso+tvf7PZj3Gw4eTe+et3ti6cF/Pbzcd8= X-Google-Smtp-Source: AAOMgpcfzXcNGs6d4tA5cby3UMSzgEO1Hqtc1mqAdH+oQVGnbto7/LgrWN0oTEJCkzSxk25NGcUbIGX3wLKh3IZAX0M= X-Received: by 2002:a9d:5211:: with SMTP id e17-v6mr3801422oth.396.1530259059232; Fri, 29 Jun 2018 00:57:39 -0700 (PDT) MIME-Version: 1.0 References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> <01e701d40f7c$430f3b20$c92db160$@virgilsecurity.com> In-Reply-To: <01e701d40f7c$430f3b20$c92db160$@virgilsecurity.com> From: Martin Thomson Date: Fri, 29 Jun 2018 17:57:29 +1000 Message-ID: To: scratch@virgilsecurity.com Cc: Katriel Cohn-Gordon , mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:57:42 -0000 On Fri, Jun 29, 2018 at 5:39 PM Alexey Ermishkin wrote: > I'm not sure if nonce should be also derived as keys will be unique and used > only once. It does not seem to affect security in either way. Signal is also > using zero nonces for one time keys. In TLS we chose to derive nonces so that it would become less feasible to do precomputation attacks. Messages are often predictable, and if you can calculate a table for common responses, it might be possible to have enough values stored to compromise confidentiality. (That was the argument; not sure how much weight it carries relative to just using a stronger primitive, but there you have it.)