From nobody Mon Mar 2 07:18:54 2020 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 4B6B83A08C2 for ; Mon, 2 Mar 2020 07:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 WzT_AUKHP4Z3 for ; Mon, 2 Mar 2020 07:18:45 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 BDEC93A08C4 for ; Mon, 2 Mar 2020 07:18:44 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id o18so33428qvf.1 for ; Mon, 02 Mar 2020 07:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=WiHZQr6G4Q/oGmYuX7Luda9KscGkbetnOTQJPF0BpFg=; b=a6wdTitUFAzQsBAU/vfggfHPzEzHtbqYQ6ocALiErJWhHE3peTjtkoQ1xaD77Osr5o bGVzE+o3XEQFFuZdE1WAgLdYqFaCRJb7SiwCNwJblqgkBgE8uJuXUCgdZ2z9le3tpAsk WZjd1ZliXRCkiMtljUr+KauTylwBebuEGmAjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=WiHZQr6G4Q/oGmYuX7Luda9KscGkbetnOTQJPF0BpFg=; b=A9fFJcorCO5prx4qgIcyVuupU2oSXANM2VrOqZqkiBY5oZ/wXolXd4Egad4NYk3MYa xxDh29rPoYaA7zX5c2ka4Mh6YyU+sClI0bVs9RAmKeKxKWDK3AFq43D1TAWbMw71Xsgw 8Bp6J/qtcmoZ8R8LwjxcbVTcpuYrO7/dxyIhKFU5E1asGJYUBTOxaiuOQFpmfNaA6ygt +2La0ytCry89ODsFk848uZFQxh5rEen/d5XWp+Ywu21FSo06+FKs/c16YXUxNWmU44HR Lz/Qv4CJIrMpogXvFAfTPAitX2etCv8IzyM4NZfowLk52/YsglWozyCxmWl3MZ8wVjlM cj+Q== X-Gm-Message-State: APjAAAUpg+ewKgDq7eSxdh3Zm/Q6HHksZuZUkYboDJ2DcRuh5OdaEGBY ov6u9Tr+XJsia6pUMlJ99ST3ARv7smQ= X-Google-Smtp-Source: APXvYqzbNe27i2UPrsyTmbxYmFBgdzj5UGEoYIDF45MdnFk1u78y0ka3pg1+EBzPWP0wYYpCCxs6Ew== X-Received: by 2002:a0c:d6cf:: with SMTP id l15mr15208009qvi.36.1583162323402; Mon, 02 Mar 2020 07:18:43 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id e15sm6653595qts.12.2020.03.02.07.18.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 07:18:42 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 2 Mar 2020 10:18:42 -0500 References: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: Message-Id: <33C22C29-09C1-408F-B63B-C07A364B8A5A@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming merge for PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 15:18:46 -0000 Richard when you get a chance land 283 and 304. Let=E2=80=99s hold off = on #296 until after this week=E2=80=99s call. spt > On Feb 26, 2020, at 11:28, Sean Turner wrote: >=20 > Hi! >=20 > Brendan noted on the call that he thought that we needed some more = discussion on #296. I see that he=E2=80=99s submitted a comment on the = PR. If we cannot come to closure on this on list, then we can discuss it = next week. >=20 > spt >=20 >> On Feb 25, 2020, at 12:29, Sean Turner wrote: >>=20 >> All, >>=20 >> The following PRs were 1st discussed at the 5-Feb virtual interim. = The WG discussed them again on the 1-Feb call and the editors believe = these are ready to merge. If have any objections to merging these please = provide your input by 2359 UTC 28-Feb otherwise we will declare = consensus and the will ask the editors to merge the PRs. >>=20 >> #283 Use the same ratchet for Handshake and Application keys >> https://github.com/mlswg/mls-protocol/pull/283 >>=20 >> #296 Flesh out the extensions story >> https://github.com/mlswg/mls-protocol/pull/296 >>=20 >> #304 Use HKDF to derive key pairs >> https://github.com/mlswg/mls-protocol/pull/304 >>=20 >> Cheers, >>=20 >> spt >>=20 >=20 From nobody Wed Mar 4 09:31:25 2020 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 5CAD23A1325 for ; Wed, 4 Mar 2020 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 GfXs9EWfzDGF for ; Wed, 4 Mar 2020 09:31:22 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 66F033A1324 for ; Wed, 4 Mar 2020 09:31:22 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id b13so1131700qvt.11 for ; Wed, 04 Mar 2020 09:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=SKt3ndroldCdjjpYWfuzNFQ696G2XzS01KVQvqn9968=; b=Z8xtsgsWKfl+R+FfH8V47CQrlnsgEnG4v0tuxSQYKQJnUPLUocEVbTVjG8562yRN7V SJqFLoUrvRCEcgrN88vAyWVn8ASp4kYkn2Jakmvj/01TryISj32TBXQ44NXA3mOrR456 +3xgGJXn7tOmu84GFhNXC6SVwWH/0sYY1SQoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=SKt3ndroldCdjjpYWfuzNFQ696G2XzS01KVQvqn9968=; b=uDvi5xfFM53H+lkKvmHpMNP6q4FeBKztIn55c6HFXwFYPenesz+j7SqsyzHLKBkrUA q10IF4VNgz+xQ4jhF3fP3gsnX/nB1fTH5Jb65g7turzQlceT7OusD5L9CKyUzPtyaJ06 hmXjZQ2GpDQyyQyA+gLIXCQa6VqGjeLEPHGI1dAUDDEHAvUxt6YwwfUuAy/NDIFnK9dj 6AM/aVO7P+cfEf+dtz95HNrBZs1woPbWw8+iLCCIuDQ7JIU84ehuBfQQIfXYAcudsFzV b2MfKrXrPZoDWk6jaV7iXjXTqONvKW6DuVxi8k/BBfLGpihmuplZWAUw7YiEiSKnq54Q VZCQ== X-Gm-Message-State: ANhLgQ2dcNaxkwO3vGL98lfgOKcVuC7MWPDhYlgnKhH1j/xBXeIrMBRZ m7oGyrZ/W1NlLPOC1hj4rc02yp2Ngi8= X-Google-Smtp-Source: ADFU+vthJsFbwwLGDZsCnGO3P7dC5VL2QQ8QfNHrSKgBMUfS9DTk+G9mcRN96lVjQG3Q7S29YGoxzw== X-Received: by 2002:ad4:5429:: with SMTP id g9mr2924412qvt.134.1583343080926; Wed, 04 Mar 2020 09:31:20 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id i26sm14290589qkl.66.2020.03.04.09.31.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2020 09:31:19 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Mar 2020 12:31:17 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> <72CD15F5-A839-4023-9CAF-0D8145966578@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <72CD15F5-A839-4023-9CAF-0D8145966578@sn3rd.com> Message-Id: <71C43AA7-C03A-4ABD-BE29-69AA8D7F678C@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 17:31:25 -0000 This week=E2=80=99s call was Britta and myself so we wrapped about = 10min. Nothing to report. The meeting minutes for the 2/19 and 2/26 minutes have been uploaded to = the datatracker. spt > On Feb 26, 2020, at 12:24, Sean Turner wrote: >=20 > Minutes for 2/19 (thanks Richard) and 2/26 meetings available now at = github: >=20 > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-19-2020.md >=20 > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-26-2020.md >=20 > spt >=20 >> On Feb 26, 2020, at 11:27, Sean Turner wrote: >>=20 >> Thanks to Brendan, Britta, and Ray for calling in today. >>=20 >> You=E2=80=99ll see some emails about the two topics we discussed = shortly. >>=20 >> spt >>=20 >>> On Feb 25, 2020, at 12:20, Sean Turner wrote: >>>=20 >>> Please note that there is another meeting tomorrow. Same time, = place, and details: >>>=20 >>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>> Meeting number: 647 391 156 >>> Password: ve2i8niw >>>=20 >>> spt >>>=20 >>>> On Feb 18, 2020, at 19:56, Sean Turner wrote: >>>>=20 >>>> Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: >>>>=20 >>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>> Meeting number: 647 391 156 >>>> Password: ve2i8niw >>>>=20 >>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>=20 >>>> spt >>>>=20 >>>>> On Feb 11, 2020, at 16:53, Sean Turner wrote: >>>>>=20 >>>>> As a reminder there is another virtual interim. This is the call = information: >>>>>=20 >>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>> Meeting number: 647 391 156 >>>>> Password: ve2i8niw >>>>>=20 >>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>=20 >>>>> spt >>>>>=20 >>>>>> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>>>>>=20 >>>>>> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>>>>>=20 >>>>>>> As a reminder, the recurring virtual interim is tomorrow. Here's = the meeting information: >>>>>>>=20 >>>>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>>>> Meeting number: 647 391 156 >>>>>>> Password: ve2i8niw >>>>>>>=20 >>>>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>>>=20 >>>>>>> Nick & Sean >>>>>>>=20 >>>>>>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>>>>>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>>>>>=20 >>>>>>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>>>>>=20 >>>>>>> Here's the proposed schedule (subject to AD approval): >>>>>>> Time: 1400-1500 GMT on Wednesdays >>>>>>> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>>>>>>=20 >>>>>>> Links to the conference calls are forthcoming. >>>>>>>=20 >>>>>>> Nick & Sean >>>>>>>=20 >>>>>>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes = wrote: >>>>>>> Also: Note that despite this poll listing specific dates, the = intent is to set up a weekly recurring meeting. In fact, these dates = will definitely not be the dates when the calls happen, because IETF = requires one week notice. >>>>>>>=20 >>>>>>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes = wrote: >>>>>>> I would like to have some weekly calls to make faster progress = on our outstanding PRs. Here's a Doodle to find a good time: >>>>>>>=20 >>>>>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>>>>>=20 >>>>>>> I believe these will need to be official Virtual Interims per = IETF process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>>>>>=20 >>>>>>> --Richard >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Mar 4 13:36:35 2020 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 123C63A0984 for ; Wed, 4 Mar 2020 13:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 rBZhgOoMEZaG for ; Wed, 4 Mar 2020 13:36:32 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 887A23A097E for ; Wed, 4 Mar 2020 13:36:32 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id eb12so1494128qvb.10 for ; Wed, 04 Mar 2020 13:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=cKYUaBLW7rcp8EhnFaaa/KhfVce8HKcwP75Y2gV9uD4=; b=aO+H/ctg0xTn/umvzct+ZkqtlQwnSm0Iwfmaf/gEoni2bB/C/8RcT8BgKui6rKQ2Uf zykDd3oS71/F4rfMKOi+iicU78/mLQomkM40fHZClN62xbYcERGrtzwuRYHCAuHnSKMQ OK2s28wUvtjvyFRbuXahMRitilhVCXCslMa28= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=cKYUaBLW7rcp8EhnFaaa/KhfVce8HKcwP75Y2gV9uD4=; b=klqCn4ZDxzLURrnNDVGCXMGf6i8yDLjRRwKv2WetO5TAdsfGW9pITzrWeOW7PaFRqr xn8mG2dP8Qb8Uyr54YZ054qLnya8epv4QRdxg4404ZJAB6mm6MUvaIb5YqYy95h6v7fy 5fO/licUKuONNna3KLjLFyc1x0jdFfKkHtJQlm4FsyRQD2dlWswciUG/XGjGZxUPy2aQ bJ6zQVuWUIq/oSSuAvsBD16E87pRTYMgycEbdwPFWxp+nI/jSRUCQsIks5AoDtt0Dhqd YL+PoF1X5SWc5dRgXeE3Elz8vjMuhS2id/4a5DH6uMOIaZY7YvdK5yup+U+oyY/ynY93 D74g== X-Gm-Message-State: ANhLgQ3YiNmvqmA7rRsTjeV2v+GKzIeshaXHPIatBaBv+bwWEgE6mpH6 RU+jsTEBvFCdlJGNNwyRlR5n9+eNQCQ= X-Google-Smtp-Source: ADFU+vupjqnUIu8jH5jjIFFzikz+OFASiaRGdCtw1VI3tmtseouriHe/qRNt5XGFfOKqrOlgpeCXdg== X-Received: by 2002:a0c:e406:: with SMTP id o6mr3606973qvl.136.1583357791148; Wed, 04 Mar 2020 13:36:31 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p53sm15425176qtb.85.2020.03.04.13.36.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2020 13:36:30 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Mar 2020 16:36:29 -0500 References: <2D478053-DBB9-440C-BF19-35BD489D7814@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <2D478053-DBB9-440C-BF19-35BD489D7814@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] MLS 2020 Spring Interim planning X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 21:36:34 -0000 Thanks to all those that responded. Based on the doodle poll we will = plan to schedule the interim for 7-8 May in Berlin. I will set the = wheels in motion to make it official. spt > On Jan 13, 2020, at 11:57, Sean Turner wrote: >=20 > All, >=20 > We are planning to have an MLS 2020 Spring F2F Interim sometime around = Eurocrypt, which is 10-14 May in Zagreb, Croatia. The location we are = considering is Berlin, because we have a host there. Please fill out = the following doodle poll to indicate your preference by 2359 UTC = 31-JAN-2020: >=20 > https://doodle.com/poll/cd5zr7aeax3dx4e7 >=20 > Cheers, >=20 > Nick & Sean >=20 >=20 From nobody Wed Mar 4 13:48:39 2020 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 118653A09B7; Wed, 4 Mar 2020 13:48:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls@ietf.org, mls-chairs@ietf.org, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158335851698.29475.5981759485587583523@ietfa.amsl.com> Date: Wed, 04 Mar 2020 13:48:37 -0800 Archived-At: Subject: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 21:48:37 -0000 A new interim meeting request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-10 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner City: Berlin Country: DE Session 1: Date: 2020-05-07 Start Time: 09:00 Europe/Berlin Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m0b5981050dd8f6e923fde6b5fb5835c1 Agenda Note: Session 2: Date: 2020-05-08 Start Time: 09:00 Europe/Berlin Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m0b5981050dd8f6e923fde6b5fb5835c1 Agenda Note: --------------------------------------------------------- From nobody Wed Mar 4 13:50:43 2020 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 EDAE03A09C4 for ; Wed, 4 Mar 2020 13:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 081S_IkT-tHQ for ; Wed, 4 Mar 2020 13:50:39 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 13F8F3A09BC for ; Wed, 4 Mar 2020 13:50:39 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id o18so1527802qvf.1 for ; Wed, 04 Mar 2020 13:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=64y9EWN1jhpEMrqo/dlM2KKu5ifzEK2EzjjoeCpsixU=; b=MVkdrMdbR5eZabDAdHmi9dIO8fJ1anfoj6QAictT203FlAYxXKnfJcD+erNIEAxXiT 1LYDt9eYcP+M7+sEi2jRHQmqz6Kdrf23i9Wa/KuNiacmIYHbG1AETD+SKEXcLPXKMzHB TXRYIYw0b5q/izu1UZL9iPwUwWGAM+zoK8jkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=64y9EWN1jhpEMrqo/dlM2KKu5ifzEK2EzjjoeCpsixU=; b=B0TWu7TmJdm5msY4zUuXtwgf+qbXs9OEHk3Jr0f1vTTcCM5m3ezDpO+9SiPG7xReqe bB0dK1XMZ6Gq4fSblQTCx+UUtBNxjBD7Q84j33qGWRQysb3DZVCbCpvvx5rn8CfDsif9 vwcc5lLYMF034Di6LwcGRis3y6SfFflWD38OsPnUwvwM7tUL00fgNL4hN0wk59Jj+cti VVmULBAwpc5uN+a8NcqM/C1TcuYWtViOgBABqI+/z9142qdTR9m8TY32jtu2N2Wi1Faq wyZcDDAZQOvZITb7En5yv3ynXMXFYhrAwrlNO9LBxA6XnLOgSuKroTn6QhAEWMQe8uk3 lYpA== X-Gm-Message-State: ANhLgQ3SQPYYMdJZOnaBjV4pF7tU3m/9Nxq5Z64+EIVhCCXTQWeQ/3EN n1ywvvrgrOz5aG5Fw6pJ9KqiKAMUl5I= X-Google-Smtp-Source: ADFU+vsqWyDUjTbu7NGG24+jn4gaxq6KqEZdoWqrPkOLMkgiaO/UqVplAWY04xnJUlhEGwlrz1SeZg== X-Received: by 2002:ad4:4e88:: with SMTP id dy8mr3939064qvb.118.1583358638224; Wed, 04 Mar 2020 13:50:38 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id a1sm14299108qkd.126.2020.03.04.13.50.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2020 13:50:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <158335851698.29475.5981759485587583523@ietfa.amsl.com> Date: Wed, 4 Mar 2020 16:50:36 -0500 Cc: Messaging Layer Security WG , MLS Chairs Content-Transfer-Encoding: quoted-printable Message-Id: <4ECF3DE1-B328-4F6D-888A-3353F0FAE586@sn3rd.com> References: <158335851698.29475.5981759485587583523@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 21:50:41 -0000 Ben, FYI - We were planning this well in advance of any COVID-19 worries. spt > On Mar 4, 2020, at 16:48, IETF Meeting Session Request Tool = wrote: >=20 >=20 > A new interim meeting request has just been submitted by Sean Turner. >=20 > This request requires approval by the Area Director of the Security = Area >=20 > The meeting can be approved here:=20 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-10 >=20 >=20 >=20 > --------------------------------------------------------- > Working Group Name: Messaging Layer Security > Area Name: Security Area > Session Requester: Sean Turner >=20 > City: Berlin > Country: DE >=20 >=20 > Session 1: >=20 > Date: 2020-05-07 > Start Time: 09:00 Europe/Berlin > Duration: 08:00 > Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm0b5981050dd8f6e923fde6b5fb5835c1= > Agenda Note:=20 > Session 2: >=20 > Date: 2020-05-08 > Start Time: 09:00 Europe/Berlin > Duration: 08:00 > Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm0b5981050dd8f6e923fde6b5fb5835c1= > Agenda Note:=20 >=20 > --------------------------------------------------------- >=20 >=20 From nobody Thu Mar 5 01:58:50 2020 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 29C153A117F for ; Thu, 5 Mar 2020 01:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gultsch-de.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 Mpyq-l2zmUwi for ; Thu, 5 Mar 2020 01:58:38 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 57D943A1169 for ; Thu, 5 Mar 2020 01:58:38 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id u17so5771206iog.11 for ; Thu, 05 Mar 2020 01:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gultsch-de.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/5dRTOdQ9zhlgYAc24Z5tAyiq/waM2/32IFyhmCd2nY=; b=j9I0UVM0ZzLKaq5/2cY9iinzsqBQDrFHnx5hlWSAuDR8xcjTmAWK9PvxqhmlbmL1mH fWRnsli1U/dokEC/HEkF0O0kazp+3lmGBKdXU4fmDFRE2KeG56neITr0qRPi8vhljg1n I+1cTtaloNLja75w5mkE6cc7at3Ofsdr5hT7HYdXw2Q77UAXbxlRgt3aT5uH1S+vDlst rDNVgGCwkQ/+OAap3TPe09FH7fhyRMHXhFOWIIR6DhACctIwd5mT4D+icrsNde6mYs3N 7cGGWyNqTxTYkfVq+oFjASYT/iCojlp4+7T6XvE+O4UH3wLHabu3/T49u6oAkn2/kFME s9+g== 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 :content-transfer-encoding; bh=/5dRTOdQ9zhlgYAc24Z5tAyiq/waM2/32IFyhmCd2nY=; b=gree4N0QHAt5ViN+Mv+gtEDyNIuzFTN4m6d0LIhsnSza5mz6U5szCnco55/lkG1D1o 5N2ANRd6pkS+h+dhHsbSNVNgCFSG51rZ2ZXW0njU82NB1axwflESh/nGFWFyjAAgtOG7 YLa9Kd1TyR6ItuM5JknWgjw4V4KUS4d9U4JHRhmdns+BHkSQBgenWg4HHoxZMA9SYf7L hvWjfNSg1kT15uWuhDaw44DvOJnkRUVOIUvCrExetO1kN62BB+3engHQQzfvM4YgS4/x CsA4eLLjZ1zJGvpW8m3i2WB1Brr9+iO5mfbuk7Vz2KP0sz/UoTBDLNPbQkbg+r9hDcrg exQw== X-Gm-Message-State: ANhLgQ33aEBM0RINIjdgp/Mrr+MdLsRDsa9NcEv7wOGdiRrnVVwQTfed uQNLcLfWCnJV333jyjJmbXkESoZ2FbJD4+BDK13sxNjcCOTvdw== X-Google-Smtp-Source: ADFU+vuD7M3Ez5q8aViasXjhJnZsFKkFnimZS92YVdt+7fL1Z4buMEPQGUg5kYlSxXYMY51vwAjcKzyYPTtcXxmvS/g= X-Received: by 2002:a5d:8790:: with SMTP id f16mr5557117ion.246.1583402317281; Thu, 05 Mar 2020 01:58:37 -0800 (PST) MIME-Version: 1.0 From: Daniel Gultsch Date: Thu, 5 Mar 2020 09:58:26 +0000 Message-ID: To: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [MLS] Question regarding DS rejecting (commit) messages with duplicate counter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 09:58:48 -0000 Hi, this is my first post on this mailing list so let me quickly introduce myself. I work on XMPP within the XMPP Standards Foundation. I=E2=80=99m th= e developer of an Android client called Conversations and I=E2=80=99m among t= he people who brought OMEMO into the XMPP world. I am not a cryptographer; I can use a library and that's it. I=E2=80=99m coming to MLS from a pure implementation perspective. So here is my question: I understand that commit messages have to arrive in order to be able to discard subsequent commit messages that try to commit on the same state. (See Section 11). So assuming that my DS can ensure a unique order of messages is it still necessary for the DS to reject messages with the same counter (As described in 11.1)? Wouldn=E2=80=99t the individu= al implementations be able to just take the first commit message and reject subsequent ones. (And then I guess the sender of the rejected commit message would have to learn that by applying the first commit message and resend their own commit message.) If keeping track counters (and rejecting duplicates) is something a DS needs to ensure (even though I don=E2=80=99t yet understand why) I think th= is is something that needs to be mentioned in the architecture document (as this seems like a slightly unusual feature for a messaging service). cheers Daniel From nobody Thu Mar 5 10:31:57 2020 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 AFC163A0924 for ; Thu, 5 Mar 2020 10:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=sn3rd.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 TsNibFurFnxk for ; Thu, 5 Mar 2020 10:31:52 -0800 (PST) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 CBBD83A091F for ; Thu, 5 Mar 2020 10:31:52 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id c19so2876150qvv.4 for ; Thu, 05 Mar 2020 10:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=AY7x+L7JzqEpM0NzKlOCLjQgU+oLjUIyoZXrBwLE9H8=; b=Fqe4CpUJkFvKu/ifCIgBG5zxOEBDDcAwZz2GscvkTKOKWvp4PIvt85yH9Xptc19OMB qdRWoBQtrzyxPqTIYjgmge9FxNAbN7pgnIyqCZuZ+eI7C9GGhaSbUmBDBeuO4Ln5JuhX 8B1+jvFKO/p98p7SIkfrT+Nw5Px7N+x9mQ6cQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=AY7x+L7JzqEpM0NzKlOCLjQgU+oLjUIyoZXrBwLE9H8=; b=dx7qOqA4zCFTjOtShHLVyWoeBGX6QL4FxQbMfyApaY7xnPhyacKHsICL30i1c5ecpm ykCBPrDA4XyFmJnCNY4NYgfFZLfU5yN1E+36g4tvK8hfrgLx8ghiy4EystPWNlg2ori3 m/PM4WzZAWcb+n2W3nqPUg7flQKCcM1qJz647HPbHNbiRtadetGhbbXW9BG1ZAVbZbU5 xWdZmMifyXgJSY6lx/0lg0vRDscwaAzuZqGKnuGM0FcIgF9o1BEwTU2nexJV9CoJswMA llkASOSNSDXfVuZqTZkEBFIu2P7jclT3N0pOrRJMlL57oJ5ERUGMOqVuTyeL7RkAoCC9 GQHw== X-Gm-Message-State: ANhLgQ2418loRAHlhK/H8ZL2ci0ubhP99i0wOK7iqvUpapSy0rrW42Yh FNsY2J68/CoLLhrCN7s3iUawf1MAxvQ= X-Google-Smtp-Source: ADFU+vvWQrxWAMIc9lNok0g1Z4BNDHk67nSJeADb4zxnJMVMFi2W0rij2jS3nvRfg+ruhkqEmXhYmg== X-Received: by 2002:a05:6214:209:: with SMTP id i9mr87113qvt.54.1583433111608; Thu, 05 Mar 2020 10:31:51 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id v12sm14836114qti.84.2020.03.05.10.31.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2020 10:31:50 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 5 Mar 2020 13:31:48 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> <72CD15F5-A839-4023-9CAF-0D8145966578@sn3rd.com> <71C43AA7-C03A-4ABD-BE29-69AA8D7F678C@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <71C43AA7-C03A-4ABD-BE29-69AA8D7F678C@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 18:31:55 -0000 Please note that I have requested that the remaining vInterims be = canceled. I think the 5 we had were very productive. spt > On Mar 4, 2020, at 12:31, Sean Turner wrote: >=20 > This week=E2=80=99s call was Britta and myself so we wrapped about = 10min. Nothing to report. >=20 > The meeting minutes for the 2/19 and 2/26 minutes have been uploaded = to the datatracker. >=20 > spt >=20 >> On Feb 26, 2020, at 12:24, Sean Turner wrote: >>=20 >> Minutes for 2/19 (thanks Richard) and 2/26 meetings available now at = github: >>=20 >> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-19-2020.md >>=20 >> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-26-2020.md >>=20 >> spt >>=20 >>> On Feb 26, 2020, at 11:27, Sean Turner wrote: >>>=20 >>> Thanks to Brendan, Britta, and Ray for calling in today. >>>=20 >>> You=E2=80=99ll see some emails about the two topics we discussed = shortly. >>>=20 >>> spt >>>=20 >>>> On Feb 25, 2020, at 12:20, Sean Turner wrote: >>>>=20 >>>> Please note that there is another meeting tomorrow. Same time, = place, and details: >>>>=20 >>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>> Meeting number: 647 391 156 >>>> Password: ve2i8niw >>>>=20 >>>> spt >>>>=20 >>>>> On Feb 18, 2020, at 19:56, Sean Turner wrote: >>>>>=20 >>>>> Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: >>>>>=20 >>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>> Meeting number: 647 391 156 >>>>> Password: ve2i8niw >>>>>=20 >>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>=20 >>>>> spt >>>>>=20 >>>>>> On Feb 11, 2020, at 16:53, Sean Turner wrote: >>>>>>=20 >>>>>> As a reminder there is another virtual interim. This is the call = information: >>>>>>=20 >>>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>>> Meeting number: 647 391 156 >>>>>> Password: ve2i8niw >>>>>>=20 >>>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>>> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>>>>>>=20 >>>>>>> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>>>>>>=20 >>>>>>> spt >>>>>>>=20 >>>>>>>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>>>>>>=20 >>>>>>>> As a reminder, the recurring virtual interim is tomorrow. = Here's the meeting information: >>>>>>>>=20 >>>>>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>>>>> Meeting number: 647 391 156 >>>>>>>> Password: ve2i8niw >>>>>>>>=20 >>>>>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>>>>=20 >>>>>>>> Nick & Sean >>>>>>>>=20 >>>>>>>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>>>>>>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>>>>>>=20 >>>>>>>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>>>>>>=20 >>>>>>>> Here's the proposed schedule (subject to AD approval): >>>>>>>> Time: 1400-1500 GMT on Wednesdays >>>>>>>> Agenda: the set of active PRs for the active documents on = Github (https://github.com/mlswg). >>>>>>>>=20 >>>>>>>> Links to the conference calls are forthcoming. >>>>>>>>=20 >>>>>>>> Nick & Sean >>>>>>>>=20 >>>>>>>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes = wrote: >>>>>>>> Also: Note that despite this poll listing specific dates, the = intent is to set up a weekly recurring meeting. In fact, these dates = will definitely not be the dates when the calls happen, because IETF = requires one week notice. >>>>>>>>=20 >>>>>>>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes = wrote: >>>>>>>> I would like to have some weekly calls to make faster progress = on our outstanding PRs. Here's a Doodle to find a good time: >>>>>>>>=20 >>>>>>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>>>>>>=20 >>>>>>>> I believe these will need to be official Virtual Interims per = IETF process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Mar 5 10:45:00 2020 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 8706F3A0963 for ; Thu, 5 Mar 2020 10:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 LLjviTpMCWmZ for ; Thu, 5 Mar 2020 10:44:56 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 028213A0962 for ; Thu, 5 Mar 2020 10:44:55 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id p62so6351349qkb.0 for ; Thu, 05 Mar 2020 10:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=371RBCuXDxggMxQzNPE5NN9KewRCg3K9mrPiNJqdqHY=; b=EaDfok1e6ihTc+0ndDAHtZ4c/EV1TsG5j+RUlxpQ7hk2se6OkJYxbEpEh+cfdcCaD/ dVNmDDLWzcIG6pbEtmeqvtxogjO/TcuueR3R+mP1WVHNyjRtjzAXbSILhxswoVoTlfBT WlNmdzAu6kcAlnjFU/04lFrzl9M7RBGXkVdzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=371RBCuXDxggMxQzNPE5NN9KewRCg3K9mrPiNJqdqHY=; b=cG8PJjFbfBICvmoCVY2XtosZKV7iaR+kyIwPxsf3OCUztWbosBStC7/8rBafbDKxE7 hfT+r1hIqFdnv6xEaEDq50gifGMNs3ZA7Rji9tAO9xPPYX/UPwz3EtSmt2c2F184Aaof c80115tYUQSVBUvfFpNMM2+icqO3+xDcVcM3q3ToCVXx8+A08RJCV67irLhqlCqLPcg2 ciTbzEkQ5I0JwSINJhr2PpzDHS5DxscTzw+UVevdCVjvtq+TAaezK5BY03/BPm7Y8mO8 T/bi+5CarqXuFZZ/ZPB/mfQ1hT+M4+CgBr3Dptc0ADdmX9h5HsvyK4QnXuGQWnaCq409 0Phg== X-Gm-Message-State: ANhLgQ1eXYQQoEbFh6AmV8Avyg7xB2wvMsAz+KqgJYouJCeEzSAP9Xc1 pysNYagpUIEUkwj82GnZJhchIi1Ngj8= X-Google-Smtp-Source: ADFU+vvmw4/TIvojhWM/TAWSDtFepGjxirPh0scL6XcciyOWi3/QuLIySOUsxr4HcuIBgtZ9gRlruQ== X-Received: by 2002:a05:620a:8c8:: with SMTP id z8mr9810426qkz.205.1583433894616; Thu, 05 Mar 2020 10:44:54 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 79sm16395720qkf.129.2020.03.05.10.44.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2020 10:44:53 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 5 Mar 2020 13:44:52 -0500 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> Message-Id: <58D2D973-B1D3-45C7-89AA-53689C24B813@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 18:44:59 -0000 All, We have confirmed the rough consensus that the protocol will support one = signature scheme for the lifetime of the group. Richard - This means you can merge #279, #304, and #307 (I believe these = are the right PRs). Note that we recognize the consensus is rough and if we got it wrong we = can change it later. Nick and Sean > On Feb 26, 2020, at 11:28, Sean Turner wrote: >=20 > There seems to be rough consensus (stressing the rough) to go with one = scheme per group. By rough consensus, I mean there seems to be a = willingness by the group to live with this decision and nobody is super = bent out of shape about it. Technically, that=E2=80=99s all we need to = move forward, but there are some concerns concerns that since it=E2=80=99s= such a small group and there are so few strong voices for the choice = that we should give it just a bit more time. So, I am extending this = call until 2359 UTC 2 March (i.e., Monday night). >=20 > Also, there are really three ciphersuite-related decisions being made, = as noted in the email below. >=20 > spt >=20 >> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>=20 >> I will not be able to make the call tomorrow, so to summarize my = opinion on this: >>=20 >> * I am OK with merging the current PR >> * I have a slight preference for *not* including the sig alg in the = ciphersuite >> * The simplicity case for including it seems reasonable, but not = dispositive >> * In any case, I don't care strongly one way or another; I care more = about progress >> * This is an easy change to revert if we change our minds later >> * Credentials are going to indicate the signature algorithm anyway >> * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >>=20 >>=20 >> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: >> Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: >> - the related PRs: >> https://github.com/mlswg/mls-protocol/pull/279 >> https://github.com/mlswg/mls-protocol/pull/307 >> - the messages in this thread >> - the issues Britta outlined: >> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>=20 >> We would like to close this issue out tomorrow. >>=20 >> Cheers, >>=20 >> spt >>=20 >>> On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: >>>=20 >>> Hi Britta, >>>=20 >>> I think you sum it up very nicely. There is one (albeit somewhat = speculative) >>> argument why a single ciphersuite per group might actually be = beneficial in a >>> federation context. In the event that there is "global concensus" = that a >>> ciphersuite needs to be deprecated, my expectation would be that a = majority of >>> the federation nodes/application providers would move to ban those = ciphersuits, >>> excluding anyone who would use _exclusively_ that ciphersuite. That = would in >>> turn be a motivation for all other nodes/application providers to = catch up as >>> well. This also means that nodes can't be made (by whatever = authority) to use >>> weak ciphersuites exclusively and still expect to federate with = other nodes that >>> have more sensible policies. >>>=20 >>> That's mostly my guess of how the dynamics in such a federated = environment >>> _could_ work, though. Anyone here with some actual = experience/expertise they can >>> share of what the dynamics could be? >>>=20 >>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just = seems a lot >>> simpler and even in the context of federation, I think that most >>> nodes/application providers would allow several ciphersuites to = begin with, >>> where not all of them are weak, meaning no one would really be = excluded too quickly. >>>=20 >>> Cheers, >>> Konrad >>>=20 >>>=20 >>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>> Under the topic of individual/single signature schemes there is the = final issue of federation. In a federated context, groups are no longer = under the control of a single application, meaning that we would lose = some control in forcing good ciphersuite choices. This could lead to two = issues: >>>>=20 >>>> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 >>>>=20 >>>> 2) Healing would take longer. Since no one application has a master = view and control over ciphersuites, upgrading long-lived groups using = questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= >>>>=20 >>>> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 >>>>=20 >>>> (Note that this is thinking in the long-term context. Obviously we = do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and = cipher breaks over the span of several years.) >>>>=20 >>>> Under all the considerations that I have seen so far, the pros and = cons on both sides place the individual signature cipher option in the = lead. However that lead is small, hence why I have not been arguing for = it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). >>>>=20 >>>> --- >>>>=20 >>>> Britta=20 >>>>=20 >>>>=20 >>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: >>>>=20 >>>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>>=20 >>>> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 >>>>=20 >>>> All the best, >>>>=20 >>>> Britta=20 >>>>=20 >>>>=20 >>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: >>>>=20 >>>> Hi! >>>>=20 >>>> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation >>>>=20 >>>> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >>>>=20 >>>> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. >>>>=20 >>>> The MLS cipher suites defined were as follows:=20 >>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>=20 >>>> At the interim, the consensus was to make the non-NIST suites = the MTI. The rationale was that those implementation that need to be = NIST compliant will do so regardless of the choice made by the WG. >>>>=20 >>>> In looking at the actual cipher suites, it was noted that the = 256-bit schemes the SHA should be SHA-512. The rationale agreed was that = SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one = less operation. >>>>=20 >>>> To avoid the proliferation of cipher suites, guidance will be = provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: >>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>> - (P-256, AES-GCM, P-256) - Compliance >>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>=20 >>>> The chairs need to confirm the interim=E2=80=99s consensus on = list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. >>>>=20 >>>> NOTE: The final text will obviously be reviewed, but is being = composed as part of the following PR: >>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>=20 >>>> NOTE: We combined these cipher suite related consensus = points, but if we only come to consensus on some of these we can still = incorporate what we do agree on. >>>>=20 >>>> Cheers, >>>>=20 >>>> Nick and Sean >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Thu Mar 5 11:02:20 2020 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 8F4613A09AC for ; Thu, 5 Mar 2020 11:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 mccZb6B8GuDP for ; Thu, 5 Mar 2020 11:02:10 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 DFC3A3A09C5 for ; Thu, 5 Mar 2020 11:02:09 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id d22so5005520qtn.0 for ; Thu, 05 Mar 2020 11:02:09 -0800 (PST) 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=PKi8UpX3h+n+bemWTZyVHpydzzicm2zwm/S0u7jScVw=; b=LIJDXA64jVGDEhnunRyGAe3qBGeJAifQY11G/lnjXNbKtFOe4sWubJvzLpTcQnR5ZP D9jdC2rVzuavO/ihaIEOa0p2FlfeZtk0osoa7UmbFLuhe5hWxo+OkPNyfurOiBSUI3jF Uyp+U3+TdXcl1sR5CAKzJ1EUIX2wFZazYGb+IZ+6XSwcQQCXk8nQtOJhY8V5jPZVDN0O Clemki/wFqfL+VbCup/DhMAod4QdLippnyGXUuGCDin86yDXKLjs8SsJ1STrgZAZpeog +JeIjwDMJm218bfWUlmNM6hiCrjftrt8tzHv1Z3hDseIagd/T7sSmgYjjC4r6pwgCx22 VYOQ== 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=PKi8UpX3h+n+bemWTZyVHpydzzicm2zwm/S0u7jScVw=; b=kg4cf2MAO2yml8y/1pt/biGZbxSrwbfltYiLyR0WGJwa0iuMSjlgXRE+CdnkupjZtx zz1XhleU7l0g/lGjH3mJn+zXRZtBu/Yo2S+BuC0SkzLTIqpKhZYRYSGShAG2WdrjlI92 WnsBr2W+i8gBK6yvzIPXWyyJ76Sgx5VW16esDAKY5BsSHvW40oAIZ2cYr6SKKiBKr5FW iOHI2iEKejfJuHoD5bGvlohgvI4xE0dnyDlBcrvp+v0h1JZuIc22v/Wnnn/StZypQ/mP HU3Olfsf95a9Bxi1syfZVIYj2iWGitsY640+yQX2kmUWlvWC3esbg2eSrV2h+l1+Bpiw yHeQ== X-Gm-Message-State: ANhLgQ0BNMaCLuBkTlvR7jvOMXxc6SsCScXTTXVT4c/QZOlUV2VmUtFF ifNz539m5irUKoiKLDvVIAAK8Vz3aZkmbf2mXahaq5Li9zI= X-Google-Smtp-Source: ADFU+vuULNJuU/klR5PrKKfgz5xHzqgmnPv2cBy6WOIVt9I5ko8kc1Si3mT7A+vZL+6YsZXU7Le83Mfynnp9VdUjnCg= X-Received: by 2002:ac8:1e90:: with SMTP id c16mr99348qtm.265.1583434927401; Thu, 05 Mar 2020 11:02:07 -0800 (PST) MIME-Version: 1.0 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <58D2D973-B1D3-45C7-89AA-53689C24B813@sn3rd.com> In-Reply-To: <58D2D973-B1D3-45C7-89AA-53689C24B813@sn3rd.com> From: Richard Barnes Date: Thu, 5 Mar 2020 11:01:53 -0800 Message-ID: To: Sean Turner Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005f819105a0202ccf" Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 19:02:14 -0000 --0000000000005f819105a0202ccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Sean. I will proceed to get things merged. As I think I said up-thread, changing it later should be straightforward. On Thu, Mar 5, 2020 at 10:45 AM Sean Turner wrote: > All, > > We have confirmed the rough consensus that the protocol will support one > signature scheme for the lifetime of the group. > > Richard - This means you can merge #279, #304, and #307 (I believe these > are the right PRs). > > Note that we recognize the consensus is rough and if we got it wrong we > can change it later. > > Nick and Sean > > > On Feb 26, 2020, at 11:28, Sean Turner wrote: > > > > There seems to be rough consensus (stressing the rough) to go with one > scheme per group. By rough consensus, I mean there seems to be a > willingness by the group to live with this decision and nobody is super > bent out of shape about it. Technically, that=E2=80=99s all we need to mo= ve > forward, but there are some concerns concerns that since it=E2=80=99s suc= h a small > group and there are so few strong voices for the choice that we should gi= ve > it just a bit more time. So, I am extending this call until 2359 UTC 2 > March (i.e., Monday night). > > > > Also, there are really three ciphersuite-related decisions being made, > as noted in the email below. > > > > spt > > > >> On Feb 25, 2020, at 13:24, Richard Barnes wrote: > >> > >> I will not be able to make the call tomorrow, so to summarize my > opinion on this: > >> > >> * I am OK with merging the current PR > >> * I have a slight preference for *not* including the sig alg in the > ciphersuite > >> * The simplicity case for including it seems reasonable, but not > dispositive > >> * In any case, I don't care strongly one way or another; I care more > about progress > >> * This is an easy change to revert if we change our minds later > >> * Credentials are going to indicate the signature algorithm anyway > >> * So the only difference in spec is whether endpoints check > Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm > >> > >> > >> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: > >> Note that the main point of the telecon tomorrow is to address the > cipher suite issue. Please take the time to review: > >> - the related PRs: > >> https://github.com/mlswg/mls-protocol/pull/279 > >> https://github.com/mlswg/mls-protocol/pull/307 > >> - the messages in this thread > >> - the issues Britta outlined: > >> > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilI= dFKw14/edit?usp=3Dsharing > >> > >> We would like to close this issue out tomorrow. > >> > >> Cheers, > >> > >> spt > >> > >>> On Feb 19, 2020, at 01:09, Konrad Kohbrok < > konrad.kohbrok@datashrine.de> wrote: > >>> > >>> Hi Britta, > >>> > >>> I think you sum it up very nicely. There is one (albeit somewhat > speculative) > >>> argument why a single ciphersuite per group might actually be > beneficial in a > >>> federation context. In the event that there is "global concensus" tha= t > a > >>> ciphersuite needs to be deprecated, my expectation would be that a > majority of > >>> the federation nodes/application providers would move to ban those > ciphersuits, > >>> excluding anyone who would use _exclusively_ that ciphersuite. That > would in > >>> turn be a motivation for all other nodes/application providers to > catch up as > >>> well. This also means that nodes can't be made (by whatever authority= ) > to use > >>> weak ciphersuites exclusively and still expect to federate with other > nodes that > >>> have more sensible policies. > >>> > >>> That's mostly my guess of how the dynamics in such a federated > environment > >>> _could_ work, though. Anyone here with some actual > experience/expertise they can > >>> share of what the dynamics could be? > >>> > >>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just > seems a lot > >>> simpler and even in the context of federation, I think that most > >>> nodes/application providers would allow several ciphersuites to begin > with, > >>> where not all of them are weak, meaning no one would really be > excluded too quickly. > >>> > >>> Cheers, > >>> Konrad > >>> > >>> > >>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >>>> Under the topic of individual/single signature schemes there is the > final issue of federation. In a federated context, groups are no longer > under the control of a single application, meaning that we would lose som= e > control in forcing good ciphersuite choices. This could lead to two issue= s: > >>>> > >>>> 1) MLS would move closer to facing the TLS problem of having old > suites supported by edge cases, which in turn weaken the entire group's > security. There is always the argument that groups would simply refuse > joiners that do not support the current group cipher, but this is not ver= y > practical from a usability view. E.g. if everyone using application X > refused group members who were using application Y, then the point of > federation would be largely defeated. So, either some form of renegotiati= on > is allowed (e.g. export psk) and downgrade becomes more likely, or > federation does not work reliably. > >>>> > >>>> 2) Healing would take longer. Since no one application has a master > view and control over ciphersuites, upgrading long-lived groups using > questionable ciphers could take a significant amount of time (all > applications would need to do so in order for the group to upgrade) or > alternatively result in kicking group members out of the group (again, > possible, but questionable for usability except in extreme cases). Under = an > individual cipher choice, any one member can choose/upgrade their scheme, > allowing for faster adaptability and potential benefits to PCS. > >>>> > >>>> From the above, it seems that a single group cipher makes federation > harder/slower/less secure, but I may not have a clear view on how > federation would work in this context. Does anyone know whether the above > are really concerns or not relevant due to other reasons? > >>>> > >>>> (Note that this is thinking in the long-term context. Obviously we d= o > not want to standardize any cipher choice that is sub-optimal; however an= y > number of things may happen with protocol versioning and cipher breaks ov= er > the span of several years.) > >>>> > >>>> Under all the considerations that I have seen so far, the pros and > cons on both sides place the individual signature cipher option in the > lead. However that lead is small, hence why I have not been arguing for i= t. > The issue of federation could be a deciding factor. If we want federation > in the future it is of course better not to build inhibiting factors into > MLS now that could undermine either usability or security in such context= s. > To make a case to proceed with the single group cipher option, it would b= e > great if someone could provide a convincing argument as to why it would b= e > the best option for usability and security in the federated environment (= or > preclude a federated use-case altogether). > >>>> > >>>> --- > >>>> > >>>> Britta > >>>> > >>>> > >>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = < > mls-bounces@ietf.org on behalf of britta.hale@nps.edu> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Concerning the use of a single group signature scheme or individua= l > signature schemes, it is probably worthwhile to expand on the considerati= on > points and clarify what security implications we are accepting - in eithe= r > case. I have listed out some issues in the following Google doc: > >>>> > >>>> > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilI= dFKw14/edit?usp=3Dsharing > >>>> > >>>> I am not making an argument for either case at this point, but > pushing this out for discussion and to help us achieve more clarity as to > the benefits and consequences of either choice. There are certainly more > issues to consider (e.g. ease of implementation, efficiency, etc. in > addition to security considerations) and other views - feel free to add > them or discuss on the mailing list. > >>>> > >>>> All the best, > >>>> > >>>> Britta > >>>> > >>>> > >>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" < > mls-bounces@ietf.org on behalf of sean@sn3rd.com> wrote: > >>>> > >>>> Hi! > >>>> > >>>> tl;dr: confirming MTI suite selections and rationale for > avoiding proliferation > >>>> > >>>> During the F2F Interim in January, the WG discussed cipher > suites-related issues. Namely, whether a per-group signature scheme shoul= d > be driven by the chosen cipher suite, what were the MTI (Mandatory To > Implement) cipher suites, and what the actual algorithm should be. > >>>> > >>>> There was rough agreement that there should be one signature > scheme per group and that should be driven by the cipher suite. There are= , > at least, three things to consider: 1) if a potential group member does n= ot > support the algorithm, then they will not become a member or the group wi= ll > need to downgrade; 2) when the group needs/wants to update, it is a flag > day; and, 3) the cipher suites will have a similar combinatorial issues a= s > the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough= =E2=80=9D because > 1) likely has some important implications. > >>>> > >>>> The MLS cipher suites defined were as follows: > >>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >>>> > >>>> At the interim, the consensus was to make the non-NIST suites > the MTI. The rationale was that those implementation that need to be NIS= T > compliant will do so regardless of the choice made by the WG. > >>>> > >>>> In looking at the actual cipher suites, it was noted that the > 256-bit schemes the SHA should be SHA-512. The rationale agreed was that > SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less > operation. > >>>> > >>>> To avoid the proliferation of cipher suites, guidance will be > provided to be conservative about allocating new code points. The consens= us > at the interim was that the suites provided were minimal and provided goo= d > coverage for the known use cases: > >>>> - (X25519, AES-GCM, Ed25519) - Good for desktop > >>>> - (P-256, AES-GCM, P-256) - Compliance > >>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >>>> > >>>> The chairs need to confirm the interim=E2=80=99s consensus on = list, so > please let the WG know by 2359 UTC 20 February whether you disagree with > these choices and why. > >>>> > >>>> NOTE: The final text will obviously be reviewed, but is being > composed as part of the following PR: > >>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>> > >>>> NOTE: We combined these cipher suite related consensus points, > but if we only come to consensus on some of these we can still incorporat= e > what we do agree on. > >>>> > >>>> Cheers, > >>>> > >>>> Nick and Sean > >>>> _______________________________________________ > >>>> 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 > >> > >> _______________________________________________ > >> 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 > --0000000000005f819105a0202ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Sean.=C2=A0 I will proceed to get things merged.= =C2=A0 As I think I said up-thread, changing it later should be straightfor= ward.

On Thu, Mar 5, 2020 at 10:45 AM Sean Turner <sean@sn3rd.com> wrote:
All,

We have confirmed the rough consensus that the protocol will support one si= gnature scheme for the lifetime of the group.

Richard - This means you can merge #279, #304, and #307 (I believe these ar= e the right PRs).

Note that we recognize the consensus is rough and if we got it wrong we can= change it later.

Nick and Sean

> On Feb 26, 2020, at 11:28, Sean Turner <sean@sn3rd.com> wrote:
>
> There seems to be rough consensus (stressing the rough) to go with one= scheme per group. By rough consensus, I mean there seems to be a willingne= ss by the group to live with this decision and nobody is super bent out of = shape about it. Technically, that=E2=80=99s all we need to move forward, bu= t there are some concerns concerns that since it=E2=80=99s such a small gro= up and there are so few strong voices for the choice that we should give it= just a bit more time. So, I am extending this call until 2359 UTC 2 March = (i.e., Monday night).
>
> Also, there are really three ciphersuite-related decisions being made,= as noted in the email below.
>
> spt
>
>> On Feb 25, 2020, at 13:24, Richard Barnes <rlb@ipv.sx> wrote= :
>>
>> I will not be able to make the call tomorrow, so to summarize my o= pinion on this:
>>
>> * I am OK with merging the current PR
>>=C2=A0 * I have a slight preference for *not* including the sig alg= in the ciphersuite
>>=C2=A0 * The simplicity case for including it seems reasonable, but= not dispositive
>>=C2=A0 * In any case, I don't care strongly one way or another;= I care more about progress
>> * This is an easy change to revert if we change our minds later >>=C2=A0 * Credentials are going to indicate the signature algorithm = anyway
>>=C2=A0 * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm
>>
>>
>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner <sean@sn3rd.com> wrote:
>> Note that the main point of the telecon tomorrow is to address the= cipher suite issue.=C2=A0 Please take the time to review:
>> - the related PRs:
>> https://github.com/mlswg/mls-protocol/pull/27= 9
>> https://github.com/mlswg/mls-protocol/pull/30= 7
>> - the messages in this thread
>> - the issues Britta outlined:
>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMt= dSilIdFKw14/edit?usp=3Dsharing
>>
>> We would like to close this issue out tomorrow.
>>
>> Cheers,
>>
>> spt
>>
>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok <konrad.kohbrok@datashrine= .de> wrote:
>>>
>>> Hi Britta,
>>>
>>> I think you sum it up very nicely. There is one (albeit somewh= at speculative)
>>> argument why a single ciphersuite per group might actually be = beneficial in a
>>> federation context. In the event that there is "global co= ncensus" that a
>>> ciphersuite needs to be deprecated, my expectation would be th= at a majority of
>>> the federation nodes/application providers would move to ban t= hose ciphersuits,
>>> excluding anyone who would use _exclusively_ that ciphersuite.= That would in
>>> turn be a motivation for all other nodes/application providers= to catch up as
>>> well. This also means that nodes can't be made (by whateve= r authority) to use
>>> weak ciphersuites exclusively and still expect to federate wit= h other nodes that
>>> have more sensible policies.
>>>
>>> That's mostly my guess of how the dynamics in such a feder= ated environment
>>> _could_ work, though. Anyone here with some actual experience/= expertise they can
>>> share of what the dynamics could be?
>>>
>>> Overall, I think I'm in favor of one-ciphersuite-per-group= . It just seems a lot
>>> simpler and even in the context of federation, I think that mo= st
>>> nodes/application providers would allow several ciphersuites t= o begin with,
>>> where not all of them are weak, meaning no one would really be= excluded too quickly.
>>>
>>> Cheers,
>>> Konrad
>>>
>>>
>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote:
>>>> Under the topic of individual/single signature schemes the= re is the final issue of federation. In a federated context, groups are no = longer under the control of a single application, meaning that we would los= e some control in forcing good ciphersuite choices. This could lead to two = issues:
>>>>
>>>> 1) MLS would move closer to facing the TLS problem of havi= ng old suites supported by edge cases, which in turn weaken the entire grou= p's security. There is always the argument that groups would simply ref= use joiners that do not support the current group cipher, but this is not v= ery practical from a usability view. E.g. if everyone using application X r= efused group members who were using application Y, then the point of federa= tion would be largely defeated. So, either some form of renegotiation is al= lowed (e.g. export psk) and downgrade becomes more likely, or federation do= es not work reliably.
>>>>
>>>> 2) Healing would take longer. Since no one application has= a master view and control over ciphersuites, upgrading long-lived groups u= sing questionable ciphers could take a significant amount of time (all appl= ications would need to do so in order for the group to upgrade) or alternat= ively result in kicking group members out of the group (again, possible, bu= t questionable for usability except in extreme cases). Under an individual = cipher choice, any one member can choose/upgrade their scheme, allowing for= faster adaptability and potential benefits to PCS.
>>>>
>>>> From the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on ho= w federation would work in this context. Does anyone know whether the above= are really concerns or not relevant due to other reasons?
>>>>
>>>> (Note that this is thinking in the long-term context. Obvi= ously we do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and cipher= breaks over the span of several years.)
>>>>
>>>> Under all the considerations that I have seen so far, the = pros and cons on both sides place the individual signature cipher option in= the lead. However that lead is small, hence why I have not been arguing fo= r it. The issue of federation could be a deciding factor. If we want federa= tion in the future it is of course better not to build inhibiting factors i= nto MLS now that could undermine either usability or security in such conte= xts. To make a case to proceed with the single group cipher option, it woul= d be great if someone could provide a convincing argument as to why it woul= d be the best option for usability and security in the federated environmen= t (or preclude a federated use-case altogether).
>>>>
>>>> ---
>>>>
>>>> Britta
>>>>
>>>>
>>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale,= Britta (CIV)" <mls-bounces@ietf.org on behalf of britta.hale@nps.edu> wrote:
>>>>
>>>>=C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0Concerning the use of a single group signature= scheme or individual signature schemes, it is probably worthwhile to expan= d on the consideration points and clarify what security implications we are= accepting - in either case. I have listed out some issues in the following= Google doc:
>>>>
>>>>=C2=A0 =C2=A0https://docs.google.com/document/d/1ZDs4KGp0_6kp= QZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=3Dsharing
>>>>
>>>>=C2=A0 =C2=A0I am not making an argument for either case at= this point, but pushing this out for discussion and to help us achieve mor= e clarity as to the benefits and consequences of either choice. There are c= ertainly more issues to consider (e.g. ease of implementation, efficiency, = etc. in addition to security considerations) and other views - feel free to= add them or discuss on the mailing list.
>>>>
>>>>=C2=A0 =C2=A0All the best,
>>>>
>>>>=C2=A0 =C2=A0Britta
>>>>
>>>>
>>>>=C2=A0 =C2=A0On 2/6/20, 8:11 AM, "MLS on behalf of Sea= n Turner" <mls-bounces@ietf.org on behalf of sean@sn3rd.com> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi!
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0tl;dr: confirming MTI suite sele= ctions and rationale for avoiding proliferation
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0During the F2F Interim in Januar= y, the WG discussed cipher suites-related issues. Namely, whether a per-gro= up signature scheme should be driven by the chosen cipher suite, what were = the MTI (Mandatory To Implement) cipher suites, and what the actual algorit= hm should be.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0There was rough agreement that t= here should be one signature scheme per group and that should be driven by = the cipher suite. There are, at least, three things to consider: 1) if a po= tential group member does not support the algorithm, then they will not bec= ome a member or the group will need to downgrade; 2) when the group needs/w= ants to update, it is a flag day; and, 3) the cipher suites will have a sim= ilar combinatorial issues as the TLS cipher suites prior to TLS 1.3. The ag= reement was =E2=80=9Crough=E2=80=9D because 1) likely has some important im= plications.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The MLS cipher suites defined we= re as follows:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_128_HPKEX25519_AES128GCM= _SHA256_Ed25519
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_128_HPKEP256_AES128GCM_S= HA256_P256
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_128_HPKEX25519_CHACHA20P= OLY1305_SHA256_Ed25519
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_256_HPKEX448_AES256GCM_S= HA384_Ed448
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_256_HPKEP521_AES256GCM_S= HA384_P521
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- MLS10_256_HPKEX448_CHACHA20POL= Y1305_SHA384_Ed448
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0At the interim, the consensus wa= s to make the non-NIST suites the MTI.=C2=A0 The rationale was that those i= mplementation that need to be NIST compliant will do so regardless of the c= hoice made by the WG.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0In looking at the actual cipher = suites, it was noted that the 256-bit schemes the SHA should be SHA-512. Th= e rationale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-= 512 because it is one less operation.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0To avoid the proliferation of ci= pher suites, guidance will be provided to be conservative about allocating = new code points. The consensus at the interim was that the suites provided = were minimal and provided good coverage for the known use cases:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (X25519, AES-GCM, Ed25519) - G= ood for desktop
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (P-256, AES-GCM, P-256) - Comp= liance
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (X25519, ChachaPoly, Ed25519) = - Good for mobile
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The chairs need to confirm the i= nterim=E2=80=99s consensus on list, so please let the WG know by 2359 UTC 2= 0 February whether you disagree with these choices and why.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0NOTE: The final text will obviou= sly be reviewed, but is being composed as part of the following PR:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://git= hub.com/mlswg/mls-protocol/pull/279
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0NOTE: We combined these cipher s= uite related consensus points, but if we only come to consensus on some of = these we can still incorporate what we do agree on.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Nick and Sean
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0________________________________= _______________
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MLS mailing list
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MLS@ietf.org
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf= .org/mailman/listinfo/mls
>>>>
>>>>
>>>>=C2=A0 =C2=A0______________________________________________= _
>>>>=C2=A0 =C2=A0MLS mailing list
>>>>=C2=A0 =C2=A0MLS@ietf.org
>>>>=C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/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<= br> >>
>> _______________________________________________
>> 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
--0000000000005f819105a0202ccf-- From nobody Thu Mar 5 11:40:44 2020 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 B37C53A0A68; Thu, 5 Mar 2020 11:40:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls-chairs@ietf.org, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158343723163.14570.7860261841293428757@ietfa.amsl.com> Date: Thu, 05 Mar 2020 11:40:31 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting Cancelled (was 2020-03-11) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 19:40:32 -0000 The Messaging Layer Security (mls) virtual interim meeting for 2020-03-11 from 14:00 to 15:00 UTC has been cancelled. From nobody Thu Mar 5 11:41:11 2020 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 50F7F3A0A74; Thu, 5 Mar 2020 11:40:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls-chairs@ietf.org, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158343725931.14655.2882820406861487308@ietfa.amsl.com> Date: Thu, 05 Mar 2020 11:40:59 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting Cancelled (was 2020-03-18) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 19:41:06 -0000 The Messaging Layer Security (mls) virtual interim meeting for 2020-03-18 from 14:00 to 15:00 UTC has been cancelled. From nobody Fri Mar 6 09:14:56 2020 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 3145B3A0B2C; Fri, 6 Mar 2020 09:14:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <158351489312.2248.1158552162214568165@ietfa.amsl.com> Date: Fri, 06 Mar 2020 09:14:53 -0800 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-09.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 17:14:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-09.txt Pages : 73 Date : 2020-03-06 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-09 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 12:26:40 2020 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 8CA2B3A09C7 for ; Fri, 6 Mar 2020 12:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 GBurfCPcdZJ1 for ; Fri, 6 Mar 2020 12:26:32 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 85AC63A09C6 for ; Fri, 6 Mar 2020 12:26:32 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id bt20so1210289qvb.11 for ; Fri, 06 Mar 2020 12:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=GrybI10zKT7CmQZbm9XKNJ5ePpi9cHK5H5QsKJ5FUHY=; b=bQpKGn/wmURcKyeT5/MSfXxM6i4D7+ONvwL4Lit9ob1S8c2ZuNmD5+6mhS9O30b6hp 7nJRl7fpjKJrdZopSbKfCKEjLasvEdYirXhy0BFStFpG0oPpcE0tKZVdxMr/FI8aReZM crM9Tgf/3MERwU0LQZrLhc0GaEpm4BtMPUSV0= 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=GrybI10zKT7CmQZbm9XKNJ5ePpi9cHK5H5QsKJ5FUHY=; b=iw8i2bpnQY4YKCGLYi2cNtWOYWPZwnkpwJH68LE3Bdow23/l7sjyG06sJ1mvIbcAIT 9elsL3jKfo6vuO0LBnrhfm8cf36CnTweG/CBzwKk/+w2OiXRx4Tu+h5cvIRBCWf2VW/x pMLdC0cNO6yxrn0DXP6MpvREiCmWdDkxhDxBEjcoBpPx+4Zvnly7hDho3QZlu/0MWFMg Rue2aD6BPLPQw7rIAmr4wZrgODr0CBXdfloimoXaaakbyJUatCa/eVqE05fLUmkdcb58 B93sQpc/HfmIBlchlQAW7EnULwJNK6uC+JCXhmJ5+RkDzgkQr+rXP1+MSEP/HGjh+2Rm KgXA== X-Gm-Message-State: ANhLgQ1WyXtAJ4qezgd721WtztyMmeWH2bVnXOy85ZXMpuXJ5vjHqB7g 2w526xdY3eUGA8+J2iEdKFPWK1d+LtA8mOBWkf1Llq+iyNuing== X-Google-Smtp-Source: ADFU+vvXCiVTbLrCcvmNbcNEvdJjOImOo5mQfRTQVUskqdBbOBupoSDIKNwc3iKW+LlpT8UrWWizI7+KDNlftNGF/iA= X-Received: by 2002:a0c:f684:: with SMTP id p4mr4488283qvn.172.1583526390998; Fri, 06 Mar 2020 12:26:30 -0800 (PST) MIME-Version: 1.0 From: Brendan McMillion Date: Fri, 6 Mar 2020 12:26:20 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000007505f05a03578bd" Archived-At: Subject: [MLS] Mandating the expiration of KeyPackages (redux) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 20:26:40 -0000 --00000000000007505f05a03578bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello mls@ In PR #275 , we started mandating the expiration of KeyPackages. However, the PR also allows applications to set the expiration of the KeyPackage to the maximum value for Last Resort keys -- meaning they never expire. I think this is conflating the problem that Last Resort keys solve with something else. Last Resort keys are a solution to DoS attacks, where somebody sends a user a lot of messages in a short period of time, to exhaust their cache of one-time-only keys and prevent anyone else from sending messages to the user. Last Resort keys are not a solution to the problem of the user being offline for an indefinite period of time. Trying to use Last Resort keys in this way can pose a problem for PCS, because if a user is compromised then any of these KPs can be used to =E2=80=9Cadd=E2= =80=9D the user to the group, when they=E2=80=99re actually adding an adversary. It=E2=80=99s tempting to say that the PCS issue is solved by rotating the u= ser=E2=80=99s identity key, as this invalidates all the previous KeyPackages that were never going to expire. However, this implies that the user=E2=80=99s identi= ty key needs to be rotated as often as new KeyPackages would ideally be generated, which could create a substantial burden on the Authentication Service. Practically, I think it=E2=80=99s unlikely that identity keys will really b= e rotated this often, or that reliable revocation will be implemented by many operators. And finally, the rotation requirement is incompatible with the multitude of signature schemes that don=E2=80=99t require a new credential = to be issued to achieve PCS. The improvement I proposed in the PR was to remove this guidance, along with modifying the Expiration extension to be a (notBefore, notAfter) pair. Having start and end dates allows everyone to see the total lifetime of a KeyPackage, and enforce that the total lifetime is below some application-defined limit. I=E2=80=99ve opened PR #317 with my suggested changes. Feedback welcome! --00000000000007505f05a03578bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello mls@


In PR #275, we started mandatin= g the expiration of KeyPackages. However, the PR also allows applications t= o set the expiration of the KeyPackage to the maximum value for Last Resort= keys -- meaning they never expire.


I think this is conflating the prob= lem that Last Resort keys solve with something else. Last Resort keys are a= solution to DoS attacks, where somebody sends a user a lot of messages in = a short period of time, to exhaust their cache of one-time-only keys and pr= event anyone else from sending messages to the user. Last Resort keys are <= /span>not<= /span> a s= olution to the problem of the user being offline for an indefinite period o= f time. Trying to use Last Resort keys in this way can pose a problem for P= CS, because if a user is compromised then any of these KPs can be used to = =E2=80=9Cadd=E2=80=9D the user to the group, when they=E2=80=99re actually = adding an adversary.


It=E2=80=99s tempting to say that the PCS issue is= solved by rotating the user=E2=80=99s identity key, as this invalidates al= l the previous KeyPackages that were never going to expire. However, this i= mplies that the user=E2=80=99s identity key needs to be rotated as often as= new KeyPackages would ideally be generated, which could create a substanti= al burden on the Authentication Service. Practically, I think it=E2=80=99s = unlikely that identity keys will really be rotated this often, or that reli= able revocation will be implemented by many operators. And finally, the rot= ation requirement is incompatible with the multitude of signature schemes t= hat don=E2=80=99t require a new credential to be issued to achieve PCS.


The improvement I proposed in the PR was to remove this guidance, along wi= th modifying the Expiration extension to be a (notBefore, notAfter) pair. H= aving start and end dates allows everyone to see the total lifetime of a Ke= yPackage, and enforce that the total lifetime is below some application-def= ined limit.


I=E2=80=99ve opened PR #317= with my s= uggested changes. Feedback welcome!
--00000000000007505f05a03578bd-- From nobody Sat Mar 7 16:16:46 2020 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 2F00E3A0EE4 for ; Sat, 7 Mar 2020 01:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 XbiAbe_iNgV7 for ; Sat, 7 Mar 2020 01:50:21 -0800 (PST) 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 EEA733A0EE2 for ; Sat, 7 Mar 2020 01:50:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,525,1574118000"; d="scan'208,217";a="341586730" Received: from 91-165-78-144.subs.proxad.net (HELO [192.168.0.1]) ([91.165.78.144]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2020 10:50:18 +0100 From: Benjamin Beurdouche Message-Id: <12FD4B1E-5673-407A-8AA8-B9D760DA94C5@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_95B60B80-971E-4076-B73C-6EB0DF16AACC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 7 Mar 2020 10:50:18 +0100 In-Reply-To: Cc: ML Messaging Layer Security To: Brendan McMillion References: X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] Mandating the expiration of KeyPackages (redux) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 09:50:23 -0000 X-List-Received-Date: Sat, 07 Mar 2020 09:50:23 -0000 --Apple-Mail=_95B60B80-971E-4076-B73C-6EB0DF16AACC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Mar 2020, at 21:26, Brendan McMillion = wrote: >=20 > Hello mls@ >=20 > In PR #275 , we = started mandating the expiration of KeyPackages. However, the PR also = allows applications to set the expiration of the KeyPackage to the = maximum value for Last Resort keys -- meaning they never expire. Well, the previous situation was that there was literally no expiration = field. > I think this is conflating the problem that Last Resort keys solve = with something else. Last Resort keys are a solution to DoS attacks, = where somebody sends a user a lot of messages in a short period of time, = to exhaust their cache of one-time-only keys and prevent anyone else = from sending messages to the user. Last Resort keys are not a solution = to the problem of the user being offline for an indefinite period of = time. Trying to use Last Resort keys in this way can pose a problem for = PCS, because if a user is compromised then any of these KPs can be used = to =E2=80=9Cadd=E2=80=9D the user to the group, when they=E2=80=99re = actually adding an adversary. No... even if you were in my brain when I wrote it, I can assure you, it = was not=E2=80=A6 : ) The goal was to achieve the first step of moving from no expiration to = some expiration, which was striking a balance when some of the editors were at a = disagreement. > It=E2=80=99s tempting to say that the PCS issue is solved by rotating = the user=E2=80=99s identity key, as this invalidates all the previous = KeyPackages that were never going to expire. However, this implies that = the user=E2=80=99s identity key needs to be rotated as often as new = KeyPackages would ideally be generated, which could create a substantial = burden on the Authentication Service. Practically, I think it=E2=80=99s = unlikely that identity keys will really be rotated this often, or that = reliable revocation will be implemented by many operators. And finally, = the rotation requirement is incompatible with the multitude of signature = schemes that don=E2=80=99t require a new credential to be issued to = achieve PCS. >=20 > The improvement I proposed in the PR was to remove this guidance, = along with modifying the Expiration extension to be a (notBefore, = notAfter) pair. Having start and end dates allows everyone to see the = total lifetime of a KeyPackage, and enforce that the total lifetime is = below some application-defined limit. I think the design goals should be: 1. Allow and encourage agressive InitKey rotation 2. Don=E2=80=99t have a difference between InitKeys in terms of = structure (last resort or not) 3. Don=E2=80=99t break existing products Both 1. 2. and 3. are already possible in the current design, so the = difference I see are the editorial and the =E2=80=9CnotBefore=E2=80=9D field which = I see as a new feature, and I like it. The PR doesn=E2=80=99t conflict with expiration of InitKeys on signature = key rotation either, so I think it is pretty good. I agree with it and support this PR. B. --Apple-Mail=_95B60B80-971E-4076-B73C-6EB0DF16AACC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6 Mar 2020, at 21:26, Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> = wrote:

Hello mls@

In PR #275, we started mandating the expiration of KeyPackages. = However, the PR also allows applications to set the expiration of the = KeyPackage to the maximum value for Last Resort keys -- meaning they = never expire.

Well, the previous situation was that there was = literally no expiration field.

I think this is conflating the problem that Last Resort keys = solve with something else. Last Resort keys are a solution to DoS = attacks, where somebody sends a user a lot of messages in a short period = of time, to exhaust their cache of one-time-only keys and prevent anyone = else from sending messages to the user. Last Resort keys are = not a solution to the problem of the user being offline for an = indefinite period of time. Trying to use Last Resort keys in this way = can pose a problem for PCS, because if a user is compromised then any of = these KPs can be used to =E2=80=9Cadd=E2=80=9D the user to the group, = when they=E2=80=99re actually adding an = adversary.

No... even if you were in my brain when I wrote = it, I can assure you, it was not=E2=80=A6 : )
The goal was to = achieve the first step of moving from no expiration to some = expiration,
which was striking a balance when some of the = editors were at a disagreement.

It=E2=80=99s tempting to say that the PCS issue is solved by = rotating the user=E2=80=99s identity key, as this invalidates all the = previous KeyPackages that were never going to expire. However, this = implies that the user=E2=80=99s identity key needs to be rotated as = often as new KeyPackages would ideally be generated, which could create = a substantial burden on the Authentication Service. Practically, I think = it=E2=80=99s unlikely that identity keys will really be rotated this = often, or that reliable revocation will be implemented by many = operators. And finally, the rotation requirement is incompatible with = the multitude of signature schemes that don=E2=80=99t require a new = credential to be issued to achieve PCS.

The improvement I proposed in the PR was to remove this = guidance, along with modifying the Expiration extension to be a = (notBefore, notAfter) pair. Having start and end dates allows everyone = to see the total lifetime of a KeyPackage, and enforce that the total = lifetime is below some application-defined = limit.

I think the design goals should = be:
1. Allow and encourage agressive InitKey = rotation
2. Don=E2=80=99t have a difference between InitKeys = in terms of structure (last resort or not)
3. Don=E2=80=99= t break existing products

Both 1. 2. and 3. are already possible in the = current design, so the difference
I see are the = editorial and the =E2=80=9CnotBefore=E2=80=9D field which I see as a new = feature, and I like it.
The PR doesn=E2=80=99t = conflict with expiration of InitKeys on signature key rotation = either,
so I think it is pretty good.

I agree with it and = support this PR.
B.

= --Apple-Mail=_95B60B80-971E-4076-B73C-6EB0DF16AACC-- From nobody Sat Mar 7 23:41:25 2020 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 8F3A73A0869 for ; Sat, 7 Mar 2020 23:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZEr/ph+B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q+mbYaDC 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 yPxgyswh20oU for ; Sat, 7 Mar 2020 23:41:17 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6093A0867 for ; Sat, 7 Mar 2020 23:41:17 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 347CA21BA9 for ; Sun, 8 Mar 2020 03:32:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 08 Mar 2020 03:32:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=0qLYy2WuQidAq1zCXR+wcJEHOGG6kbKKEv/FzQ7lPkk=; b=ZEr/ph+B ZpGLpSuAun1xqtWKEkXPyuJ5tXRMcMXGeBTV3ivONtI+SK3vJV/S/oci4uDZ1Nc1 tel7u2idB8sL9Q8drY6Sro9FjHP6wy+ZdQcgLJ5U1uHW5NJQ81MIpj78q43LZSoM x7kf7+I9hpUHyJn8ZUrxD7FnMcFAaIoa2C5u0S3PYGaGu80ElS6VayU9U7y6imDf MptOyvAwmwdvbgcTmw/Xwa48m1jUpLK5LOQANoiFLBxhIKZM+DxwgzhE5VgFi7vL cKx1NK8Zxttpq9Pk7uNQ6DL+LOjrcSmQMpJ5k0qmT5W8HQQe/vuf4kCJnGjiifP3 aBtb+d4ocf/UgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=0qLYy2WuQidAq1zCXR+wcJEHOGG6k bKKEv/FzQ7lPkk=; b=q+mbYaDCTQyC5IHWC4gZhoP8H9Ehd6yl92oB63RroXHVE TZEYbaclst1x0wcskJ9Bttgpb72zK/ybXZVCHigBfhxXiXog4XnSSB7ib/2IhZ4a 96c3ZAnAq3ytiF3SlHqatRZww/WcoKxyfebSnpv6YpVuW2noLoXLro7xXB0iudoZ 2H/5m/XQUkWkTj8AWZBXupIR5TlwYqnbI30UJ1PfBt9FCSnTTMoNWbC2kviOeues 9c07kCG5CLSZfc9LwSAEGtCV1b3+EbYNTUCSS6/n/k22snlP7FUr9QqTvVTcBIyn X6ZE3IY9LeAYRY7XhHmit0zUJhmxWykdr0o5yxY4A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduhedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeegtddruddugedrvdekrddvtdejnecuvehluhhs thgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvg hplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.114.28.207]) by mail.messagingengine.com (Postfix) with ESMTPA id F048B3280059 for ; Sun, 8 Mar 2020 03:32:48 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0852348457093287792==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200308073248.F048B3280059@mailuser.nyi.internal> Date: Sun, 8 Mar 2020 03:32:48 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 07:41:20 -0000 --===============0852348457093287792== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 issues created: - Add IANA considerations for Extensions (by bifurcation) https://github.com/mlswg/mls-protocol/issues/312=20 Pull requests ------------- * mlswg/mls-protocol (+7/-13/=F0=9F=92=AC9) 7 pull requests submitted: - Change expiration extension to lifetime extension. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/317=20 - Update changelog for KeyPackage (by bifurcation) https://github.com/mlswg/mls-protocol/pull/316=20 - ClientInitKey -> KeyPackage (by bifurcation) https://github.com/mlswg/mls-protocol/pull/315=20 - Fix build and update changelog (by bifurcation) https://github.com/mlswg/mls-protocol/pull/314=20 - Clarify signature algorithm requirements (by bifurcation) https://github.com/mlswg/mls-protocol/pull/313=20 - Review of section 7. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/311=20 - Fix identation and remove some vestigial stuff from the key schedule. (= by Bren2010) https://github.com/mlswg/mls-protocol/pull/310=20 3 pull requests received 9 new comments: - #308 Remove nonce from SenderData AAD. (6 by Bren2010, beurdouche, bifu= rcation, britXta) https://github.com/mlswg/mls-protocol/pull/308=20 - #296 Flesh out the extensions story (2 by Bren2010, bifurcation) https://github.com/mlswg/mls-protocol/pull/296=20 - #274 Fix contexts and simplify key schedule (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/274 [? follow-up] [enhanceme= nt] [security] [work in progress]=20 13 pull requests merged: - Update changelog for KeyPackage https://github.com/mlswg/mls-protocol/pull/316=20 - ClientInitKey -> KeyPackage https://github.com/mlswg/mls-protocol/pull/315=20 - Fix build and update changelog https://github.com/mlswg/mls-protocol/pull/314=20 - Clarify signature algorithm requirements https://github.com/mlswg/mls-protocol/pull/313=20 - Use HKDF to derive key pairs https://github.com/mlswg/mls-protocol/pull/304 [ready to merge]=20 - Bring back more ciphersuites https://github.com/mlswg/mls-protocol/pull/279 [enhancement] [ready to = merge]=20 - DE-related text https://github.com/mlswg/mls-protocol/pull/307 [editorial]=20 - Flesh out the extensions story https://github.com/mlswg/mls-protocol/pull/296 [editorial] [functionali= ty] [security]=20 - Review of section 7. https://github.com/mlswg/mls-protocol/pull/311 [editorial]=20 - Mandate expiration of ClientInitKeys and presence of some extensions https://github.com/mlswg/mls-protocol/pull/275 [enhancement] [ready to = merge] [security]=20 - Update MLSPlaintextTBS struct to match MLSPlaintext. https://github.com/mlswg/mls-protocol/pull/309=20 - Use the same ratchet for Handshake and Application keys https://github.com/mlswg/mls-protocol/pull/283 [discussion] [privacy] [= ready to merge] [security]=20 - Fix identation and remove some vestigial stuff from the key schedule. https://github.com/mlswg/mls-protocol/pull/310 [editorial]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============0852348457093287792== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday March 08, 2020

Issues

mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0)

1 issues created:

Pull requests

mlswg/mls-protocol (+7/-13/=F0=9F=92=AC9)

7 pull requests submitted:

3 pull requests received 9 new comments:

13 pull requests merged:

Repositories tracked by this digest:

--===============0852348457093287792==-- From nobody Tue Mar 10 14:11:56 2020 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 173B53A0DFC for ; Tue, 10 Mar 2020 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 jiWE-iV12vBb for ; Tue, 10 Mar 2020 14:11:36 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 0176A3A0E05 for ; Tue, 10 Mar 2020 14:11:35 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id 59so48355qtb.1 for ; Tue, 10 Mar 2020 14:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:reply-to:mime-version:subject:date:references:to:message-id; bh=uxZqrlMYtulqXv8vHiJQ55zsPkbwz+FN+Esbs+M3Xm0=; b=j+ndbS6cHWL9I9rg6nSGEIL3xxpZEVgzkXWtAHW8ppIqjbBScqHQi+YLrrY2He6QoU x4jDza7XS9UOrL8FGuOqWWqlbBtX3G7K7mOyiOc0OCnz4u7ui6+vgE5jLzrkYb/Bzo4D SSD01KR4ZP+CrISBOcuXTmFt8BM/I6+ATGVSg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:date :references:to:message-id; bh=uxZqrlMYtulqXv8vHiJQ55zsPkbwz+FN+Esbs+M3Xm0=; b=cG14jVBD2Z53xIEVOOwxnPnDibFsEEPddHt5idMJ5sUzxtZv351b92mNH22XiwCEOp X2DpTfGqPMPyQ2jrbZgetICXSc5lXANqg8pMfXtSX6TUWtRcy/y1WGpyiTYaTUvdySpO va2bihMMXbKX0soYLpdqZWvDEQpDozgUndtS9J6dw353W6/HsGowXZdF7Gi+Dqb3T/sO UOOd0m3QwrhsPwk2/lXAxzRJgb5t10wKyNYQ3gXBUKfPMrSwpQpvnqIkhA//X5nLjEVb 9XV37cOZ9Ku9dNkjEc/Suie3zdxgbcUt1WqXwtFxHlMttsb/JErZCxB/VjQHw+92mP47 dmIg== X-Gm-Message-State: ANhLgQ1dNLq4HkrUvTN5wkCsTY1G5cb1H5yAQeakfbmuKiPW2RvAGaE0 JWgGH02OWrY/Emw0yPYibRjaBx4hIEM= X-Google-Smtp-Source: ADFU+vsw4hP415CU6vhQswyXKB4P5NVCmzC0VisprSqG1n1uyTe8/DGaW1q33RE2+CM6svj/4Y77yA== X-Received: by 2002:ac8:4906:: with SMTP id e6mr18632698qtq.178.1583874694371; Tue, 10 Mar 2020 14:11:34 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id v1sm6326977qkd.74.2020.03.10.14.11.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 14:11:33 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_62B96A58-B333-465A-8BE0-6CF5017BF34F" Reply-To: ietf Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 10 Mar 2020 17:11:33 -0400 References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> To: MLS List Message-Id: <84BBD737-8762-4C82-BC20-66220172A458@sn3rd.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [MLS] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:11:49 -0000 --Apple-Mail=_62B96A58-B333-465A-8BE0-6CF5017BF34F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those of you not on the ietf@ietf.org mailing = list and that planning to attend in-person, this is of interest. I will = also forward the ED follow up message about registration cancellations = and refunds. spt > Begin forwarded message: >=20 > From: The IESG > Subject: IETF 107 Vancouver In-Person Meeting Cancelled > Date: March 10, 2020 at 3:10:27 PM EDT > To: "IETF Announcement List" > Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org > Reply-To: iesg@ietf.org >=20 > The IESG and the IRTF Chair have decided to cancel the in-person IETF = 107 Vancouver meeting. This decision is based on input we gathered from = Working Group (WG) and Research Group (RG) chairs about our ability to = hold productive WG and RG sessions at IETF 107. Our assessment of this = feedback is that a majority of sessions would not be viable if we were = to hold the in-person IETF meeting. On this basis, we believe we cannot = hold an effective in-person meeting.=20 >=20 > As a result of this cancellation, the in-person Hackathon, Code = Sprint, all other in-person events planned for the weekend of March = 21-22, the chairs training scheduled for March 20, and all other = in-person sessions during the week are cancelled. >=20 > The IESG is working on an alternative all-virtual agenda for the week = of March 21-27 with a limited schedule adapted to accommodate the time = zones of as many participants as possible. We are also planning to = support an increased volume of virtual interim meetings during the weeks = that follow. We will send another update to the community soon with more = information about these plans. The Hackathon organizers are also = considering plans for virtual Hackathon support. >=20 > We have re-opened Internet-Draft submissions, which had been closed on = March 9 in anticipation of the in-person meeting. Internet-Drafts may be = submitted at . >=20 > A separate announcement from the IETF Executive Director will follow = with details about registration cancellations and refunds. =20 >=20 > These are unusual times given the circumstances created by the spread = of COVID-19. We hope that everyone remains safe and healthy. >=20 > Regards, > The IESG and the IRTF Chair >=20 --Apple-Mail=_62B96A58-B333-465A-8BE0-6CF5017BF34F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii For = those of you not on the ietf@ietf.org mailing list and that planning to = attend in-person, this is of interest.  I will also forward the ED = follow up message about registration cancellations and refunds.

spt

Begin = forwarded message:

From: = The IESG <iesg@ietf.org>
Subject: = IETF 107 = Vancouver In-Person Meeting Cancelled
Date: = March 10, 2020 at 3:10:27 PM = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org
Reply-To: = iesg@ietf.org

The IESG and the IRTF Chair = have decided to cancel the in-person IETF 107 Vancouver meeting. This = decision is based on input we gathered from Working Group (WG) and = Research Group (RG) chairs about our ability to hold productive WG and = RG sessions at IETF 107. Our assessment of this feedback is that a = majority of sessions would not be viable if we were to hold the = in-person IETF meeting. On this basis, we believe we cannot hold an = effective in-person meeting.

As a result = of this cancellation, the in-person Hackathon, Code Sprint, all other = in-person events planned for the weekend of March 21-22, the chairs = training scheduled for March 20, and all other in-person sessions during = the week are cancelled.

The IESG is working = on an alternative all-virtual agenda for the week of March 21-27 with a = limited schedule adapted to accommodate the time zones of as many = participants as possible. We are also planning to support an increased = volume of virtual interim meetings during the weeks that follow. We will = send another update to the community soon with more information about = these plans. The Hackathon organizers are also considering plans for = virtual Hackathon support.

We have = re-opened Internet-Draft submissions, which had been closed on March 9 = in anticipation of the in-person meeting. Internet-Drafts may be = submitted at <https://datatracker.ietf.org/submit/>.
A separate announcement from the IETF Executive Director = will follow with details about registration cancellations and refunds. =  

These are unusual times given the = circumstances created by the spread of COVID-19.  We hope that = everyone remains safe and healthy.

Regards,
The IESG and the IRTF Chair


= --Apple-Mail=_62B96A58-B333-465A-8BE0-6CF5017BF34F-- From nobody Sun Mar 15 00:41:09 2020 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 58C463A115C for ; Sun, 15 Mar 2020 00:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=HCTGbG8Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cpRXW6Az 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 x7ctgEltc4hI for ; Sun, 15 Mar 2020 00:41:06 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FEB3A1145 for ; Sun, 15 Mar 2020 00:41:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 544ED458 for ; Sun, 15 Mar 2020 03:32:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 15 Mar 2020 03:32:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=vWfhN8ZFJLc6w1QegDh1rGpbdS65ZVyPrF/i2WbT6pg=; b=HCTGbG8Q 91K5sd7OoTytP9wLlnzfedU8lOAUxXM7SlNBWjiLGDG6YYwqU2bojNt+Kf+yxlzF +nd31XUrbl+EbZkpv8g2WT9zcb0y3OmQonzXGzqH8Hj3GJyyfzWXUGFR+R72292Y e1jvy72eMFlLPcHSaWrf1AA7ds9Sye97SzkuQbP8/jb4NaAxFYCdFBfgnGy0uvj3 bQ9i9eXuj9ZjVHKxNMkltXgjetcBQC5ywMq1hGfj4kgwvH8JirJofv3edcED5/Dq 3ZZF7qGWws1xJZb/iv4Dh+GfAPu60xamX0a1Gs9NXcwtvL+1CiSbGTcxh8xadLrf G29HZg7dXHDJ6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=vWfhN8ZFJLc6w1QegDh1rGpbdS65Z VyPrF/i2WbT6pg=; b=cpRXW6AzefYC2tDh8bWJ2RjQEudRhi/haqSpGQk5N2FYv n2PwyPd8SA0XFu6tkYnbyDi3m4IXzfyr0mljVG5zp6I8Gck78AKNI9YNRKfgIAVZ 1/x3CWJiCFhCdip3+v9xJAm0xa6U7eQOAh2HwDRW2Tqa1WWY3YPuwhi4fEUCE1ev Bpw0tDCd19oHUD14onBikVATvto2PXEy4PbzcxOW3hM20dhgLCKkL+fIQu+L7/lK bMspmlioxF5zah60EcPzUkaCBMTKbiByl2fiwK75//cVuZl7rmBDKrSvYpfxHaAv P8kG3ygifhw8TDvUcQUsOHtO7nWPhtscaegGHtc7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeftddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeegtddrjeelrddvvddrvdeggeenucevlhhushht vghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.79.22.244]) by mail.messagingengine.com (Postfix) with ESMTPA id BD4C5328005A for ; Sun, 15 Mar 2020 03:32:30 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5165084658263156422==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200315073230.BD4C5328005A@mailuser.nyi.internal> Date: Sun, 15 Mar 2020 03:32:30 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 07:41:09 -0000 --===============5165084658263156422== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+3/-0/=F0=9F=92=AC0) 3 pull requests submitted: - Use node type instead of leaf index in tree hashes. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/320=20 - Use correct type for uint32. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/319=20 - Fix markdown formatting issue for Ciphersuite section (by arianvp) https://github.com/mlswg/mls-protocol/pull/318=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============5165084658263156422== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday March 15, 2020

Pull requests

mlswg/mls-protocol (+3/-0/=F0=9F=92=AC0)

3 pull requests submitted:

Repositories tracked by this digest:

--===============5165084658263156422==-- From nobody Thu Mar 19 11:37:05 2020 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 D9EE33A0D05 for ; Thu, 19 Mar 2020 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=cloudflare.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 oUJCY0NfDXGz for ; Thu, 19 Mar 2020 11:37:02 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 540223A0D03 for ; Thu, 19 Mar 2020 11:37:02 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id m9so2373768vso.2 for ; Thu, 19 Mar 2020 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=XdP+bmmPqlBHUG/TAo5hDuADdJwdqIxKw1jZPcyfLl4=; b=YhI1w+IcKwtUTRN1RHun23WVrGWyEJD80NbiDeOPgMwMB9UY+X2+DhsExYFHRpVinJ 14M8rVDL0cRs5RK4HX8uzFC7jDVOkVOHU4/vlk7fjRVQOO6FzFqWAMaLvkUWtPtJTg9P 7x80t8/RArW+sx7h/bC4LH7Dqsc2ojEuhcat0= 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=XdP+bmmPqlBHUG/TAo5hDuADdJwdqIxKw1jZPcyfLl4=; b=eeotCSlhvVEAIytjyLLioQsuNnDtZ9fPRdR5uJGGviob7MX6jC/1qyfq0Zov9Njd+5 76ofNWL4XHteP7JxmP7VlPOx0untzvy/0hoJpJknJox2m43sbDSTjYiTZjjpVTZBEJQe 7+XGEzaKrp5b054FuulrHVHlAVV617fEkIghRaCW2RZe9fAyJv5OGwyJc6vWfhB2ScfV lLuOkkkTiAokjOvRL2TyGjDBd7AdW8xEfjPT/u2TxpTyZCqffVwj20SWdTmT3/YwoSuq VTMAhrcaEkPJvCxhqL9u1GHIPOAql2M16evzIfegZCk6ZmWCvaz3M3fHDGjVkN0IxPzk cp8w== X-Gm-Message-State: ANhLgQ2RT8jVXubkthLz4K8mVRDursSr8Fwse+bdTj/X3do7rzrWRjWa MJtkE+1tDbifclU1tJANjBC0YW7Huttfo0WOHkWw7W+tKjT9Hw== X-Google-Smtp-Source: ADFU+vsJHwrODEIf9cAeyEaVUa2YEzJ7qTLcaLQGdTXWc2TQhOHoGudzoEIIDDzDXc79Y//V7wlrT7HuNOpr8paSzYs= X-Received: by 2002:a67:cd8e:: with SMTP id r14mr3325076vsl.172.1584643020811; Thu, 19 Mar 2020 11:37:00 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Thu, 19 Mar 2020 11:34:45 -0700 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005a175f05a13974a1" Archived-At: Subject: [MLS] Planning: IETF 107 Virtual Meeting X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:37:04 -0000 --0000000000005a175f05a13974a1 Content-Type: text/plain; charset="UTF-8" Hello MLSWG members, Since the IETF 107 is no longer happening in person, it may be useful to have a virtual meeting for MLS instead. There are a number of PRs and ideas to discuss. Please fill out the following poll to help us determine interest: https://docs.google.com/forms/d/e/1FAIpQLSdGgMT16UcwL21KWbO_RFwqkozuDkBRV-FJh-VmVF_C204H8g/viewform?usp=sf_link Nick & Sean --0000000000005a175f05a13974a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello MLSWG=C2=A0members,

Si= nce the IETF 107 is no longer happening in person, it may be useful to have= a virtual meeting for MLS instead. There are a number of PRs and ideas to = discuss.

Please fill out the following poll to hel= p us determine interest:
https://docs.google.com/forms/d/e/1FAIpQLSdGgMT16UcwL21KWbO_RFwqkozuD= kBRV-FJh-VmVF_C204H8g/viewform?usp=3Dsf_link

Nic= k & Sean
--0000000000005a175f05a13974a1-- From nobody Sun Mar 22 00:41:12 2020 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 DEB683A0F39 for ; Sun, 22 Mar 2020 00:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=eD97m/Re; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aZAOK3uL 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 LovptOEMk1B6 for ; Sun, 22 Mar 2020 00:41:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8D13A0F2E for ; Sun, 22 Mar 2020 00:41:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9284B5D3 for ; Sun, 22 Mar 2020 03:32:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 22 Mar 2020 03:32:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=V456f0X7CThZf7FxbQY2LP1Y3V+4GQI4LrgyKsHqxtM=; b=eD97m/Re 8Y30oJ9M1EfFWkFtCGxTxyiXNPRA+39UiG2tPCRX7fr7cNOlds6eXVzTv6b26kjT NoQvauj6jNx030oCa67l9j1P1L9VoHS3Ujm3WfPJMIpRJSWmOhXUO7O+3UpkIbWt NGtnJLmM8JaWPOk5iQzRvPJwCegFHW5mSuwCQCoSo+AgVIkfh8rmhwWL1cGO879F BARN3E0IvI7jmD8zoIHXrglBL6VGjAo/FA15G0+Rbu0AmlO8sTTWFHVP2fPfMnVl erJRB95BcqKRJk/er3y2NML6Q29e8t0EZaC7gXesIuLeWQa+FIWpr1l60/NxV+O2 yIfzQhERxPm7ew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=V456f0X7CThZf7FxbQY2LP1Y3V+4G QI4LrgyKsHqxtM=; b=aZAOK3uLbUs3mG4iC7Qdm4GEX93B0YpzPv3O3mIM3/tIa fzqIDJTLFrQ5t1BsQjDyyxvo2YpdumxvxvUBfRQnvFUQvkIIGxRcGilluQS2BvfM DaXnj1AnYjEpRVFjzPBUc89oQ4HLBSyNVvK90eOj/BBMfx9K3LCy1pz0pMXxU097 HI77sE/WNNBKkYqfoiXXykoqlkwMHGH3O5OWf5vnu5a6GBnud5YXSJWqll7574O1 +MGOTUrqf9602Tw9Wma6HliCmxIyBtgfCMwjQAcj9bYB4dO9OnCtQlWQC5RGDmWq 27UQ5knf1BwuMZOWvWkPOPZvgipT9+zJIgbSU1k9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeghedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepgedtrdejledrjedtrddvheenucevlhhushhtvghr ufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.79.70.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 1858830624E4 for ; Sun, 22 Mar 2020 03:32:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2660618115241744181==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200322073228.1858830624E4@mailuser.nyi.internal> Date: Sun, 22 Mar 2020 03:32:28 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 07:41:10 -0000 --===============2660618115241744181== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Extensions -> Extension (by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/321=20 1 pull requests merged: - Extensions -> Extension https://github.com/mlswg/mls-protocol/pull/321=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2660618115241744181== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday March 22, 2020

Pull requests

mlswg/mls-protocol (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============2660618115241744181==-- From nobody Wed Mar 25 06:18:02 2020 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 466D43A0484; Wed, 25 Mar 2020 06:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158514226722.31323.9038888831302164654@ietfa.amsl.com> Date: Wed, 25 Mar 2020 06:17:47 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2020-05-07 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 13:17:48 -0000 The Messaging Layer Security (mls) Working Group will hold a multi-day interim meeting. Session 1: 2020-05-07 09:00 to 17:00 Europe/Berlin(07:00 to 15:00 UTC) Session 2: 2020-05-08 09:00 to 17:00 Europe/Berlin(07:00 to 15:00 UTC) Meeting Location: Berlin, DE Agenda: https://github.com/mlswg/wg-materials/blob/master/interim-2020-05/agenda.md Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m0b5981050dd8f6e923fde6b5fb5835c1 From nobody Wed Mar 25 10:29:00 2020 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 EF3D33A0DF4 for ; Wed, 25 Mar 2020 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 KFd07OJIoS83 for ; Wed, 25 Mar 2020 10:28:51 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 95B493A0DE5 for ; Wed, 25 Mar 2020 10:28:51 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id z13so1483019qvw.3 for ; Wed, 25 Mar 2020 10:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Jre/LuUT17EMPUO7cS+T4glOszwtf+iqm04Gtcsak6c=; b=Eciu2yet8izcs9m0g5mw6lzZ7G+lEzFdruYWSc/iRXcsoV64eNyhQOrns04/naJwL2 nvCewPfa5xvLJzEqzHNCBs73WPbzEln59+6AT1quHLeaPShlbK8GCv3xhTL/TrMLYP/F cj1fnDZdcsVUw8mM+9HkoDcR2c2jVzNTI00+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Jre/LuUT17EMPUO7cS+T4glOszwtf+iqm04Gtcsak6c=; b=NmGBGtYSmZAmru0pq8JBZ87FL0WuQ0cFydOLZbS/Wvdm1caBHGIQaJCJssDi6YFqUO EceS4/KiMj8r8FWBbyvKf6GcCjhQIQ/988BwKbQrqmxeQxmfr2d7W5d9B/gDftahGljU vEf0ah18YLBYjOxSzsj5IN2X5fNfam6342FfUwTRIvlHaEKKbpk9VdHpDseIcuk4/Nh6 5OQFXPV4fKRjiVoEaLq9uxiNX3gbjigzEfeC+rNKj0u0vQqrEBpekRMxpvJNfxmgWGKH 6kPBbPKcDJFnWUbzG2VbaTX75RbVuLKbmdOoARsyn0d7HQts0X0auJcegbPOCfs22sfa dgzg== X-Gm-Message-State: ANhLgQ2YCoNcuwrCONyqQH4bkVyKrzRYW55s9Fm/rIGn1P/It5T08VTc pYz+PhLN41h89gvOIXZklKI/DtnxBfk= X-Google-Smtp-Source: ADFU+vuPz5tVBvU/M4kkHmhRVpFs/vSx2b0ydAZ39Sx08K1jihuSifi2Zw2nysTyl0CcuNh9dr7R5g== X-Received: by 2002:ad4:4202:: with SMTP id k2mr4321100qvp.25.1585157329937; Wed, 25 Mar 2020 10:28:49 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p9sm16484024qtu.3.2020.03.25.10.28.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 10:28:48 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 25 Mar 2020 13:28:48 -0400 References: <158514226722.31323.9038888831302164654@ietfa.amsl.com> To: MLS List In-Reply-To: <158514226722.31323.9038888831302164654@ietfa.amsl.com> Message-Id: <08928F36-207C-4F89-B698-53256FFD182E@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2020-05-07 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 17:28:58 -0000 Please note we submitted this before COVID-19 really took off. We will = need to revisit whether we actually meet in-person. spt > On Mar 25, 2020, at 9:17 AM, IESG Secretary = wrote: >=20 > The Messaging Layer Security (mls) Working Group will hold > a multi-day interim meeting. >=20 > Session 1: > 2020-05-07 09:00 to 17:00 Europe/Berlin(07:00 to 15:00 UTC) > Session 2: > 2020-05-08 09:00 to 17:00 Europe/Berlin(07:00 to 15:00 UTC) >=20 > Meeting Location: > Berlin, DE >=20 > Agenda: > = https://github.com/mlswg/wg-materials/blob/master/interim-2020-05/agenda.m= d >=20 > Information about remote participation: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm0b5981050dd8f6e923fde6b5fb5835c1= >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Sun Mar 29 00:38:17 2020 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 AE6343A13DC for ; Sun, 29 Mar 2020 00:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=zJbGwZYS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yjNJjV+r 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 DvPPheWZFpcY for ; Sun, 29 Mar 2020 00:38:13 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AF93A13D8 for ; Sun, 29 Mar 2020 00:38:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AA3415C0186 for ; Sun, 29 Mar 2020 03:32:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 29 Mar 2020 03:32:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=HBOyOpl8e4YxvDmFPDUnrRXBJBZ2rXnF74SdTuBDEj0=; b=zJbGwZYS EB7ef/KMlspZSYgMUHV/VIHcJE0B/pr05Am+BogyAysjxymHTf1JAyrBq6uIVTF+ tEbXZdk+4utfi8FFw/FbwVwGOWJYmWZWaqaoh9QP7zBDWz59Y7D3XIwQPLxzX6HO FOw7wq0ITvMlr4cegeUgLzlW0m7fiS06SNkkz79HNODmuItucpvyc0xtagi78AhG cNehMHXRNKTSpdBSqtK+3Xg616Nb4bsyzrzUQ3CBXoQs3Yv9h6veiSr8te4vyrH9 6pfJDEjt8pWl7/wZQzUGXaWs97OmrvxorcXqFiVZwdSy3xSJaz60LEfMs2ZcoZwR x2foymKUP3JSaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=HBOyOpl8e4YxvDmFPDUnrRXBJBZ2r XnF74SdTuBDEj0=; b=yjNJjV+rbthy5G9pgZ/QDOYCj6MU6DDHqbSclrF4vFekc FUbKSrPy8crvqOpfX66tmrXIfSfQXlaOg9gF1wq9JHv1aVWhzEgwo3XOO2OGZtRn 4XW4XcFSlLrUUCew3OlzggACW2xc/Q39LD2KQOzHBRBc8zfkumLemrMGyQ4vPFu+ fLFkTQCDrhJoQEIA/Kwv8wbNc0Ossj7m+rtmyPdt7/3KdMmNPVRAOAucBwLii4He GCVlrZJ1ZGKuZBgwG8EDhQAP/oG+UR1k8PVnFRzf54+7jIxICEW/ZZ3fPjSM/1Rz gr4iGgg/U3jPQVoVS7BAVPTgsnTG3i+1i7EQyKNuw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeivddguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeegtddrkedtrddugeehrdehnecuvehluhhsthgv rhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.80.145.5]) by mail.messagingengine.com (Postfix) with ESMTPA id 73B8E306C7D9 for ; Sun, 29 Mar 2020 03:32:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6747076606415197673==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200329073231.73B8E306C7D9@mailuser.nyi.internal> Date: Sun, 29 Mar 2020 03:32:31 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 07:38:15 -0000 --===============6747076606415197673== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+4/-0/=F0=9F=92=AC6) 4 issues created: - Authenticate that added members know the PSK (by bifurcation) https://github.com/mlswg/mls-protocol/issues/326=20 - Simplify epoch secret derivation? (by bifurcation) https://github.com/mlswg/mls-protocol/issues/325 [question]=20 - Use consistent arguments to Derive-Secret (by bifurcation) https://github.com/mlswg/mls-protocol/issues/324=20 - Fix context for new-member-initiated Add (by bifurcation) https://github.com/mlswg/mls-protocol/issues/323=20 3 issues received 6 new comments: - #326 Authenticate that added members know the PSK (2 by beurdouche, bif= urcation) https://github.com/mlswg/mls-protocol/issues/326=20 - #325 Simplify epoch secret derivation? (3 by Bren2010, beurdouche, raph= aelrobert) https://github.com/mlswg/mls-protocol/issues/325 [question]=20 - #323 Fix context for new-member-initiated Add (1 by Bren2010) https://github.com/mlswg/mls-protocol/issues/323 [bug]=20 Pull requests ------------- * mlswg/mls-protocol (+2/-1/=F0=9F=92=AC0) 2 pull requests submitted: - Fix bugs in tree math and cleanup docs. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/327=20 - Minor fix (by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/322=20 1 pull requests merged: - Minor fix https://github.com/mlswg/mls-protocol/pull/322=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6747076606415197673== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday March 29, 2020

Issues

mlswg/mls-protocol (+4/-0/=F0=9F=92=AC6)

4 issues created:

3 issues received 6 new comments:

Pull requests

mlswg/mls-protocol (+2/-1/=F0=9F=92=AC0)

2 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============6747076606415197673==--