From nobody Tue Jun 4 23:01:01 2019 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 2F7FB1200D7 for ; Tue, 4 Jun 2019 23:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_96_Q=1.508, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2Jw0rFeaGZX for ; Tue, 4 Jun 2019 23:00:59 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 D5F6312003E for ; Tue, 4 Jun 2019 23:00:58 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id m3so1786848itl.1 for ; Tue, 04 Jun 2019 23:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nxMOPHUYFPydZI4vvEFc2xEYFvBshqvSovbvl84mc9A=; b=VpmgkzyLG/bxkZGkdW5gfCp/0ex5dRAq2NhkZvOnZ3Zyi50ucAf0zbi8UrpBBuPa7W 6YH2ya0wnK06pMcYebdDdslqozCTMnh9aO5LMeD0hF5TqQG+Qv4i0P/XTERpB0pkObWG Sg9SEoI8Mal1j9UfNrf7oeb/pr1L9e2aty5ASyErRc7RMuKkUlUZLFxuSYL4x4QxLiiC PnEvIiWKoWgZs8bmEY7S+WwBOduGAWqGbt1mpqhw8evyQN8QX/B5U4UoLxDFy1+t4SKv duQfspEBIC52Zn8rvqbDfkqoWlPUTysA4EAZ9j3RP2IEshWCa3iv5Yl/Yw3UyP/OHESK gIdw== 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=nxMOPHUYFPydZI4vvEFc2xEYFvBshqvSovbvl84mc9A=; b=JfvnsdLLm8oMD/2UgaiDyfWF59/fE70Y/uEUdf3xrDAcGrOUnL/C0KNanzcZWU41y1 GkJm+MItXulx9G268SUxEfKmRqNIum9CA5hmY1hpXyNUnbOELfI9R/mLZCHJ1ZoU66fS LV9he2Y/05xF2WB0H5+bqCbYk+4EC7vr6SE+IvPBmgGsTKtZxqLq1IHXeID6zSUKpWTm r+Ad5G1jDfPLboevV5unKxb9FGtGXz9VeyCroHFd6RnI2QYU6ToihEh3cDIITyf0ktwU IX0Vhf5pbL9l6HtO8CxQnleSHorGQFZX4lwvToGNrQIW8FkxI2Iim+Cnax2BV3lVzmri 7gfw== X-Gm-Message-State: APjAAAUz8hoVMK59UX9zFOjFjVCLjJMdbyD42Ph+M6Zw3naERFuo8peY B8SzlGTmk0ZV8ltQ/CJoJBW0ZQrkRKod3+AGWPdQr62c X-Google-Smtp-Source: APXvYqzWYIC1sufpBt9MJsJLFFQfhqkk7ATMoYe7jSqs9yCwtCNOeXi4AdF5Od2wRGap7ULG9gYfBcO/M7W4O+2k4Ig= X-Received: by 2002:a24:c4d7:: with SMTP id v206mr24638551itf.102.1559714457859; Tue, 04 Jun 2019 23:00:57 -0700 (PDT) MIME-Version: 1.0 From: Marek Jankowski Date: Tue, 11 Jun 2019 16:33:15 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000036397c058a8d52e1" Archived-At: Subject: [MLS] Group ID 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, 05 Jun 2019 06:01:00 -0000 --00000000000036397c058a8d52e1 Content-Type: text/plain; charset="UTF-8" Hi, Regarding some issues that were raised in the last couple of months, I wonder if we should hide the group ID from the DS. I think the group ID is valuable metadata -- the DS may keep track of it and by that identify sudden changes in the traffic, which may leak information. Please consider the following alternatives: group_id[n] = HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1], "group_id", 4) I am aware it does not support reordering, But I'm sure one can figure an alternative that does. Marek. --00000000000036397c058a8d52e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Regarding some issues that were raised in the last = couple of months, I wonder if we should hide the group ID from the DS. I th= ink the group ID is valuable metadata -- the DS may keep track of it and by= that identify sudden changes in the traffic, which may leak information.Please consider the following alternatives:
group_id[n] =3D HKDF-Expan= d-Label(confirmation_key[n-1],group_id[n-1], "group_id", 4)
I = am aware it does not support reordering, But I'm sure one can figure an= alternative that does.

Marek.
--00000000000036397c058a8d52e1-- From nobody Wed Jun 5 00:59:53 2019 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 D0465120605 for ; Wed, 5 Jun 2019 00:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=wire-com.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 8N1DAh0nALuk for ; Wed, 5 Jun 2019 00:59:50 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 7DBA1120086 for ; Wed, 5 Jun 2019 00:59:50 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id v22so1223659wml.1 for ; Wed, 05 Jun 2019 00:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=REnHm9LWV5qS8iBHUh8RcJBSb50/5ofaziHB1w3Dvho=; b=fKj4Q45PMQxRZyiY6809zEirbKVZ40CZIhcykoBydjPiP4wz+Q5U71PKSoXduaw4hO Q+sOYJb7XWiC1WKy6qsfir3DLYpWNxPhOpI2+NYeUZtXYCFSS6AR/czb1FfOciPBEX/Q pNOi9ca6/Kvuhq3WAgV2RdiH+uzAL7CKKWO8A3VKWsP27nzglFNWrUE/VdS5tTfxD4NA avdUzBMEUz3EHFjf2IlFSoaGkyEKUz90H73ua4PgxgWUdOGjBf3KO1Z7v+PIJwoAgYQP Kst4WkJeHEFhmYpVhAqO7A92jMV0KuXDe82KMW7XgZkYKc60LeUYDzMIdZjYYp7l7qPu 9SZA== 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=REnHm9LWV5qS8iBHUh8RcJBSb50/5ofaziHB1w3Dvho=; b=JF/MqAxzoxi/5TpjsVlN89kKeBcV3HR1q8FN+JSp0LxAg38zC85wdZYLdlT8JM1LiZ dV/4eXPShiLs5GTMKlCkLcKT4ip2J9j3fVpSKjITSLTlhU16LaLsbXtufVeocQ/MCbGZ YWHzusUDcaBr2x/lTEnC2lpe3WGlIeF551d4Bl3XNImtTRHSI1s+i/rKBU/h4qaphw7A DG1Tat/vFHqVl0uM/jirvpPNpD83Ugd9Yt/uUpQDNBAAQK4xICJeFAGXGqvlIkIOerxo GAtbgUQVKbMneR9Ngimd34quDjHDBp147ahaVoRtqppw6cuKQY6r5576UzgOcFIRunzd oOBQ== X-Gm-Message-State: APjAAAUz3FuNErqNA4HGuFU1w3ONpuWHzNCzAgaSXdKVLmMDW+1R4AVH QswiF85s8FDOlVCVc6LSaWXTKQfobBI= X-Google-Smtp-Source: APXvYqx8dxXEciCsI1HtcC801Dm+KS3lVJdhvRfJdB0k+1u7lIlJ7EXxtYdzfUptLFwX/R3mgWrNKQ== X-Received: by 2002:a7b:cb4b:: with SMTP id v11mr2443722wmj.103.1559721588254; Wed, 05 Jun 2019 00:59:48 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id f2sm20363878wrq.48.2019.06.05.00.59.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 00:59:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Raphael Robert In-Reply-To: Date: Wed, 5 Jun 2019 09:59:46 +0200 Cc: Marek Jankowski Content-Transfer-Encoding: quoted-printable Message-Id: <7A857F01-3494-4F57-BCC0-C5DE3DBB96E3@wire.com> References: To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Group ID 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, 05 Jun 2019 07:59:53 -0000 Hi Marek, > I am aware it does not support reordering, But I'm sure one can figure = an alternative that does. We looked into doing exactly that. Server-side ordering is unfortunately = a hard requirement for TreeKEM, so this is an open issue. We=E2=80=99d = be happy to hear about a proposal that covers both problems! Raphael > On 11 Jun 2019, at 16:33, Marek Jankowski = wrote: >=20 > Hi, > Regarding some issues that were raised in the last couple of months, I = wonder if we should hide the group ID from the DS. I think the group ID = is valuable metadata -- the DS may keep track of it and by that identify = sudden changes in the traffic, which may leak information. > Please consider the following alternatives: > group_id[n] =3D HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1], = "group_id", 4) > I am aware it does not support reordering, But I'm sure one can figure = an alternative that does. >=20 > Marek. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Jun 5 13:29:26 2019 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 7B0FA120159 for ; Wed, 5 Jun 2019 13:29:24 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 1xqBjU3x_Nvl for ; Wed, 5 Jun 2019 13:29:22 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 10D48120019 for ; Wed, 5 Jun 2019 13:29:22 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id v186so4897300oie.5 for ; Wed, 05 Jun 2019 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bZCrV1poJp7wz+QPXsgHv/loNOnZ+VCyJKJoomkIzzc=; b=nmRJ5lF0iNwwFPtWPeei+Bed1ytSC8o/0e0cRcgzB1WIHXfc7iqjp7pIB73Elb/Nqm oYyFArAPQEMMssDeW3/qOL9cd2PL746zKpztJp7aHgxl7XGWQZI2UWqrI2ZgmuGTdjUL yDOnb8Zvt3Vz/D8iFFU9kkSFIuCUhBJQzgtVStaBgUWpqr2cOeMCuxbG8hF+3KrVq3M7 jIQ6Ufw7V9BOkOkJlIsjTHqTP1w4Cs4IGQNQoHBrkI5p/UnxicXHIIVHc/0E2xLaVe6+ NuUeLFKjPTKikliGEqNTSmCwANkELfMotlkbj+bSj6LIGjHlwCG3jEEqsCaAFn52ubaR 0qJQ== 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=bZCrV1poJp7wz+QPXsgHv/loNOnZ+VCyJKJoomkIzzc=; b=MumLrMU/djEmuqr9znbIGQYlL4Y1qhuxyQJ4V9YHMhDTpjLcd9D8zqO8KBtWfHfVhg lyIA06UstQPy7hJpaW0rUPCnogx5wtrmCkr+V9iKQ53te36AlS/9P3/zQQDndxk/dR+W XJ2BchPd9vul8vqlsmouzx1KWHw/pJsebTXAPD0f4GPF5b/3yEwy/0yMlj7UC++UFTny JT7K2E4bBnx+cnh50qaI51jXej8FHF1OLbsUXjXOS1dXCGX8XIAsKKIn/vtLZPQgJ0ro NR6TxPVtaMlKPZpN9D3L9CeIqzcnFK3RG3dvoASPRw2cVE2citgbAlg3iM+Mn4mv/hJC bZFQ== X-Gm-Message-State: APjAAAV9W5+YdI8qSzZ0g1LIsbtHZkYjaDDHJbDwZT0TPuCOrM7WkrC+ l3GXzL/paN1A6CEAY8rcKLbnZnbEWetJR1UDaRm/WA== X-Google-Smtp-Source: APXvYqyoeCgWUH7xkyQ8Hrsr/mjDbFyAvCVgTsMb+rFdxAdGCAhNtZbpgpoU2VwzTP1tT0pSKDIvXTFAV74RXh652/E= X-Received: by 2002:aca:de44:: with SMTP id v65mr9243394oig.135.1559766561100; Wed, 05 Jun 2019 13:29:21 -0700 (PDT) MIME-Version: 1.0 References: <7A857F01-3494-4F57-BCC0-C5DE3DBB96E3@wire.com> In-Reply-To: <7A857F01-3494-4F57-BCC0-C5DE3DBB96E3@wire.com> From: Richard Barnes Date: Wed, 5 Jun 2019 13:29:00 -0700 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG , Marek Jankowski Content-Type: multipart/alternative; boundary="000000000000ceab2c058a997358" Archived-At: Subject: Re: [MLS] Group ID 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, 05 Jun 2019 20:29:24 -0000 --000000000000ceab2c058a997358 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Like Raphael, I'm not concerned about the ordering requirement, since we already have an ordering requirement. Note, however, that whatever identifier is used here will probably have to be stable within an epoch, so the DS will still be able to see traffic volumes within an epoch. The DS may also be able to use time correlations to infer which opaque groupID values represent the same group. That still seems like it makes it harder for the DS to be malicious, so it seems worthwhile to me. Benjamin Beurdouche had raised a similar idea earlier, of replacing the (groupID, epoch) pair with a single ID that is opaque to the DS. I'm increasingly thinking that that's probably the way to go. Marek / Benjamin, if you'd like to update PR#152 to do this, that could help move this along. I wonder if we still want some constant group ID value, even if it's known only to group members. No concrete On Wed, Jun 5, 2019 at 1:00 AM Raphael Robert wrote: > Hi Marek, > > > I am aware it does not support reordering, But I'm sure one can figure > an alternative that does. > > We looked into doing exactly that. Server-side ordering is unfortunately = a > hard requirement for TreeKEM, so this is an open issue. We=E2=80=99d be h= appy to > hear about a proposal that covers both problems! > > Raphael > > > On 11 Jun 2019, at 16:33, Marek Jankowski > wrote: > > > > Hi, > > Regarding some issues that were raised in the last couple of months, I > wonder if we should hide the group ID from the DS. I think the group ID i= s > valuable metadata -- the DS may keep track of it and by that identify > sudden changes in the traffic, which may leak information. > > Please consider the following alternatives: > > group_id[n] =3D HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1], > "group_id", 4) > > I am aware it does not support reordering, But I'm sure one can figure > an alternative that does. > > > > Marek. > > _______________________________________________ > > 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 > --000000000000ceab2c058a997358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Like Raphael, I'm not concerned about the orderin= g requirement, since we already have an ordering requirement.=C2=A0 Note, h= owever, that whatever identifier is used here will probably have to be stab= le within an epoch, so the DS will still be able to see traffic volumes wit= hin an epoch.=C2=A0 The DS may also be able to use time correlations to inf= er which opaque groupID values represent the same group.=C2=A0

That still seems like it makes it harder for the DS to be= malicious, so it seems worthwhile to me.=C2=A0 Benjamin Beurdouche had rai= sed a similar idea earlier, of replacing the (groupID, epoch) pair with a s= ingle ID that is opaque to the DS.=C2=A0 I'm increasingly thinking that= that's probably the way to go.=C2=A0 Marek / Benjamin, if you'd li= ke to update PR#152 to do this, that could help move this along.
=

I wonder if we still want some constant group= ID value, even if it's known only to group members.=C2=A0 No concrete =


On Wed, Jun 5, 2019 at 1:00 AM Raphael Robert <= raphael=3D40wire.com@dmarc.iet= f.org> wrote:
Hi Marek,

> I am aware it does not support reordering, But I'm sure one can fi= gure an alternative that does.

We looked into doing exactly that. Server-side ordering is unfortunately a = hard requirement for TreeKEM, so this is an open issue. We=E2=80=99d be hap= py to hear about a proposal that covers both problems!

Raphael

> On 11 Jun 2019, at 16:33, Marek Jankowski <mjankowski309@gmail.com> wrote:=
>
> Hi,
> Regarding some issues that were raised in the last couple of months, I= wonder if we should hide the group ID from the DS. I think the group ID is= valuable metadata -- the DS may keep track of it and by that identify sudd= en changes in the traffic, which may leak information.
> Please consider the following alternatives:
> group_id[n] =3D HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1],= "group_id", 4)
> I am aware it does not support reordering, But I'm sure one can fi= gure an alternative that does.
>
> Marek.
> _______________________________________________
> 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
--000000000000ceab2c058a997358-- From nobody Wed Jun 5 13:30:25 2019 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 81B86120043 for ; Wed, 5 Jun 2019 13:30:22 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yNIYoaA6wYAK for ; Wed, 5 Jun 2019 13:30:19 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 28178120019 for ; Wed, 5 Jun 2019 13:30:19 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id 203so19147867oid.13 for ; Wed, 05 Jun 2019 13:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fUjZ8xgX06ngmIMfsex9eDxy1QsFyMq9CZP+BzFdb54=; b=nUI1tu7jAfEsNIZyp5jkasr1kUEn0NoSZTARQwQSFnsfQfIHw1pH/3FwTV4GjKx/5n i4is9WlVMNC8DFMtCH4dd69/cK7BFOQ+U94XMzqg5eqVKglrdyq6Ps8iqWfXdV1OWLHt W3b3fYaPV3/BAm4cdRngSUOzsowe2O2Uty1rfKYhxabdts6WuLNiExFxQ+qG+PNeBlZg /8+EyBGtMH7tk02payWTDLoVkkCfXmHSXnpQipJuevyaHxBXQL5px21w49Fjb15NxTtO qO/R/ai9hywKF52yOuNq5hI6SX2L3ugjb7M+eYDTsol8Xkm9+E39sklMfCt2/efW44l2 A+fw== 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=fUjZ8xgX06ngmIMfsex9eDxy1QsFyMq9CZP+BzFdb54=; b=P6b1aO9YfmfVVnqIocipbLwHDWndA/sMGU6PMuyRpoP04iLPPsKzi315UV83zWKjG1 lGZ5uGTUcwM7YRB0Wl6tbOCLsoS1dVsvJDyCDVD3TperAQDw/ArI0AbIdT0hMh7giGpU qPjr8MCtDqpJa3bAcP3IKnl+yV4jWMim2MlLOEMERelFOrCqqi1lbGpB+kqh2omLKoHV kWk2g+2oDEbKCR3ebeHlekh0dQFE9osokj+CBGkfEDaphk9Ch9pvUwoNDYYjT19c9gfZ ZmGID+fukv8eWfY3V2XS9M/ZLJvkABV4Uvp6oMzffGejtwQyR6BM2Q8LQq6xB4EZvj7h VLYw== X-Gm-Message-State: APjAAAXUiL8dySQb09nA3xl/s7NB2Y27vi1XTOuUfVbg8V2RIVDMkbUm ZCq36au54UYjk6bRT82YcwAqCZVTf1x3t9Tm1TttdA== X-Google-Smtp-Source: APXvYqzL8uOpZbEX9Wmg7XH9P7JTKv9OW/0rgXcAUPb+PhxWCjhbud7mWQnv17bdkbBhhQsvwnLR/o5abELzKOR7Izs= X-Received: by 2002:aca:e687:: with SMTP id d129mr7808784oih.169.1559766618347; Wed, 05 Jun 2019 13:30:18 -0700 (PDT) MIME-Version: 1.0 References: <7A857F01-3494-4F57-BCC0-C5DE3DBB96E3@wire.com> In-Reply-To: From: Richard Barnes Date: Wed, 5 Jun 2019 13:29:58 -0700 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG , Marek Jankowski Content-Type: multipart/alternative; boundary="000000000000383113058a997707" Archived-At: Subject: Re: [MLS] Group ID 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, 05 Jun 2019 20:30:23 -0000 --000000000000383113058a997707 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, hit "send" prematurely. On Wed, Jun 5, 2019 at 1:29 PM Richard Barnes wrote: > Like Raphael, I'm not concerned about the ordering requirement, since we > already have an ordering requirement. Note, however, that whatever > identifier is used here will probably have to be stable within an epoch, = so > the DS will still be able to see traffic volumes within an epoch. The DS > may also be able to use time correlations to infer which opaque groupID > values represent the same group. > > That still seems like it makes it harder for the DS to be malicious, so i= t > seems worthwhile to me. Benjamin Beurdouche had raised a similar idea > earlier, of replacing the (groupID, epoch) pair with a single ID that is > opaque to the DS. I'm increasingly thinking that that's probably the way > to go. Marek / Benjamin, if you'd like to update PR#152 to do this, that > could help move this along. > https://github.com/mlswg/mls-protocol/pull/152 I wonder if we still want some constant group ID value, even if it's known > only to group members. No concrete > ... need is occurring to me right now, but it seems like there might be some utility in separating contexts. --Richard > > > On Wed, Jun 5, 2019 at 1:00 AM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > >> Hi Marek, >> >> > I am aware it does not support reordering, But I'm sure one can figure >> an alternative that does. >> >> We looked into doing exactly that. Server-side ordering is unfortunately >> a hard requirement for TreeKEM, so this is an open issue. We=E2=80=99d b= e happy to >> hear about a proposal that covers both problems! >> >> Raphael >> >> > On 11 Jun 2019, at 16:33, Marek Jankowski >> wrote: >> > >> > Hi, >> > Regarding some issues that were raised in the last couple of months, I >> wonder if we should hide the group ID from the DS. I think the group ID = is >> valuable metadata -- the DS may keep track of it and by that identify >> sudden changes in the traffic, which may leak information. >> > Please consider the following alternatives: >> > group_id[n] =3D HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1], >> "group_id", 4) >> > I am aware it does not support reordering, But I'm sure one can figure >> an alternative that does. >> > >> > Marek. >> > _______________________________________________ >> > 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 >> > --000000000000383113058a997707 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, hit "send" prematurely.<= br>

On Wed, Jun 5, 2019 at 1:29 PM Richard Barnes <rlb@ipv.sx> wrote:<= br>
Like Raphael, I'm not concerned about the ordering requirement, s= ince we already have an ordering requirement.=C2=A0 Note, however, that wha= tever identifier is used here will probably have to be stable within an epo= ch, so the DS will still be able to see traffic volumes within an epoch.=C2= =A0 The DS may also be able to use time correlations to infer which opaque = groupID values represent the same group.=C2=A0

That still seems like it makes it harder for the DS to be malicious, so i= t seems worthwhile to me.=C2=A0 Benjamin Beurdouche had raised a similar id= ea earlier, of replacing the (groupID, epoch) pair with a single ID that is= opaque to the DS.=C2=A0 I'm increasingly thinking that that's prob= ably the way to go.=C2=A0 Marek / Benjamin, if you'd like to update PR#= 152 to do this, that could help move this along.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I wo= nder if we still want some constant group ID value, even if it's known = only to group members.=C2=A0 No concrete
=
... need is occurring to me right now, but it seems like the= re might be some utility in separating contexts.

-= -Richard
=C2=A0


On Wed, Jun 5, 2019 = at 1:00 AM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
Hi Marek,

> I am aware it does not support reordering, But I'm sure one can fi= gure an alternative that does.

We looked into doing exactly that. Server-side ordering is unfortunately a = hard requirement for TreeKEM, so this is an open issue. We=E2=80=99d be hap= py to hear about a proposal that covers both problems!

Raphael

> On 11 Jun 2019, at 16:33, Marek Jankowski <mjankowski309@gmail.com> wrote:=
>
> Hi,
> Regarding some issues that were raised in the last couple of months, I= wonder if we should hide the group ID from the DS. I think the group ID is= valuable metadata -- the DS may keep track of it and by that identify sudd= en changes in the traffic, which may leak information.
> Please consider the following alternatives:
> group_id[n] =3D HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1],= "group_id", 4)
> I am aware it does not support reordering, But I'm sure one can fi= gure an alternative that does.
>
> Marek.
> _______________________________________________
> 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
--000000000000383113058a997707-- From nobody Thu Jun 6 12:33:08 2019 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 4B63312011B for ; Thu, 6 Jun 2019 12:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 azjZSZPSxW7E for ; Thu, 6 Jun 2019 12:33:06 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 71F0812014F for ; Thu, 6 Jun 2019 12:32:59 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id 14so4127456qtf.0 for ; Thu, 06 Jun 2019 12:32:59 -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:message-id:date :to; bh=C8ovEAhBA6w39y033yFOaQVommuN4ZNLUpN0NLyZM0k=; b=RUwdTACmD1OcFDpYqG1lSOFyqxPCf3wSYPJ/VNVsBzdK+OmpQvt3z+1xaUDfrT254B nG7LkTQrR27Bf08TPNuk+P6/129CWIqmeYQI8ccmESELD365szXy9m1YGOHsoYfe4lB/ gvpiQ8odtGQZn3CQYbXPTQX5B4hw6whjXG5Zk= 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:message-id:date:to; bh=C8ovEAhBA6w39y033yFOaQVommuN4ZNLUpN0NLyZM0k=; b=GUXVeS2/Vyt+0ZdlUv6HzRuaYuK0jtbSJsd230Nqg/ubSBLGanAR7MirzHZvya+U++ EkFzjkL/vGJ+NbR2+kwRgCFEpzSCi7t5T7u9dkaT6jtJt0lzZ6EhZu4ixVkbzIkvsr3F UlYZaymQr8OwDobfFK2xCJ3Yhn6bvJtcuS3dQcSQ3ZJ7O7V9li7Etjjj7Xj4zIdUkYh/ cJcGIjC6y71gsDpAej6A6CMlVfb+Pe4O3Gfr0VAbi5eAiQlZsu6PMV9ztUNOg1GF/z8e ebAu+cZe9SvwGZsVIZj2E0MaddXfrDqZXgwY2nP93MbU7ytbbzUD0Hbvq/8Yhc2hAoiw tj+Q== X-Gm-Message-State: APjAAAUpuU/slRtCv25cJM9GRGEg9SogWcGLkFGgW7S57H6MA5C2eyZk kPpV9CdYdJmMG6C1DMOjpQISHb8fNwQ= X-Google-Smtp-Source: APXvYqx33BposHvzDwXA0k91NFrewjpfeZS4gAvp6TcP8SljFG8kK75vYC9IgNDiMGe9i0gDPzXbDQ== X-Received: by 2002:ac8:38c5:: with SMTP id g5mr43097880qtc.299.1559849578465; Thu, 06 Jun 2019 12:32:58 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id m4sm1374038qka.70.2019.06.06.12.32.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2019 12:32:58 -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 12.4 \(3445.104.11\)) Message-Id: <324D5227-F4BB-4D87-8426-336856F5ED02@sn3rd.com> Date: Thu, 6 Jun 2019 15:32:57 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] MLS@IETF105: Agenda Topics 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, 06 Jun 2019 19:33:07 -0000 The MLS WG will be meeting @ IETF 105 in Montreal. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to mls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. Cheers, Nick and Sean= From nobody Mon Jun 10 07:34:56 2019 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 6E634120020 for ; Mon, 10 Jun 2019 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_96_Q=1.508, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXkrhO1tvQHa for ; Mon, 10 Jun 2019 07:34:53 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 17B20120019 for ; Mon, 10 Jun 2019 07:34:53 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id q14so12400410itc.5 for ; Mon, 10 Jun 2019 07:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MQI05QmbZ6M+ayDvVLbO0I3oLSYJK8CMxXuWE4dpOzU=; b=Y2E2vKSO6WhZgNTBhugy8fwE2mkNSgS6zJU2xZo6GWJQVl9kYXz+SDt0m5+PP+T6ra ptohZcSBlYdk1oyvAM2cGf96/jvl2IhaldbkC8CFsVrLzW8zbxT6VTO8S/j6zsF0CF3J 2Go8G9MJHZe3c19EdT9IHKU/T2BWyxEpjuMOrdVG/LDnKzwHUizBhAMlvVWZrrN45vbb uzF9RIBcUf5MccbrzDZyE7OiViPPok7pPr7QdISBl3SXYV80UeXUKe+mXW6KsYJKRiS2 PcRk85OpZO44zEA7b/wCx/QrAs8m8hMmqLAGHbw6twmvRkH+yw35weiZ9yggYIk9iioo TiRQ== 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=MQI05QmbZ6M+ayDvVLbO0I3oLSYJK8CMxXuWE4dpOzU=; b=V1/+idd+5InMUsJTAVy/YoPBvf57Io6YAGseUICiqf4RgO1UxEExto5JOYYUp6BPSX 5PIRlQQ845EV7irCBMVO3WxlE69f2N+KBsVDCk/fv52r/tJGt8sMajudUDrbqNfDaxix HqvVh/1V0X9FShEJ5SArFOMqS9+ftcGm+KKt7Z6TimJAsq+aASIwkjDxU/w5giO/RibO GJXk8Z7SxXt8VLEWqpO9V6tNsYRHc3BScFZr7W8ixkYaIOjcCvEhc9zt1TXgEqc6UI7d DfFcL8XrN5mS80R9b4l9crfoVZBmpq1xIajHtZk99fDD/Hy41jqffMqqvp3Uhe70pbh1 /FjA== X-Gm-Message-State: APjAAAU8RNIlMtUd7jjvh0YggIszRRvll4A8thITmNSK5JPdHi0mDQg+ EypaV1/vURlHZQwtfCcWSRTbNPkVjWRADEWURhzznJEh X-Google-Smtp-Source: APXvYqwqFFDdySU3AeJ1X3FRlEbnQ+jpPBzUZ2wQhxtLQTMwjzNBojKIgHyAQhEv5nMR/IZ3LZ8+D6IU4W/Y2i5xEP0= X-Received: by 2002:a24:c4d7:: with SMTP id v206mr14446517itf.102.1560177292266; Mon, 10 Jun 2019 07:34:52 -0700 (PDT) MIME-Version: 1.0 From: Marek Jankowski Date: Sun, 16 Jun 2019 18:06:48 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ad653058af91598" Archived-At: Subject: [MLS] PBC in MLS 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, 10 Jun 2019 14:34:55 -0000 --0000000000004ad653058af91598 Content-Type: text/plain; charset="UTF-8" Hi all, I have only briefly read through the previous MLS discussions, so please forgive me if it had been discussed before. Lately there has been significant amount of research and standardization effort in the area of pairings (I-D boneh, I-D yonezawa). The schemes, some of which are already deployed in the industry (Cloudflare, Intel), offer interesting cryptographic primitives with somewhat surprisingly small ciphertext length. One of the drawbacks I identified in the current MLS proposal is the log(n) factor each user pays in bandwidth for every ADD/DELETE/UPDATE message. It is especially significant in groups with many members, which is a requirement for any MLS solution. I wonder if any of the primitives PBC offers (O(1) ciphertext length IBBE, 3PDH) may reduce the bandwidth usage for large groups. I would be happy to hear any of the folks' ideas and thoughts regarding those schemes and their potential uses for MLS. Thank you, Marek. --0000000000004ad653058af91598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have only briefly read through the previo= us MLS discussions, so please forgive me if it had been discussed before.
Lately there has been significant amount of research and standardizat= ion effort in the area of pairings (I-D boneh, I-D yonezawa). The schemes, = some of which are already deployed in the industry (Cloudflare, Intel), off= er interesting cryptographic primitives with somewhat surprisingly small ci= phertext length.

One of the drawbacks I identified in the current ML= S proposal is the log(n) factor each user pays in bandwidth for every ADD/D= ELETE/UPDATE message. It is especially significant in groups with many memb= ers, which is a requirement for any MLS solution. I wonder if any of the pr= imitives PBC offers (O(1) ciphertext length IBBE, 3PDH) may reduce the band= width usage for large groups.

I would be happy to hear any of the fo= lks' ideas and thoughts regarding those schemes and their potential use= s for MLS.

Thank you,
Marek.
--0000000000004ad653058af91598-- From nobody Fri Jun 14 09:57:58 2019 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 5E344120186 for ; Fri, 14 Jun 2019 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=protonmail.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 9QB8XHVia0bC for ; Fri, 14 Jun 2019 09:57:53 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 EF4BD1205FC for ; Fri, 14 Jun 2019 09:57:51 -0700 (PDT) Date: Fri, 14 Jun 2019 16:57:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1560531469; bh=kZnE5uMT1EvDUPA5IevvM6GDn6kk8Z3cqKn5si0B1+s=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=LCCgIyblKI8zNresgE4tVumm+7UftoIFvcHczIixu45imU+K4C/HdZ6X+P2DrEBHv iq0ptvuTaghV/pNxiktR0sBhYVf7mE3GTsOmdzrFfYwVDJUIziEQBGR09jH98KfzBQ iMCMzVvyahOzxgF9K4jTS7RJuf1IUkNWsO2IKfR0= To: "mls@ietf.org" From: Ian Reply-To: Ian Message-ID: Feedback-ID: H1veCrExs7KBsBDnLUM0Kd8bl1OyJ7rKqET0jLFaSel3aFjbg1QfbnTy5F7ptCUBzu0p5GVlzoBculqXLGFxiw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_4c5431713387cd5910384d98eee34995" Archived-At: Subject: [MLS] P2P operation of MLS? 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, 14 Jun 2019 16:57:56 -0000 This is a multi-part message in MIME format. --b1_4c5431713387cd5910384d98eee34995 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgQWxsLAoKSSdtIHRoZSBmb3VuZGVyIG9mIFBlZXJnb3MgWzFdLCBhIGRlY2VudHJhbGlzZWQg ZW5kLXRvLWVuZCBlbmNyeXB0ZWQgc3RvcmFnZSBhbmQgc29jaWFsIG5ldHdvcmsgYnVpbHQgb24g dG9wIG9mIElQRlMgWzJdLiBJJ20gbG9va2luZyBmb3IgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wg Zm9yIGxhcmdlIGdyb3VwIGNoYXRzIGFuZCB3YXMgcG9pbnRlZCB0b3dhcmQgTUxTLiBJIGFtIGxv b2tpbmcgaW50byB0aGUgcG9zc2liaWxpdHkgb2YgaW1wbGVtZW50aW5nIGFuZCB1c2luZyBNTFMg aW4gUGVlcmdvcyBpbiB0aGUgZnV0dXJlLgoKVGhlIG1haW4gdGhpbmcgSSBjdXJyZW50bHkgaGF2 ZSBxdWVzdGlvbnMgYWJvdXQgaXMgdGhlIGRlbGl2ZXJ5IHNlcnZpY2UgKFdlIGhhdmUgYSBwa2kg dGhhdCBmaXRzIHBlcmZlY3RseSB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSkuIFRoZSBtYWlu IHF1ZXN0aW9uIGlzIHdoZXRoZXIgTUxTIHdpbGwgc3RpbGwgd29yayBpbiBhIGZ1bGx5IFAyUCBz dG9yZSBhbmQgZm9yd2FyZCBuZXR3b3JrLiBUaGUgc2V0dXAgSSdtIGltYWdpbmluZyBpcyBsb2dp Y2FsbHkgZXF1aXZhbGVudCB0byBlYWNoIG1lbWJlciBvZiBhIGdyb3VwIHN0b3JpbmcgdGhlaXIg b3duIGFwcGVuZCBvbmx5IGxpc3Qgb2YgbWVzc2FnZXMgaW4gdGhlIGdyb3VwLiBXaGVuIHRoZXkg dGhlbXNlbHZlcyBzZW5kIGEgbWVzc2FnZSB0aGV5IGp1c3QgYXBwZW5kIHRvIHRoZWlyIG93biBj b3B5LiBPdGhlciBtZW1iZXJzIGhhdmUgYWNjZXNzIHRvIGVhY2ggb3RoZXIgbWVtYmVyJ3MgdmVy c2lvbiwgYW5kIHBlcmlvZGljYWxseSBtZXJnZSBpbiBhbnkgbmV3IG1lc3NhZ2VzIHRvIHRoZWly IG93biBjb3B5LiBUaGlzIHByZXNlcnZlcyB0aGUgb3JkZXIgb2YgbWVzc2FnZXMgZnJvbSBhIGdp dmVuIHVzZXIsIGFuZCBlbnN1cmVzIHRoYXQgZGVwZW5kZW50IG1lc3NhZ2VzIGFyZSBiZWZvcmUg dGhvc2UgdGhhdCBkZXBlbmQgb24gdGhlbS4gV291bGQgdGhpcyBzdWZmaWNlPwoKVGhlIG90aGVy IHJlbGF0ZWQgcXVlc3Rpb24gaXMgaWYgdGhlcmUgaXMgYSBuZXR3b3JrIHBhcnRpdGlvbiwgbXkg dW5kZXJzdGFuZGluZyBzbyBmYXIgaXMgdGhlIHR3byBoYWx2ZXMgb2YgYSBncm91cCBjYW4gc3Rp bGwgY29udGludWUgbWVzc2FnaW5nIGFtb25nc3QgdGhlaXIgcGFydGl0aW9uIChpbiB0aGVpciB2 aWV3IHRoZSBvdGhlciBoYWxmIGlzIGp1c3Qgb2ZmbGluZSksIGFuZCBldmVudHVhbGx5IHRoZSBo YWx2ZXMgY291bGQgcmVjb25uZWN0IGFuZCBtZXJnZSBhbmQgcmVjZWl2ZSBhbGwgdGhlIG1lc3Nh Z2VzIGZyb20gdGhlIG90aGVyIGhhbGYsIHVwZGF0aW5nIHRoZSB0cmVla2VtIGFzIHRoZXkgZ28u IElzIHRoaXMgY29ycmVjdD8KCk9uZSBzbWFsbCBjb21tZW50IG9uIG15IHJlYWRpbmdzIHNvIGZh cjogSW4gbXkgb3BpbmlvbiB0aGUgZGlyZWN0b3J5IHNlcnZpY2Ugd2hlcmUgdGhlIGluaXRpYWwg a2V5IG1hdGVyaWFsIGlzIG9idGFpbmVkIGZyb20gaXMgbG9naWNhbGx5IGRpc3RpbmN0IGZyb20g dGhlIGRlbGl2ZXJ5IHNlcnZpY2UgYW5kIHNob3VsZCBiZSBkZXNjcmliZWQgYXMgc3VjaCwgZ2l2 aW5nIHRocmVlIGFyY2hpdGVjdHVyYWwgZGVwZW5kZW5jaWVzLgoKcC5zLiBJIGxpdmUgaW4gT3hm b3JkIChVSykgYW5kIHdvdWxkIGxvdmUgdG8gbWVldCB0aGUgT3hmb3JkIGJhc2VkIG1lbWJlcnMg aWYgdGhleSBhcmUgaW50ZXJlc3RlZC4KCk1hbnkgdGhhbmtzLApJYW4gUHJlc3RvbgoKWzFdIGh0 dHBzOi8vZ2l0aHViLmNvbS9wZWVyZ29zL3BlZXJnb3MKWzJdIGh0dHBzOi8vaXBmcy5pbwoKLS0K RHIgSWFuIFByZXN0b24KUGVlcmdvcwpAcGVlcmdvcwpodHRwczovL3BlZXJnb3Mub3Jn --b1_4c5431713387cd5910384d98eee34995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5IaSBBbGwsPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSdtIHRoZSBmb3VuZGVy IG9mIFBlZXJnb3MgWzFdLCBhIGRlY2VudHJhbGlzZWQgZW5kLXRvLWVuZCBlbmNyeXB0ZWQgc3Rv cmFnZSBhbmQgc29jaWFsIG5ldHdvcmsgYnVpbHQgb24gdG9wIG9mIElQRlMgWzJdLiBJJ20gbG9v a2luZyBmb3IgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wgZm9yIGxhcmdlIGdyb3VwIGNoYXRzIGFu ZCB3YXMgcG9pbnRlZCB0b3dhcmQgTUxTLiBJIGFtIGxvb2tpbmcgaW50byB0aGUgcG9zc2liaWxp dHkgb2YgaW1wbGVtZW50aW5nIGFuZCB1c2luZyBNTFMgaW4gUGVlcmdvcyBpbiB0aGUgZnV0dXJl LiA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbWFpbiB0aGluZyBJIGN1cnJlbnRs eSBoYXZlIHF1ZXN0aW9ucyBhYm91dCBpcyB0aGUgZGVsaXZlcnkgc2VydmljZSAoV2UgaGF2ZSBh IHBraSB0aGF0IGZpdHMgcGVyZmVjdGx5IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlKS4gVGhl IG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciBNTFMgd2lsbCBzdGlsbCB3b3JrIGluIGEgZnVsbHkg UDJQIHN0b3JlIGFuZCBmb3J3YXJkIG5ldHdvcmsuIFRoZSBzZXR1cCBJJ20gaW1hZ2luaW5nIGlz IGxvZ2ljYWxseSBlcXVpdmFsZW50IHRvIGVhY2ggbWVtYmVyIG9mIGEgZ3JvdXAgc3RvcmluZyB0 aGVpciBvd24gYXBwZW5kIG9ubHkgbGlzdCBvZiBtZXNzYWdlcyBpbiB0aGUgZ3JvdXAuIFdoZW4g dGhleSB0aGVtc2VsdmVzIHNlbmQgYSBtZXNzYWdlIHRoZXkganVzdCBhcHBlbmQgdG8gdGhlaXIg b3duIGNvcHkuIE90aGVyIG1lbWJlcnMgaGF2ZSBhY2Nlc3MgdG8gZWFjaCBvdGhlciBtZW1iZXIn cyB2ZXJzaW9uLCBhbmQgcGVyaW9kaWNhbGx5IG1lcmdlIGluIGFueSBuZXcgbWVzc2FnZXMgdG8g dGhlaXIgb3duIGNvcHkuIFRoaXMgcHJlc2VydmVzIHRoZSBvcmRlciBvZiBtZXNzYWdlcyBmcm9t IGEgZ2l2ZW4gdXNlciwgYW5kIGVuc3VyZXMgdGhhdCBkZXBlbmRlbnQgbWVzc2FnZXMgYXJlIGJl Zm9yZSB0aG9zZSB0aGF0IGRlcGVuZCBvbiB0aGVtLiBXb3VsZCB0aGlzIHN1ZmZpY2U/PGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIG90aGVyIHJlbGF0ZWQgcXVlc3Rpb24gaXMgaWYg dGhlcmUgaXMgYSBuZXR3b3JrIHBhcnRpdGlvbiwgbXkgdW5kZXJzdGFuZGluZyBzbyBmYXIgaXMg dGhlIHR3byBoYWx2ZXMgb2YgYSBncm91cCBjYW4gc3RpbGwgY29udGludWUgbWVzc2FnaW5nIGFt b25nc3QgdGhlaXIgcGFydGl0aW9uIChpbiB0aGVpciB2aWV3IHRoZSBvdGhlciBoYWxmIGlzIGp1 c3Qgb2ZmbGluZSksIGFuZCBldmVudHVhbGx5IHRoZSBoYWx2ZXMgY291bGQgcmVjb25uZWN0IGFu ZCBtZXJnZSBhbmQgcmVjZWl2ZSBhbGwgdGhlIG1lc3NhZ2VzIGZyb20gdGhlIG90aGVyIGhhbGYs IHVwZGF0aW5nIHRoZSB0cmVla2VtIGFzIHRoZXkgZ28uIElzIHRoaXMgY29ycmVjdD88YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PbmUgc21hbGwgY29tbWVudCBvbiBteSByZWFkaW5ncyBz byBmYXI6IEluIG15IG9waW5pb24gdGhlIGRpcmVjdG9yeSBzZXJ2aWNlIHdoZXJlIHRoZSBpbml0 aWFsIGtleSBtYXRlcmlhbCBpcyBvYnRhaW5lZCBmcm9tIGlzIGxvZ2ljYWxseSBkaXN0aW5jdCBm cm9tIHRoZSBkZWxpdmVyeSBzZXJ2aWNlIGFuZCBzaG91bGQgYmUgZGVzY3JpYmVkIGFzIHN1Y2gs IGdpdmluZyB0aHJlZSBhcmNoaXRlY3R1cmFsIGRlcGVuZGVuY2llcy4gPGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+cC5zLiBJIGxpdmUgaW4gT3hmb3JkIChVSykgYW5kIHdvdWxkIGxvdmUg dG8gbWVldCB0aGUgT3hmb3JkIGJhc2VkIG1lbWJlcnMgaWYgdGhleSBhcmUgaW50ZXJlc3RlZC4g PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TWFueSB0aGFua3MsPGJyPjwvZGl2PjxkaXY+ SWFuIFByZXN0b248YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5bMV0gPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL3BlZXJnb3MvcGVlcmdvcyI+aHR0cHM6Ly9naXRodWIuY29tL3BlZXJn b3MvcGVlcmdvczwvYT48YnI+PC9kaXY+PGRpdj5bMl0gaHR0cHM6Ly9pcGZzLmlvPGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIj48 ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyIj48ZGl2IGNsYXNzPSJw cm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1 cmVfYmxvY2stdXNlciI+LS08YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1 cmVfYmxvY2stdXNlciI+RHIgSWFuIFByZXN0b248YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciI+UGVlcmdvcyA8YnI+PC9kaXY+PGRpdiBjbGFzcz0i cHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciI+QHBlZXJnb3M8YnI+PC9kaXY+PGRpdiBj bGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciI+PGEgaHJlZj0iaHR0cHM6Ly9w ZWVyZ29zLm9yZyI+aHR0cHM6Ly9wZWVyZ29zLm9yZzwvYT48YnI+PC9kaXY+PGRpdiBjbGFzcz0i cHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9uIHByb3Rvbm1haWxfc2lnbmF0dXJlX2Js b2NrLWVtcHR5Ij48YnI+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdiBjbGFz cz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9uIHByb3Rvbm1haWxfc2lnbmF0dXJl X2Jsb2NrLWVtcHR5Ij48YnI+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_4c5431713387cd5910384d98eee34995-- From nobody Fri Jun 28 16:01:29 2019 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 91F94120942; Fri, 28 Jun 2019 15:57:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267759.11015.241469215953860432.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:57 -0700 Archived-At: Subject: [MLS] mls - Requested sessions have been scheduled for IETF 105 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, 28 Jun 2019 22:58:09 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (1:00 requested) Thursday, 25 July 2019, Afternoon Session III 1740-1910 Room Name: Place du Canada size: 300 --------------------------------------------- mls Session 2 (2:00 requested) Friday, 26 July 2019, Morning Session I 1000-1200 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/mls.ics Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 125 Conflicts to Avoid: First Priority: acme artarea cfrg dispatch iasa2 httpbis perc quic rtcweb saag secdispatch tls Second Priority: curdle dprive lamps sidrops stir suit teep People who must be present: Eric Rescorla Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: ---------------------------------------------------------