From nobody Thu Jan 2 12:39:14 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 27AFE120103 for ; Thu, 2 Jan 2020 12:39: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pfIToVGJFngm for ; Thu, 2 Jan 2020 12:39:11 -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 1D7221200FA for ; Thu, 2 Jan 2020 12:39:11 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id z76so32642584qka.2 for ; Thu, 02 Jan 2020 12:39:11 -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=MPc3o5DgmtnCQMaUu6A0rWLfpErutk7ioykzg6PwRno=; b=pd10EIp33Hl1HrRSLON9Ih/dBh8D8BgLxiYO/GgC4qvkOPHZOZbHDhm4gfiCIYvf1n 1IYQa4emjRZkBI0UK3YNfdMR49ZwpaVSWcwR0rsRYeEsrs7ZAfgPNxyVpNIVEDWyPQp+ iTAgYKQhEP/LGQ9eLqZSV+fHFlG5BykCwX0vkvNhlC4hsHLKQvOTUxo+14IyF9dMPneq LeCQZddm52LtXf+Q/e/opn5W0ZxJFpuYDDp/RpEz+yqZ0Z7s3ZRL2/yFRz7+SAEOYtMc zfZoYtTAaqB3MlFCps9OL/oXNGe4xXwD7iJJEFnxGpFPnAUtY2W0vzYDqGHgHH9SnLnv Qjxg== 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=MPc3o5DgmtnCQMaUu6A0rWLfpErutk7ioykzg6PwRno=; b=puuf6hVh/cUonoVk15rxhgzjhoG0cepBRb49VmX6LNd6qOpDTYwggMjsynm+PwNPQh 0zgT68+1nzKtuEbwtWAllUjcaQP710q1mHPJCxV7CtQ2bJm61mLJrIjelWjQP60V9AIe +lCt/F8cQ1mcXnSXjjuvtkjZTetOu06d3/HVlm5nYlDRhbOezmDBYh0za/zYDH7uQRIs XKLegwZ1f1ooVs0oYh64PicYq2lkPaz9wHhvgzUybqv1nuVNKv1cijzdZD0I3UdenM/W 65V0+CBPgwSUF8GHqRW3W1jsPxxisMPu2fBu/4OdhRM+qkYyGaMQKsl1g7NcYkS0Wuer 1HMg== X-Gm-Message-State: APjAAAUR2irFLXC+Hm6Tgl6vrbIXOe/SRBvXWrlLkIQtLfrYwf4g/c2Q B15Crncg5JWIBBAj3njfZyJZaPqRHyJtOg1IDR71ZQ== X-Google-Smtp-Source: APXvYqycVXGk1MQtAM1aHZVkb3OvQ4pq1EVzvrjeYjGtgQx6JehuYVXKOV9JrPufpDW78+D3YOR3vDZXbUxwq2LYcEQ= X-Received: by 2002:a05:620a:102e:: with SMTP id a14mr65974833qkk.159.1577997550071; Thu, 02 Jan 2020 12:39:10 -0800 (PST) MIME-Version: 1.0 References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> In-Reply-To: <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> From: Richard Barnes Date: Thu, 2 Jan 2020 15:38:53 -0500 Message-ID: To: Benjamin Beurdouche Cc: Jon Callas , Michael Rosenberg , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006dc22a059b2e2fd8" Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 02 Jan 2020 20:39:13 -0000 --0000000000006dc22a059b2e2fd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, Resurrecting this thread, as it seems that we never came to resolution on this question. I'd like to propose we scope down and solve a narrower problem, namely the problem of enabling forks in the group's history. So we're not going to try to provide any privacy properties, just remove the impediment to forking. This seems like a worthwhile thing to me just because it seems silly to have forking blocked just because of syntactic constraint, in addition to it likely being necessary for some decentralized use cases (e.g., Matrix). To allow forks, we really just need some "tie breaker" bits in the epoch ID so that if a given epoch has multiple successors, they end up with different epoch IDs. And in order to avoid synchronization, each participant needs to be able to generate those bits independently. There are a couple of basic questions about how to construct the tie breaker: 1. Pseudorandom or not? - Not-pseudorandom example: tiebreaker =3D commitSenderID - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) - Not-pseudorandom implies some assumptions, e.g., that each sender would only send one Commit on top of each epoch - Pseudorandom risks random collisions - Possible to do both: tiebreaker =3D commitSenderID || H(MLSPlaintext(Commit)) 2. How many bits? On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > > > On Apr 26, 2019, at 9:26 PM, Jon Callas wrote: > > > >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg > wrote: > >> > >> So why not remove epoch entirely? > > > > An epoch lets you deal with things happening neither too often nor not > often enough. Presume there is a client that is either malicious or just > stupid. You want to keep it from forcing a rekey every 100=C2=B5s. You wa= nt to > force a rekey every so often. Hence epochs. Yeah, picking the right epoch > size is an exercise left to the reader. > > You can=E2=80=99t use the epoch number for that as it is just global coun= ter for > group operations, we will have to keep track of the latest group operatio= n > =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to che= ck =E2=80=9Cupdate > frequency=E2=80=9D and handle some of the situations you described. > > Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I fee= l > like having more than 2^32 group operations over the lifetime of a group = is > not unrealistic in certain extreme use cases, especially with large group= s > forcing PCS for application messages by triggering an update after each a= pp > message... > > We could remove the epoch number if we really want but it is necessary to > give the Delivery Service some ordering information (unpredictable or not > is an interesting question) to handle concurrent handshake messages which > is, I believe, the main current goal of that information. > > Benjamin > --0000000000006dc22a059b2e2fd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Resurrecting this t= hread, as it seems that we never came to resolution on this question.

I'd like to propose we scope down and solve a n= arrower problem, namely the problem of enabling forks in the group's hi= story.=C2=A0 So we're not going to try to provide any privacy propertie= s, just remove the impediment to forking.=C2=A0 This seems like a worthwhil= e thing to me just because it seems silly to have forking blocked just beca= use of syntactic constraint, in addition to it likely being necessary for s= ome decentralized use cases (e.g., Matrix).

To all= ow forks, we really just need some "tie breaker" bits in the epoc= h ID so that if a given epoch has multiple successors, they end up with dif= ferent epoch IDs.=C2=A0 And in order to avoid synchronization, each partici= pant needs to be able to generate those bits independently.=C2=A0 There are= a couple of basic questions about how to construct the tie breaker:
<= div>
1. Pseudorandom or not?
=C2=A0 - Not-pseudoran= dom example: tiebreaker =3D commitSenderID
=C2=A0 - Pseudoran= dom example: tiebreaker =3D H(MLSPlaintext(Commit))
=C2=A0 - Not-= pseudorandom implies some assumptions, e.g., that each sender would only se= nd one Commit on top of each epoch
=C2=A0 - Pseudorandom risks ra= ndom collisions
=C2=A0 - Possible to do both: tiebreaker =3D comm= itSenderID || H(MLSPlaintext(Commit))

2. How many = bits?





On F= ri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:<= br> >>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor not= often enough. Presume there is a client that is either malicious or just s= tupid. You want to keep it from forcing a rekey every 100=C2=B5s. You want = to force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global counte= r for group operations, we will have to keep track of the latest group oper= ation =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to= check =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations= you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel = like having more than 2^32 group operations over the lifetime of a group is= not unrealistic in certain extreme use cases, especially with large groups= forcing PCS for application messages by triggering an update after each ap= p message...

We could remove the epoch number if we really want but it is necessary to g= ive the Delivery Service some ordering information (unpredictable or not is= an interesting question) to handle concurrent handshake messages which is,= I believe, the main current goal of that information.

Benjamin
--0000000000006dc22a059b2e2fd8-- From nobody Thu Jan 2 12:52:44 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 4EA2712013F for ; Thu, 2 Jan 2020 12:52:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y2_FsaGT_aDK for ; Thu, 2 Jan 2020 12:52:40 -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 D5CBC12004D for ; Thu, 2 Jan 2020 12:52:39 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id t3so35501558qtr.11 for ; Thu, 02 Jan 2020 12:52:39 -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=HbqJDpCrgh62jGuVK2ThdRv/qL3SX7PYhUQcFJpL514=; b=TGhoKFOw6EUpiQqf26e5upNdU3mRnAQoA6juajvQ2T8fuewOXJV2Phsp9UZ5QsPvzp xLXSOgAWqR6w2T3Bm5uwjSGKhAboOdxWq8whidttsidTNIGtUrrCkvwFwV+w3b9gLuXp q3TIJDjlLAuJqdvBWAp5Fz8H38oux2xdCb0VJCzIfLACBPFXG2/UJW5xlgTMO0Y/xkI9 QJaTf1xVzxkzPal1N2J/c0NAYjJ0YNRqqacwAitbAsYhQne0NUbyZdIqRh3SNpmTfjsK dop4hL0l/nG4UoEiGCtuDvgrYgfWTHP6imG+kqOHnkaAfl2dUj2aF83kidZJiwBQGrzU E2Dg== 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=HbqJDpCrgh62jGuVK2ThdRv/qL3SX7PYhUQcFJpL514=; b=Q9x7kFLi7kziAYq4wdxCSAa2myxISroU9yf413xaDk2QZl5GZ2ft691S1xiYKLi1Rr J5+C0w9lz7pL3cKw6nS3pY4G4yJ7j6/rkI4noL2HUZfpA1t/PkIygjQlENnx4q/rlc+e ZJwnS24rqR4O9T5q81Ov0070bHHZFbnmEwtfvHSXmaRBonQs5OxyPx+XXREw8SOyXVmE FNbESaP7qw+iC1TQlUCZR3yF9Do+wy8Z0NnpR40+ULxviiP1E6ZkXTxEGCXYgcQz30Xy JFoBj0a6KTbMoMsrO/jSnhYtkZcCM3u1NWMJegSHGFqFo9WQKYBJp6YbXC5jjWTV9HoT yuVw== X-Gm-Message-State: APjAAAWN6rMQoXC6caVo92MkBvVPTtZr2ipwOdq2vm4D0/CU9W3CwISV raF1d/TIeIfoCUgIojni8CYNUXJyDu9Mu5lWUzFN/Q== X-Google-Smtp-Source: APXvYqzQbO7Uch9RnX3Ho351OpsNSS5JOhLrr3qNeoI4adnhnZInKiW0q3NVQBZ7uZrrrqKUKcTqkkCePbO8IIITW+0= X-Received: by 2002:ac8:b43:: with SMTP id m3mr60611412qti.191.1577998358957; Thu, 02 Jan 2020 12:52:38 -0800 (PST) MIME-Version: 1.0 References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> In-Reply-To: From: Richard Barnes Date: Thu, 2 Jan 2020 15:52:22 -0500 Message-ID: To: Benjamin Beurdouche Cc: Jon Callas , Michael Rosenberg , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000a45ca8059b2e5f45" Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 02 Jan 2020 20:52:42 -0000 --000000000000a45ca8059b2e5f45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Argh, hit send too soon. Continuing below... On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes wrote: > Hey all, > > Resurrecting this thread, as it seems that we never came to resolution on > this question. > > I'd like to propose we scope down and solve a narrower problem, namely th= e > problem of enabling forks in the group's history. So we're not going to > try to provide any privacy properties, just remove the impediment to > forking. This seems like a worthwhile thing to me just because it seems > silly to have forking blocked just because of syntactic constraint, in > addition to it likely being necessary for some decentralized use cases > (e.g., Matrix). > > To allow forks, we really just need some "tie breaker" bits in the epoch > ID so that if a given epoch has multiple successors, they end up with > different epoch IDs. And in order to avoid synchronization, each > participant needs to be able to generate those bits independently. There > are a couple of basic questions about how to construct the tie breaker: > > 1. Pseudorandom or not? > - Not-pseudorandom example: tiebreaker =3D commitSenderID > - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) > - Not-pseudorandom implies some assumptions, e.g., that each sender > would only send one Commit on top of each epoch > - Pseudorandom risks random collisions > - Possible to do both: tiebreaker =3D commitSenderID || > H(MLSPlaintext(Commit)) > > 2. How many bits of tiebreaker? > - Non-pseudorandom size will be dictated by what we include - Pseudorandom size will be dictated by tolerable collision probability - Probability of collision ~ (number of forks per seq no) / 2^{number of bits} 3. How many bits of sequence number? - DS might want to see sequence to help enforce ordering - Probably want this big enough to avoid wrapping. (Note that this is a value that goes in every message, so there's some incentive to keep things small.) Personally, my proposal would be something like: struct { uint64 sequence_number; uint64 commit_hash; // H(MLSPlaintext(Commit)) } EpochID; That seems to strike a reasonable balance between low collision probability (~2^-64) and a reasonably small identifier. If 128 bits is good enough for IPv6, it can be good enough for us :) Does that seem workable to folks? --Richard > > > > > > On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > >> >> > On Apr 26, 2019, at 9:26 PM, Jon Callas wrote: >> > >> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg >> wrote: >> >> >> >> So why not remove epoch entirely? >> > >> > An epoch lets you deal with things happening neither too often nor not >> often enough. Presume there is a client that is either malicious or just >> stupid. You want to keep it from forcing a rekey every 100=C2=B5s. You w= ant to >> force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h >> size is an exercise left to the reader. >> >> You can=E2=80=99t use the epoch number for that as it is just global cou= nter for >> group operations, we will have to keep track of the latest group operati= on >> =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to ch= eck =E2=80=9Cupdate >> frequency=E2=80=9D and handle some of the situations you described. >> >> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I >> feel like having more than 2^32 group operations over the lifetime of a >> group is not unrealistic in certain extreme use cases, especially with >> large groups forcing PCS for application messages by triggering an updat= e >> after each app message... >> >> We could remove the epoch number if we really want but it is necessary t= o >> give the Delivery Service some ordering information (unpredictable or no= t >> is an interesting question) to handle concurrent handshake messages whic= h >> is, I believe, the main current goal of that information. >> >> Benjamin >> > --000000000000a45ca8059b2e5f45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Argh, hit send too soon.=C2=A0 Continuing= below...

On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.sx&g= t; wrote:
Hey all,

Resurrecting this thread,= as it seems that we never came to resolution on this question.

I'd like to propose we scope down and solve a narrowe= r problem, namely the problem of enabling forks in the group's history.= =C2=A0 So we're not going to try to provide any privacy properties, jus= t remove the impediment to forking.=C2=A0 This seems like a worthwhile thin= g to me just because it seems silly to have forking blocked just because of= syntactic constraint, in addition to it likely being necessary for some de= centralized use cases (e.g., Matrix).

To allow for= ks, we really just need some "tie breaker" bits in the epoch ID s= o that if a given epoch has multiple successors, they end up with different= epoch IDs.=C2=A0 And in order to avoid synchronization, each participant n= eeds to be able to generate those bits independently.=C2=A0 There are a cou= ple of basic questions about how to construct the tie breaker:
1. Pseudorandom or not?
=C2=A0 - Not-pseudorandom ex= ample: tiebreaker =3D commitSenderID
=C2=A0 - Pseudorandom ex= ample: tiebreaker =3D H(MLSPlaintext(Commit))
=C2=A0 - Not-pseudo= random implies some assumptions, e.g., that each sender would only send one= Commit on top of each epoch
=C2=A0 - Pseudorandom risks random c= ollisions
=C2=A0 - Possible to do both: tiebreaker =3D commitSend= erID || H(MLSPlaintext(Commit))

2. How many bits o= f tiebreaker?
=C2=A0 - Non-pseudorandom size w= ill be dictated by what we include
=C2=A0 - Pseudorandom size wil= l be dictated by tolerable collision probability
=C2=A0 - Probabi= lity of collision ~ (number of forks per seq no) / 2^{number of bits}
=

3. How many bits of sequence number?
- DS mig= ht want to see sequence to help enforce ordering
- Probably want = this big enough to avoid wrapping.

(Note that = this is a value that goes in every message, so there's some incentive t= o keep things small.)

Personally, my proposal = would be something like:

struct {
= =C2=A0 uint64 sequence_number;
=C2=A0 uint64 commit_hash; // H(ML= SPlaintext(Commit))
} EpochID;

T= hat seems to strike a reasonable balance between low collision probability = (~2^-64) and a reasonably small identifier.=C2=A0 If 128 bits is good enoug= h for IPv6, it can be good enough for us :)

Does t= hat seem workable to folks?

--Richard
=C2=A0
=





On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche <benjamin.beurdouche@inria.= fr> wrote:
jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:<= br> >>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor not= often enough. Presume there is a client that is either malicious or just s= tupid. You want to keep it from forcing a rekey every 100=C2=B5s. You want = to force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global counte= r for group operations, we will have to keep track of the latest group oper= ation =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to= check =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations= you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel = like having more than 2^32 group operations over the lifetime of a group is= not unrealistic in certain extreme use cases, especially with large groups= forcing PCS for application messages by triggering an update after each ap= p message...

We could remove the epoch number if we really want but it is necessary to g= ive the Delivery Service some ordering information (unpredictable or not is= an interesting question) to handle concurrent handshake messages which is,= I believe, the main current goal of that information.

Benjamin
--000000000000a45ca8059b2e5f45-- From nobody Thu Jan 2 15:16: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 527B01207FB for ; Thu, 2 Jan 2020 15:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Jl05fD05i2WT for ; Thu, 2 Jan 2020 15:16:01 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 3000F120096 for ; Thu, 2 Jan 2020 15:16:01 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id c7so11158059uaf.5 for ; Thu, 02 Jan 2020 15:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bNYwrOckHYX++oUalrmqDi9oIZIA7i/p7xzJrsnZzDY=; b=iuQr1GBfPDUFwa92CZE2oVKs0fUVpHCuuPvXIgFj6cbeTmiz7qe/rCW06yEncAoIuB 1qU5cU8MQ953MQumIn1DLpzj+YKo4wdei5c0tgZKG4RL7lnzZDw4EFQJath3GeZtLd52 sEb3RjoKBxxIZyq25TCbmyZ3PwKj3NTX+5uh721yKObVMIVrFY8Xc6M3UEiJgsfev/tb O4XAge8uPRNpSBm8azDIcMPrxuycjpQxU9qJHuFDViLZ/DlBk9YYQiObuta2kbgEH2PJ TuTIT6J0H01RLkz7yHfJuc0BvrtWmc6ic2lAmtCBMMyGphed7ryFjFVzXB0cckmf+Geb cBJQ== 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=bNYwrOckHYX++oUalrmqDi9oIZIA7i/p7xzJrsnZzDY=; b=EVLjl3z8sQgsK5k2kb8920uGGXBgfUeKoO0JvlOQ7NVlNizzLvMoPlz/ZXRGZhY1HT tLOLPuyChbTXYBwCwpvjxpTdWVQLg27J/4gf5ZyPAb53y+qaN+VZE2t9MADuFY2o75Nm qhBwyGiSGdmQsyMGDLRd51PbDbL082X/6j5c86GScBgzXfG3tkLOyGa78+mrytVvcUHg GTwMXv6PK+l1QARdY71M35E5ZJutwEC/m1TD/A+egSGUn0QRv1L/u7TR+Yto5aW/dXl7 17PeLq2VjxRfD6rluSO0IYUHqZmtK/NCMIOBRfZfymWwXLhITi0NNkZWto/oSgeshQA0 6seg== X-Gm-Message-State: APjAAAXI2YFeBjUr4pDjoOu3C07MrxcV8M/cXxo7THN8B/b14G4yXLGw AilqgvPPwaAZsLEU0sJpD11rAPtKEthxb8pUIWBYqA== X-Google-Smtp-Source: APXvYqy61EASS/vQpJaChGTpeY0M2jKRzU63CQS+IBdvPheQqt9aqEPL+8iWEnyhrKkKFdOEsBpjzk2YTuh/r7tvm6c= X-Received: by 2002:ab0:6505:: with SMTP id w5mr22190924uam.125.1578006960030; Thu, 02 Jan 2020 15:16:00 -0800 (PST) MIME-Version: 1.0 References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> In-Reply-To: From: Kelvin Ritland Date: Thu, 2 Jan 2020 15:15:48 -0800 Message-ID: To: Richard Barnes Cc: Benjamin Beurdouche , Michael Rosenberg , Messaging Layer Security WG , Jon Callas Content-Type: multipart/alternative; boundary="0000000000004ea4ca059b30604a" Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 02 Jan 2020 23:16:08 -0000 --0000000000004ea4ca059b30604a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Not-pseudorandom implies some assumptions, e.g., that each sender would > only send one Commit on top of each epoch This isn't bad imo, it reduces complexity to some extent. I'm somewhat in favour of a non-pseudorandom tiebreaker if there's no other arguments against it. How many bits of sequence number? Have we considered using varints? Similar to the CTLS proposal - https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1 Other forking considerations, I think there's more involved than just changing the epoch identifier: 1. We'll need merges as well, since forks can lead to inconsistent group membership: Suppose in epoch 1 a group has A, B, and C A removes C in epoch 2A B adds D in epoch 2B We now have two group states 2A with AB and 2B with ABCD - and it's unclear which group to use to send with. We could mandate that any client MUST send a "merge" commit on it's view of history before sending any message. This commit could just be the list of epochs that are being merged (+a usual DirectPath update?), and processing it would mean replaying all proposals up to the common ancestor for those epochs on the common ancestor. 2. Forward secrecy issues. By allowing forks, devices must now keep the previous epoch around to derive possible future forks - but this means we'll be re-using init_secret_. A possible solution could be to use the nth app secret from the ASTree instead of init_secret_ as the start for the new epoch secret. This ties nicely with using a non-pseudorandom tiebreaker. 3. Ordering implications It's unclear what a sensible ordering strategy is for the DS if we allow forking. (simply ensuring that each commit is based on the "current" epoch isn't well defined since there can be multiple "current" epochs). By allowing forks the DS need not enforce ordering at all imo. This means that apps need to keep around old epochs, but this is already required per (2). A different question is how many we need to keep around - perhaps a TTL or the past N epochs after a topological sort would make sense. Generally I think getting rid of server ordering is good idea: - Helps Matrix and general federation use cases - A common consistent mutated state for group operations can cause server side DB contention in my experience Forks is one way to remove ordering, and if we need to support it anyways it's a nice benefit. On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes wrote: > Argh, hit send too soon. Continuing below... > > On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes wrote: > >> Hey all, >> >> Resurrecting this thread, as it seems that we never came to resolution o= n >> this question. >> >> I'd like to propose we scope down and solve a narrower problem, namely >> the problem of enabling forks in the group's history. So we're not goin= g >> to try to provide any privacy properties, just remove the impediment to >> forking. This seems like a worthwhile thing to me just because it seems >> silly to have forking blocked just because of syntactic constraint, in >> addition to it likely being necessary for some decentralized use cases >> (e.g., Matrix). >> >> To allow forks, we really just need some "tie breaker" bits in the epoch >> ID so that if a given epoch has multiple successors, they end up with >> different epoch IDs. And in order to avoid synchronization, each >> participant needs to be able to generate those bits independently. Ther= e >> are a couple of basic questions about how to construct the tie breaker: >> >> 1. Pseudorandom or not? >> - Not-pseudorandom example: tiebreaker =3D commitSenderID >> - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) >> - Not-pseudorandom implies some assumptions, e.g., that each sender >> would only send one Commit on top of each epoch >> - Pseudorandom risks random collisions >> - Possible to do both: tiebreaker =3D commitSenderID || >> H(MLSPlaintext(Commit)) >> >> 2. How many bits of tiebreaker? >> > - Non-pseudorandom size will be dictated by what we include > - Pseudorandom size will be dictated by tolerable collision probability > - Probability of collision ~ (number of forks per seq no) / 2^{number o= f > bits} > > 3. How many bits of sequence number? > - DS might want to see sequence to help enforce ordering > - Probably want this big enough to avoid wrapping. > > (Note that this is a value that goes in every message, so there's some > incentive to keep things small.) > > Personally, my proposal would be something like: > > struct { > uint64 sequence_number; > uint64 commit_hash; // H(MLSPlaintext(Commit)) > } EpochID; > > That seems to strike a reasonable balance between low collision > probability (~2^-64) and a reasonably small identifier. If 128 bits is > good enough for IPv6, it can be good enough for us :) > > Does that seem workable to folks? > > --Richard > > > >> >> >> >> >> >> On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche < >> benjamin.beurdouche@inria.fr> wrote: >> >>> >>> > On Apr 26, 2019, at 9:26 PM, Jon Callas wrote: >>> > >>> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg >>> wrote: >>> >> >>> >> So why not remove epoch entirely? >>> > >>> > An epoch lets you deal with things happening neither too often nor no= t >>> often enough. Presume there is a client that is either malicious or jus= t >>> stupid. You want to keep it from forcing a rekey every 100=C2=B5s. You = want to >>> force a rekey every so often. Hence epochs. Yeah, picking the right epo= ch >>> size is an exercise left to the reader. >>> >>> You can=E2=80=99t use the epoch number for that as it is just global co= unter for >>> group operations, we will have to keep track of the latest group operat= ion >>> =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to c= heck =E2=80=9Cupdate >>> frequency=E2=80=9D and handle some of the situations you described. >>> >>> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I >>> feel like having more than 2^32 group operations over the lifetime of a >>> group is not unrealistic in certain extreme use cases, especially with >>> large groups forcing PCS for application messages by triggering an upda= te >>> after each app message... >>> >>> We could remove the epoch number if we really want but it is necessary >>> to give the Delivery Service some ordering information (unpredictable o= r >>> not is an interesting question) to handle concurrent handshake messages >>> which is, I believe, the main current goal of that information. >>> >>> Benjamin >>> >> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000004ea4ca059b30604a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How many bits of sequence number?
Have we considered usin= g varints? Similar to the CTLS proposal - http= s://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1


Other forking considerat= ions, I think there's more involved than just changing the epoch identi= fier:

1. We'll need merges as well, sinc= e forks can lead to inconsistent group membership:
Suppose i= n epoch 1 a=C2=A0group has A, B, and C
A removes C in epoch 2A
B adds D in epoch 2B

We now have two group= states 2A with AB and 2B with ABCD - and it's unclear which group to u= se to send with. We could mandate that any client MUST send a "merge&q= uot; commit on it's view of history before sending any message. This co= mmit could just be the list of epochs that are being merged (+a usual Dire= ctPath update?), and processing it would mean replaying all proposals up to= the common ancestor for those epochs on the common ancestor.

2. Forward secrecy issues.
By allowing forks, devices must now keep the previous epoch around to der= ive possible future forks - but this means we'll be re-using init_secre= t_. A possible solution could be to use the nth app secret from the ASTree = instead of init_secret_ as the start=C2=A0for the new epoch secret. This ti= es nicely with using a non-pseudorandom=C2=A0tiebreaker.

=
3. Ordering implications
It's unclear what a sensi= ble ordering strategy is for the DS if we allow forking. (simply ensuring t= hat each commit is based on the "current" epoch isn't well de= fined since there can be multiple "current" epochs).
By allowing forks the DS=C2=A0need=C2=A0not=C2=A0enforce order= ing at all imo. This means that apps need to keep around old epochs, but th= is is already required=C2=A0per (2). A different question is how many we ne= ed to keep around - perhaps a TTL or the past N epochs after a topological = sort would make sense.

Generally I think getting r= id of server ordering is good idea:
- Helps Matrix and general fe= deration use cases
- A common consistent mutated state for group = operations can cause server side DB contention in my experience
<= br>
Forks is one way to remove ordering, and if we need to suppor= t it anyways it's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes <rlb= @ipv.sx> wrote:
Argh, hit send too soon.=C2=A0 Continu= ing below...

On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.s= x> wrote:
Hey all,

Resurrecting this thre= ad, as it seems that we never came to resolution on this question.

I'd like to propose we scope down and solve a narr= ower problem, namely the problem of enabling forks in the group's histo= ry.=C2=A0 So we're not going to try to provide any privacy properties, = just remove the impediment to forking.=C2=A0 This seems like a worthwhile t= hing to me just because it seems silly to have forking blocked just because= of syntactic constraint, in addition to it likely being necessary for some= decentralized use cases (e.g., Matrix).

To allow = forks, we really just need some "tie breaker" bits in the epoch I= D so that if a given epoch has multiple successors, they end up with differ= ent epoch IDs.=C2=A0 And in order to avoid synchronization, each participan= t needs to be able to generate those bits independently.=C2=A0 There are a = couple of basic questions about how to construct the tie breaker:

1. Pseudorandom or not?
=C2=A0 - Not-pseudorandom= example: tiebreaker =3D commitSenderID
=C2=A0 - Pseudorandom= example: tiebreaker =3D H(MLSPlaintext(Commit))
=C2=A0 - Not-pse= udorandom implies some assumptions, e.g., that each sender would only send = one Commit on top of each epoch
=C2=A0 - Pseudorandom risks rando= m collisions
=C2=A0 - Possible to do both: tiebreaker =3D commitS= enderID || H(MLSPlaintext(Commit))

2. How many bit= s of tiebreaker?
=C2=A0 - Non-pseudorandom siz= e will be dictated by what we include
=C2=A0 - Pseudorandom size = will be dictated by tolerable collision probability
=C2=A0 - Prob= ability of collision ~ (number of forks per seq no) / 2^{number of bits}

3. How many bits of sequence number?
- DS = might want to see sequence to help enforce ordering
- Probably wa= nt this big enough to avoid wrapping.

(Note th= at this is a value that goes in every message, so there's some incentiv= e to keep things small.)

Personally, my propos= al would be something like:

struct {
=C2=A0 uint64 sequence_number;
=C2=A0 uint64 commit_hash; // H(M= LSPlaintext(Commit))
} EpochID;

= That seems to strike a reasonable balance between low collision probability= (~2^-64) and a reasonably small identifier.=C2=A0 If 128 bits is good enou= gh for IPv6, it can be good enough for us :)

Does = that seem workable to folks?

--Richard
<= br>
=C2=A0





On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche <benjamin.beurdouche@inria= .fr> wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:<= br> >>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor not= often enough. Presume there is a client that is either malicious or just s= tupid. You want to keep it from forcing a rekey every 100=C2=B5s. You want = to force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global counte= r for group operations, we will have to keep track of the latest group oper= ation =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to= check =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations= you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel = like having more than 2^32 group operations over the lifetime of a group is= not unrealistic in certain extreme use cases, especially with large groups= forcing PCS for application messages by triggering an update after each ap= p message...

We could remove the epoch number if we really want but it is necessary to g= ive the Delivery Service some ordering information (unpredictable or not is= an interesting question) to handle concurrent handshake messages which is,= I believe, the main current goal of that information.

Benjamin
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000004ea4ca059b30604a-- From nobody Fri Jan 3 07:32:33 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 E6E5912004F for ; Fri, 3 Jan 2020 07:32:31 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 (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 dcCFdE218Ryd for ; Fri, 3 Jan 2020 07:32:28 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1496012000F for ; Fri, 3 Jan 2020 07:32:28 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id m26so41788217ljc.13 for ; Fri, 03 Jan 2020 07:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sYOblLcihSPdJO0dl5yuoQ+nu8UWOlD8wSeRaJVwx4c=; b=i5xROw5kmdDusIuVEldgLfZUzkgV14s82uvlJUp4muTWWKUlyzPxkOrCtOFzu9cFR2 RIWiYC0voLoXqqSICZjo16wqrxLf48O/HYPDy+eVdurIkXh5OGEKuKkY7K4EC2/AgY/B ZW1gjmZHpjqE1S51NA89MJhq6FC+DyrhB1ZZYzrGOwDxq/5Tg1yfhHG4vpVTAsRmgdk9 hPQ2l9aX5c5J14ns6x9/S0ZCQWyAao4UYDGnTGcM5+XkCFLxh1O8AQfmq3OP7dYP0l/5 EbVdUUqPp+rhSxF54zlQg7q7AtbLoa84DvnMujOXFU/ZeCCReuMbK4q5uXMbNtDx6bXd ycfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sYOblLcihSPdJO0dl5yuoQ+nu8UWOlD8wSeRaJVwx4c=; b=d35fsA8YBhHziotmjl1rPBHQRA1zJGH8OPW+lEfOr5G7rt9KcnXxuBJuvhzD+A6Ifn EzTOYR0CWadIHCo+vK+TSm8DKLKCg6ZI9kHN/VddA7JJ6BiCd2/0JP/LZvAA7QjphWqC hJZSZQYd7tGy0Q2QWYVaEYNW47OYaabcvCZGgNTiEHOQP+yz2fCasiLoUssvysUTsANk RM2KYiEK8+pFScKuXSB1m4bjKtN/TT+ZPaM7rgewa8f/G85LnMYQk2/S8D4oSSroDSvl /ol54cep4tFALqC2U79qzhBQXIZfXcNhdAZYHD9uZm10TfWrw6IbQVZpBe289UQgZqSe cvaA== X-Gm-Message-State: APjAAAWqNwhKbGQPc8vOpUYHN1q5ALrkDY6jZHgl9+DmNQx+zP0FwWW4 BQ56xg5eWpGvvoanE2ZjzRix/w== X-Google-Smtp-Source: APXvYqxgnJOo0SLZ+kT+Rziz1i/DrVbnomcl6gMVPbVlLF2q6FHfHDjUl6Bs/ImLMlq58brlDpVjDQ== X-Received: by 2002:a2e:8745:: with SMTP id q5mr53417376ljj.208.1578065545998; Fri, 03 Jan 2020 07:32:25 -0800 (PST) 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 a14sm24786635lfh.50.2020.01.03.07.32.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 07:32:24 -0800 (PST) From: Raphael Robert Message-Id: <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_48F2E490-D5AE-4BE9-8CA3-C62B5CBCC9FD" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Fri, 3 Jan 2020 16:32:23 +0100 In-Reply-To: Cc: Richard Barnes , Michael Rosenberg , Messaging Layer Security WG , Benjamin Beurdouche , Jon Callas To: Kelvin Ritland References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 03 Jan 2020 15:32:32 -0000 --Apple-Mail=_48F2E490-D5AE-4BE9-8CA3-C62B5CBCC9FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Kelvin=E2=80=99s points in general. Allowing forks might be = an interesting goal, but it raises a wealth of new questions. On the other hand I think Richard=E2=80=99s proposal of extending the = Epoch ID with a commit hash makes sense to detect potential forks. I=E2=80=99d like to propose that we adopt that as a first step, but only = in the context of fork detection for now. This doesn=E2=80=99t preclude = us from building on top of that in the future, but we also don=E2=80=99t = introduce something dangerous right now. Raphael > On 3 Jan 2020, at 00:15, Kelvin Ritland = wrote: >=20 > Not-pseudorandom implies some assumptions, e.g., that each sender = would only send one Commit on top of each epoch > This isn't bad imo, it reduces complexity to some extent. I'm somewhat = in favour of a non-pseudorandom tiebreaker if there's no other arguments = against it. >=20 > How many bits of sequence number? > Have we considered using varints? Similar to the CTLS proposal - = https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1 = >=20 >=20 > Other forking considerations, I think there's more involved than just = changing the epoch identifier: >=20 > 1. We'll need merges as well, since forks can lead to inconsistent = group membership: > Suppose in epoch 1 a group has A, B, and C > A removes C in epoch 2A > B adds D in epoch 2B >=20 > We now have two group states 2A with AB and 2B with ABCD - and it's = unclear which group to use to send with. We could mandate that any = client MUST send a "merge" commit on it's view of history before sending = any message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor. >=20 > 2. Forward secrecy issues. > By allowing forks, devices must now keep the previous epoch around to = derive possible future forks - but this means we'll be re-using = init_secret_. A possible solution could be to use the nth app secret = from the ASTree instead of init_secret_ as the start for the new epoch = secret. This ties nicely with using a non-pseudorandom tiebreaker. >=20 > 3. Ordering implications > It's unclear what a sensible ordering strategy is for the DS if we = allow forking. (simply ensuring that each commit is based on the = "current" epoch isn't well defined since there can be multiple "current" = epochs). >=20 > By allowing forks the DS need not enforce ordering at all imo. This = means that apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense. >=20 > Generally I think getting rid of server ordering is good idea: > - Helps Matrix and general federation use cases > - A common consistent mutated state for group operations can cause = server side DB contention in my experience >=20 > Forks is one way to remove ordering, and if we need to support it = anyways it's a nice benefit. >=20 > On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes wrote: > Argh, hit send too soon. Continuing below... >=20 > On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes wrote: > Hey all, >=20 > Resurrecting this thread, as it seems that we never came to resolution = on this question. >=20 > I'd like to propose we scope down and solve a narrower problem, namely = the problem of enabling forks in the group's history. So we're not = going to try to provide any privacy properties, just remove the = impediment to forking. This seems like a worthwhile thing to me just = because it seems silly to have forking blocked just because of syntactic = constraint, in addition to it likely being necessary for some = decentralized use cases (e.g., Matrix). >=20 > To allow forks, we really just need some "tie breaker" bits in the = epoch ID so that if a given epoch has multiple successors, they end up = with different epoch IDs. And in order to avoid synchronization, each = participant needs to be able to generate those bits independently. = There are a couple of basic questions about how to construct the tie = breaker: >=20 > 1. Pseudorandom or not? > - Not-pseudorandom example: tiebreaker =3D commitSenderID > - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) > - Not-pseudorandom implies some assumptions, e.g., that each sender = would only send one Commit on top of each epoch > - Pseudorandom risks random collisions > - Possible to do both: tiebreaker =3D commitSenderID || = H(MLSPlaintext(Commit)) >=20 > 2. How many bits of tiebreaker? > - Non-pseudorandom size will be dictated by what we include > - Pseudorandom size will be dictated by tolerable collision = probability > - Probability of collision ~ (number of forks per seq no) / = 2^{number of bits} >=20 > 3. How many bits of sequence number? > - DS might want to see sequence to help enforce ordering > - Probably want this big enough to avoid wrapping. >=20 > (Note that this is a value that goes in every message, so there's some = incentive to keep things small.) >=20 > Personally, my proposal would be something like: >=20 > struct { > uint64 sequence_number; > uint64 commit_hash; // H(MLSPlaintext(Commit)) > } EpochID; >=20 > That seems to strike a reasonable balance between low collision = probability (~2^-64) and a reasonably small identifier. If 128 bits is = good enough for IPv6, it can be good enough for us :) >=20 > Does that seem workable to folks? >=20 > --Richard >=20 > =20 >=20 >=20 >=20 >=20 >=20 > On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche = > = wrote: >=20 > > On Apr 26, 2019, at 9:26 PM, Jon Callas > wrote: > >=20 > >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg > wrote: > >>=20 > >> So why not remove epoch entirely? > >=20 > > An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader. >=20 > You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described. >=20 > Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I = feel like having more than 2^32 group operations over the lifetime of a = group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message... >=20 > We could remove the epoch number if we really want but it is necessary = to give the Delivery Service some ordering information (unpredictable or = not is an interesting question) to handle concurrent handshake messages = which is, I believe, the main current goal of that information. >=20 > Benjamin > _______________________________________________ > 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 --Apple-Mail=_48F2E490-D5AE-4BE9-8CA3-C62B5CBCC9FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Kelvin=E2=80=99s points in general. Allowing forks might be = an interesting goal, but it raises a wealth of new questions.
On the other hand I think Richard=E2=80=99s proposal of = extending the Epoch ID with a commit hash makes sense to detect = potential forks.

I=E2=80=99d like to propose that we adopt that as a first = step, but only in the context of fork detection for now. This doesn=E2=80=99= t preclude us from building on top of that in the future, but we also = don=E2=80=99t introduce something dangerous right now.

Raphael

On 3 Jan 2020, at 00:15, Kelvin Ritland <kelvinr=3D40google.com@dmarc.ietf.org> wrote:

Not-pseudorandom implies some = assumptions, e.g., that each sender would only send one Commit on top of = each epoch
This isn't bad imo, it reduces = complexity to some extent. I'm somewhat in favour of a non-pseudorandom = tiebreaker if there's no other arguments against it.

How many bits of sequence = number?
Have we considered using varints? = Similar to the CTLS proposal - https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.s= ection.3.1


Other forking = considerations, I think there's more involved than just changing the = epoch identifier:

1. We'll need merges as well, since forks can lead to = inconsistent group membership:
Suppose in epoch 1 a group has A, B, and C
A removes C in epoch 2A
B adds D in = epoch 2B

We = now have two group states 2A with AB and 2B with ABCD - and it's unclear = which group to use to send with. We could mandate that any client MUST = send a "merge" commit on it's view of history before sending any = message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor.

2. Forward secrecy issues.
By allowing = forks, devices must now keep the previous epoch around to derive = possible future forks - but this means we'll be re-using init_secret_. A = possible solution could be to use the nth app secret from the ASTree = instead of init_secret_ as the start for the new epoch secret. This = ties nicely with using a non-pseudorandom tiebreaker.

3. = Ordering implications
It's unclear what a sensible = ordering strategy is for the DS if we allow forking. (simply ensuring = that each commit is based on the "current" epoch isn't well defined = since there can be multiple "current" epochs).

By allowing forks the = DS need not enforce ordering at all imo. This means that = apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense.

Generally I think getting rid of server ordering is good = idea:
- Helps Matrix and general federation use = cases
- A common consistent mutated state for group = operations can cause server side DB contention in my = experience

Forks= is one way to remove ordering, and if we need to support it anyways = it's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes = <rlb@ipv.sx> = wrote:
Argh, hit send too soon.  Continuing = below...

On Thu, Jan = 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

Resurrecting this thread, as it seems that we never came to = resolution on this question.

I'd like to propose we scope down and = solve a narrower problem, namely the problem of enabling forks in the = group's history.  So we're not going to try to provide any privacy = properties, just remove the impediment to forking.  This seems like = a worthwhile thing to me just because it seems silly to have forking = blocked just because of syntactic constraint, in addition to it likely = being necessary for some decentralized use cases (e.g., = Matrix).

To = allow forks, we really just need some "tie breaker" bits in the epoch ID = so that if a given epoch has multiple successors, they end up with = different epoch IDs.  And in order to avoid synchronization, each = participant needs to be able to generate those bits independently.  = There are a couple of basic questions about how to construct the tie = breaker:

1. = Pseudorandom or not?
  - Not-pseudorandom = example: tiebreaker =3D commitSenderID
  - Pseudorandom example: tiebreaker =3D = H(MLSPlaintext(Commit))
  - Not-pseudorandom = implies some assumptions, e.g., that each sender would only send one = Commit on top of each epoch
  - Pseudorandom = risks random collisions
  - Possible to do = both: tiebreaker =3D commitSenderID || H(MLSPlaintext(Commit))

2. How many bits of = tiebreaker?
  - = Non-pseudorandom size will be dictated by what we include
  - Pseudorandom size will be dictated by tolerable = collision probability
  - Probability of = collision ~ (number of forks per seq no) / 2^{number of bits}

3. How many bits of = sequence number?
- DS might want to see sequence to = help enforce ordering
- Probably want this big = enough to avoid wrapping.

(Note that this is a value that goes in = every message, so there's some incentive to keep things small.)

Personally, my proposal would be something like:

struct {
  uint64 = sequence_number;
  uint64 commit_hash; // = H(MLSPlaintext(Commit))
} = EpochID;

That seems to strike a reasonable balance between low = collision probability (~2^-64) and a reasonably small identifier.  = If 128 bits is good enough for IPv6, it can be good enough for us = :)

Does that = seem workable to folks?

--Richard

 





On Fri, Apr 26, 2019 at 4:18 PM = Benjamin Beurdouche <benjamin.beurdouche@inria..fr> = wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:
>>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I = feel like having more than 2^32 group operations over the lifetime of a = group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message...

We could remove the epoch number if we really want but it is necessary = to give the Delivery Service some ordering information (unpredictable or = not is an interesting question) to handle concurrent handshake messages = which is, I believe, the main current goal of that information.

Benjamin
_______________________________________________
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

= --Apple-Mail=_48F2E490-D5AE-4BE9-8CA3-C62B5CBCC9FD-- From nobody Fri Jan 3 08:55:45 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 D006D1200DE for ; Fri, 3 Jan 2020 08:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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] 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 CS16P7quYKv1 for ; Fri, 3 Jan 2020 08:55:39 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 6680C120091 for ; Fri, 3 Jan 2020 08:55:39 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id d18so34578632qtj.10 for ; Fri, 03 Jan 2020 08:55:39 -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=c/4I4qO/Z813fL3KErDp7bYME9KlGvjDeTN43qpqLtc=; b=f4EsCMOcSDQV/I43e5NcfyfTgTz1PWCjkCOBZFihn8aKvFk5xb8aCtgeDzZ362tpam VLQFQKugD5O9JxB6n1wyqTiYfHBZx/zS/A4ShTzChnv0Wp8KIh3sHUOVXcWMd4FHRd/S MtgB98NH5jtrlS4tGecIxbxvfetqPCHol2ai3kjUhrc85hs9Bs7yquGlTF6Svmf1u8Vq R0ZlD9PvzrrTI1WbWofdsQYmYBQeJK3TBBcRBqrADhHs9L6sRkHKti1VcyrOv7LNclb1 2w1y+2L3EnJne53SpSolrAyjeES0ANzwoj+QV1f/tLw9E3cOB1fR/35W/Y0gEj0QmkJ3 i76A== 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=c/4I4qO/Z813fL3KErDp7bYME9KlGvjDeTN43qpqLtc=; b=INkFwwWTRT721PT7SFE/o3S7qupShy5K1T7h6+lkIg0vk3FpQFYQcKfmn71y3XMHr/ rdiuxmNIz9A03EkvwJafK9WnBUMcH0hKltSQtMRmE13bDisTCGkhpKCzAqR+o2KDXVH1 c1BYdm6YJmCTPqKbrazwQve799j7UdleDJdlhZwSTb75hWtRPkbgDzz5xnYEd0PKcsrM Jh3gyhnFIAnP3cY8K56asdFszOgV21kQFTk9SLdvAQ89H0S6YzXeQCyzFOiwBYhlUQ4d bF+nmQIqNqK/XFHgzPQhMtAbxZxPOcASyKav68f2+TNen/DIiPtiKhxFJs0Olc9qMRUn YJMw== X-Gm-Message-State: APjAAAXuT4mQrcUg0hEcOfMfyy4XRxEZdoqcISFIvmqzSkoYt+IJxzTb bzbm9RoSRfd+ICMRdfERMLOsVj7uXl4brip5RVO9Fg== X-Google-Smtp-Source: APXvYqwflmWwF7qJau2ftai+DEEOX+xfY40SjqzLRvfLOD1g5ibcsbagNl2frMqeJ0NcDp19Bxn6qw46wZiB7QPRqM8= X-Received: by 2002:ac8:1e90:: with SMTP id c16mr64804489qtm.265.1578070538489; Fri, 03 Jan 2020 08:55:38 -0800 (PST) MIME-Version: 1.0 References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> In-Reply-To: <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> From: Richard Barnes Date: Fri, 3 Jan 2020 11:55:21 -0500 Message-ID: To: Raphael Robert Cc: Kelvin Ritland , Michael Rosenberg , Messaging Layer Security WG , Benjamin Beurdouche , Jon Callas Content-Type: multipart/alternative; boundary="000000000000e0a98c059b3f2dce" Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 03 Jan 2020 16:55:43 -0000 --000000000000e0a98c059b3f2dce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I'm on the same page here. My objective is to remove the roadblock without trying to solve the whole problem. As Kelvin points out, there's a lot of interesting thinking to be done about how to manage a DAG of state. In chatting with Raphael just now, he proposed a nice framing -- that the tiebreaker bits could be used for fork *detection*. Even in the case where the DS is trying to maintain order, there's a chance that things go wrong. The tiebreaker bits would ensure that people don't try to use the wrong keys for a message in that case. Here's a quick PR implementing the "extended epoch" proposal: https://github.com/mlswg/mls-protocol/pull/281 On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert wrote: > I agree with Kelvin=E2=80=99s points in general. Allowing forks might be = an > interesting goal, but it raises a wealth of new questions. > On the other hand I think Richard=E2=80=99s proposal of extending the Epo= ch ID > with a commit hash makes sense to detect potential forks. > > I=E2=80=99d like to propose that we adopt that as a first step, but only = in the > context of fork detection for now. This doesn=E2=80=99t preclude us from = building > on top of that in the future, but we also don=E2=80=99t introduce somethi= ng > dangerous right now. > > Raphael > > On 3 Jan 2020, at 00:15, Kelvin Ritland < > kelvinr=3D40google.com@dmarc.ietf.org> wrote: > > Not-pseudorandom implies some assumptions, e.g., that each sender would >> only send one Commit on top of each epoch > > This isn't bad imo, it reduces complexity to some extent. I'm somewhat in > favour of a non-pseudorandom tiebreaker if there's no other arguments > against it. > > How many bits of sequence number? > > Have we considered using varints? Similar to the CTLS proposal - > https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1 > > > Other forking considerations, I think there's more involved than just > changing the epoch identifier: > > 1. We'll need merges as well, since forks can lead to inconsistent group > membership: > Suppose in epoch 1 a group has A, B, and C > A removes C in epoch 2A > B adds D in epoch 2B > > We now have two group states 2A with AB and 2B with ABCD - and it's > unclear which group to use to send with. We could mandate that any client > MUST send a "merge" commit on it's view of history before sending any > message. This commit could just be the list of epochs that are being merg= ed > (+a usual DirectPath update?), and processing it would mean replaying all > proposals up to the common ancestor for those epochs on the common ancest= or. > > 2. Forward secrecy issues. > By allowing forks, devices must now keep the previous epoch around to > derive possible future forks - but this means we'll be re-using > init_secret_. A possible solution could be to use the nth app secret from > the ASTree instead of init_secret_ as the start for the new epoch secret. > This ties nicely with using a non-pseudorandom tiebreaker. > > 3. Ordering implications > It's unclear what a sensible ordering strategy is for the DS if we allow > forking. (simply ensuring that each commit is based on the "current" epoc= h > isn't well defined since there can be multiple "current" epochs). > > By allowing forks the DS need not enforce ordering at all imo. This means > that apps need to keep around old epochs, but this is already required pe= r > (2). A different question is how many we need to keep around - perhaps a > TTL or the past N epochs after a topological sort would make sense. > > Generally I think getting rid of server ordering is good idea: > - Helps Matrix and general federation use cases > - A common consistent mutated state for group operations can cause server > side DB contention in my experience > > Forks is one way to remove ordering, and if we need to support it anyways > it's a nice benefit. > > On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes wrote: > >> Argh, hit send too soon. Continuing below... >> >> On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes wrote: >> >>> Hey all, >>> >>> Resurrecting this thread, as it seems that we never came to resolution >>> on this question. >>> >>> I'd like to propose we scope down and solve a narrower problem, namely >>> the problem of enabling forks in the group's history. So we're not goi= ng >>> to try to provide any privacy properties, just remove the impediment to >>> forking. This seems like a worthwhile thing to me just because it seem= s >>> silly to have forking blocked just because of syntactic constraint, in >>> addition to it likely being necessary for some decentralized use cases >>> (e.g., Matrix). >>> >>> To allow forks, we really just need some "tie breaker" bits in the epoc= h >>> ID so that if a given epoch has multiple successors, they end up with >>> different epoch IDs. And in order to avoid synchronization, each >>> participant needs to be able to generate those bits independently. The= re >>> are a couple of basic questions about how to construct the tie breaker: >>> >>> 1. Pseudorandom or not? >>> - Not-pseudorandom example: tiebreaker =3D commitSenderID >>> - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) >>> - Not-pseudorandom implies some assumptions, e.g., that each sender >>> would only send one Commit on top of each epoch >>> - Pseudorandom risks random collisions >>> - Possible to do both: tiebreaker =3D commitSenderID || >>> H(MLSPlaintext(Commit)) >>> >>> 2. How many bits of tiebreaker? >>> >> - Non-pseudorandom size will be dictated by what we include >> - Pseudorandom size will be dictated by tolerable collision probabilit= y >> - Probability of collision ~ (number of forks per seq no) / 2^{number >> of bits} >> >> 3. How many bits of sequence number? >> - DS might want to see sequence to help enforce ordering >> - Probably want this big enough to avoid wrapping. >> >> (Note that this is a value that goes in every message, so there's some >> incentive to keep things small.) >> >> Personally, my proposal would be something like: >> >> struct { >> uint64 sequence_number; >> uint64 commit_hash; // H(MLSPlaintext(Commit)) >> } EpochID; >> >> That seems to strike a reasonable balance between low collision >> probability (~2^-64) and a reasonably small identifier. If 128 bits is >> good enough for IPv6, it can be good enough for us :) >> >> Does that seem workable to folks? >> >> --Richard >> >> >> >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche < >>> benjamin.beurdouche@inria..fr > wrote: >>> >>>> >>>> > On Apr 26, 2019, at 9:26 PM, Jon Callas wrote: >>>> > >>>> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg >>>> wrote: >>>> >> >>>> >> So why not remove epoch entirely? >>>> > >>>> > An epoch lets you deal with things happening neither too often nor >>>> not often enough. Presume there is a client that is either malicious o= r >>>> just stupid. You want to keep it from forcing a rekey every 100=C2=B5s= . You want >>>> to force a rekey every so often. Hence epochs. Yeah, picking the right >>>> epoch size is an exercise left to the reader. >>>> >>>> You can=E2=80=99t use the epoch number for that as it is just global c= ounter >>>> for group operations, we will have to keep track of the latest group >>>> operation =E2=80=9Ctimestamp=E2=80=9D for each member within the group= state to check >>>> =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations y= ou described. >>>> >>>> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I >>>> feel like having more than 2^32 group operations over the lifetime of = a >>>> group is not unrealistic in certain extreme use cases, especially with >>>> large groups forcing PCS for application messages by triggering an upd= ate >>>> after each app message... >>>> >>>> We could remove the epoch number if we really want but it is necessary >>>> to give the Delivery Service some ordering information (unpredictable = or >>>> not is an interesting question) to handle concurrent handshake message= s >>>> which is, I believe, the main current goal of that information. >>>> >>>> Benjamin >>>> >>> _______________________________________________ >> 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 > > > --000000000000e0a98c059b3f2dce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I'm on the same page here. My objective is = to remove the roadblock without trying to solve the whole problem.=C2=A0 As= Kelvin points out, there's a lot of interesting thinking to be done ab= out how to manage a DAG of state.

In chatting with= Raphael just now, he proposed a nice framing -- that the tiebreaker bits c= ould be used for fork *detection*.=C2=A0=C2=A0 Even in the case where the D= S is trying to maintain order, there's a chance that things go wrong.= =C2=A0 The tiebreaker bits would ensure that people don't try to use th= e wrong keys for a message in that case.

Here'= s a quick PR implementing the "extended epoch" proposal:
https://github= .com/mlswg/mls-protocol/pull/281


On Fri, J= an 3, 2020 at 10:32 AM Raphael Robert <raphael@wire.com> wrote:
I agree with K= elvin=E2=80=99s points in general. Allowing forks might be an interesting g= oal, but it raises a wealth of new questions.
On the other hand I think= Richard=E2=80=99s proposal of extending the Epoch ID with a commit hash ma= kes sense to detect potential forks.

I=E2=80=99d l= ike to propose that we adopt that as a first step, but only in the context = of fork detection for now. This doesn=E2=80=99t preclude us from building o= n top of that in the future, but we also don=E2=80=99t introduce something = dangerous right now.

Raphael

On 3 Jan 2020, at 00:15, Kelvin Ritland <kelvinr= =3D40google.com@dmarc.ietf.org> wrote:

Not-pseudoran= dom implies some assumptions, e.g., that each sender would only send one Co= mmit on top of each epoch
This isn't bad imo, it reduc= es complexity to some extent. I'm somewhat in favour of a non-pseudoran= dom tiebreaker if there's no other arguments against it.

=
How many bits = of sequence number?
Have we considered using varints? Simi= lar to the CTLS proposal - https://tools.ietf.= org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1


Other forking considerations, I think t= here's more involved than just changing the epoch identifier:

1. We'll need merges as well, since forks can lea= d to inconsistent group membership:
Suppose in epoch 1 a=C2= =A0group has A, B, and C
A removes C in epoch 2A
B adds= D in epoch 2B

We now have two group states 2A wit= h AB and 2B with ABCD - and it's unclear which group to use to send wit= h. We could mandate that any client MUST send a "merge" commit on= it's view of history before sending any message. This commit could jus= t be the list of epochs that are being merged (+a usual DirectPath update?= ), and processing it would mean replaying all proposals up to the common an= cestor for those epochs on the common ancestor.
=

2. Forward secrecy issues.
By allowing = forks, devices must now keep the previous epoch around to derive possible f= uture forks - but this means we'll be re-using init_secret_. A possible= solution could be to use the nth app secret from the ASTree instead of ini= t_secret_ as the start=C2=A0for the new epoch secret. This ties nicely with= using a non-pseudorandom=C2=A0tiebreaker.

3. = Ordering implications
It's unclear what a sensible ordering s= trategy is for the DS if we allow forking. (simply ensuring that each commi= t is based on the "current" epoch isn't well defined since th= ere can be multiple "current" epochs).

B= y allowing forks the DS=C2=A0need=C2=A0not=C2=A0enforce ordering at all imo= . This means that apps need to keep around old epochs, but this is already = required=C2=A0per (2). A different question is how many we need to keep aro= und - perhaps a TTL or the past N epochs after a topological sort would mak= e sense.

Generally I think getting rid of server o= rdering is good idea:
- Helps Matrix and general federation use c= ases
- A common consistent mutated state for group operations can= cause server side DB contention in my experience

= Forks is one way to remove ordering, and if we need to support it anyways i= t's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes <rlb@ipv.sx> wrote:
= Argh, hit send too soon.=C2=A0 Continuing below...

On Thu, Jan 2, 2020 = at 3:38 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

Resurr= ecting this thread, as it seems that we never came to resolution on this qu= estion.

I'd like to propose we scope down = and solve a narrower problem, namely the problem of enabling forks in the g= roup's history.=C2=A0 So we're not going to try to provide any priv= acy properties, just remove the impediment to forking.=C2=A0 This seems lik= e a worthwhile thing to me just because it seems silly to have forking bloc= ked just because of syntactic constraint, in addition to it likely being ne= cessary for some decentralized use cases (e.g., Matrix).

To allow forks, we really just need some "tie breaker" bit= s in the epoch ID so that if a given epoch has multiple successors, they en= d up with different epoch IDs.=C2=A0 And in order to avoid synchronization,= each participant needs to be able to generate those bits independently.=C2= =A0 There are a couple of basic questions about how to construct the tie br= eaker:

1. Pseudorandom or not?
=C2=A0 - = Not-pseudorandom example: tiebreaker =3D commitSenderID
=C2= =A0 - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit))
=C2=A0 - Not-pseudorandom implies some assumptions, e.g., that each sende= r would only send one Commit on top of each epoch
=C2=A0 - Pseudo= random risks random collisions
=C2=A0 - Possible to do both: tieb= reaker =3D commitSenderID || H(MLSPlaintext(Commit))

2. How many bits of tiebreaker?
=C2=A0 - No= n-pseudorandom size will be dictated by what we include
=C2=A0 - = Pseudorandom size will be dictated by tolerable collision probability
=
=C2=A0 - Probability of collision ~ (number of forks per seq no) / 2^{= number of bits}

3. How many bits of sequence numbe= r?
- DS might want to see sequence to help enforce ordering
=
- Probably want this big enough to avoid wrapping.

<= /div>
(Note that this is a value that goes in every message, so there&#= 39;s some incentive to keep things small.)

Per= sonally, my proposal would be something like:

stru= ct {
=C2=A0 uint64 sequence_number;
=C2=A0 uint64 c= ommit_hash; // H(MLSPlaintext(Commit))
} EpochID;

That seems to strike a reasonable balance between low col= lision probability (~2^-64) and a reasonably small identifier.=C2=A0 If 128= bits is good enough for IPv6, it can be good enough for us :)
Does that seem workable to folks?

--R= ichard

=C2=A0



=


On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche &l= t;benjami= n.beurdouche@inria..fr> wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:<= br> >>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor not= often enough. Presume there is a client that is either malicious or just s= tupid. You want to keep it from forcing a rekey every 100=C2=B5s. You want = to force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global counte= r for group operations, we will have to keep track of the latest group oper= ation =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to= check =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations= you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel = like having more than 2^32 group operations over the lifetime of a group is= not unrealistic in certain extreme use cases, especially with large groups= forcing PCS for application messages by triggering an update after each ap= p message...

We could remove the epoch number if we really want but it is necessary to g= ive the Delivery Service some ordering information (unpredictable or not is= an interesting question) to handle concurrent handshake messages which is,= I believe, the main current goal of that information.

Benjamin
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div> --000000000000e0a98c059b3f2dce-- From nobody Sat Jan 4 16:41:13 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 8712C1200A1 for ; Sat, 4 Jan 2020 16:41:11 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 x72ukLdMOF0T for ; Sat, 4 Jan 2020 16:41:08 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 817FB12008F for ; Sat, 4 Jan 2020 16:41:08 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id a33so25121381pgm.5 for ; Sat, 04 Jan 2020 16:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RdV5ys+lpEXEmYxMA2zBpEtn/SOic9hXKUBHizqjT0Y=; b=KI6pi39JbFqY2Gl5fOcHQ/NGmUpL0Q2kEGnvyrT129XW7vyL4cteIVsUWfnn8Mum0N BHqFx8loMV6s+gzobMDrOBoNu56CEQ+ihkHkLiX+4w6lhfadWIzuv2QW7qR+u45WVjAw BUkMKu2s4+iBEE+Rc/MWUr0s3XKElHNCf9WtM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RdV5ys+lpEXEmYxMA2zBpEtn/SOic9hXKUBHizqjT0Y=; b=rZUMm07JctTd6NqfWv2R3+1FNHKcB6vh7CBLO0VvE2384Fi80WyHFbc0wyu45YefW/ zEWgOedWGzcF/9VpnRKUFwUeWse22cL3ZxGp8Xx3pNWCOPrhRtpupyiHAtFCdE1Nx0g8 u9FyxDSNo29KhlDddK6KT4YcazVrb4rR2pnYWTQvnH90qRqtYuuQ02aL+/tc+hnlujJR pKB1Zn6UGyusHh0LXDijjEBNd4mTeNwK9RthgbB3uBYajIFXa4RvEAcYdgHfILn5l4M2 gu4Ys2q9zswuWgUsXrnAX9yvwFrgFgbR8CstL6L2Uoh+EWkT5bup5AGUnubb3bd7agt+ 29Xw== X-Gm-Message-State: APjAAAXjzvRGGbIo4IiCy172bWoZintploQ0CHVoyEjNbUsukwPXwiQQ +S7qzw9YalSP5AsCaD6e147TYw== X-Google-Smtp-Source: APXvYqzOJ+MA2DRqTfMHB57htWMw1KaYLJKvYvwo+Et6tnb13P/fW+Ub/TQchEae5M7Vu4ILDJDt/A== X-Received: by 2002:aa7:979a:: with SMTP id o26mr102575624pfp.0.1578184867840; Sat, 04 Jan 2020 16:41:07 -0800 (PST) Received: from ?IPv6:2601:640:8600:25:e913:8f5:e2ae:f7e0? ([2601:640:8600:25:e913:8f5:e2ae:f7e0]) by smtp.gmail.com with ESMTPSA id c17sm66418597pfi.104.2020.01.04.16.41.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jan 2020 16:41:07 -0800 (PST) From: Brendan McMillion Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE086C5-75B0-4BAA-A93F-93E915416E5B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sat, 4 Jan 2020 16:32:27 -0800 In-Reply-To: Cc: Raphael Robert , Kelvin Ritland , Michael Rosenberg , Messaging Layer Security WG , Benjamin Beurdouche , Jon Callas To: Richard Barnes References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 05 Jan 2020 00:41:12 -0000 --Apple-Mail=_FBE086C5-75B0-4BAA-A93F-93E915416E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Strictly speaking, it=E2=80=99s already possible to detect forks. The = content_type and epoch are left unencrypted, so if you have two messages = with content_type=3DCommit and the same epoch number, that=E2=80=99s a = fork. You can layer any sort of consensus mechanism you want on top of = the protocol to handle those situations, whether it=E2=80=99s a central = server, quorum voting, or something else. It seems like the problem you=E2=80=99re trying to solve now is =E2=80=9CH= ow do we know which fork a message belongs to, if that message is sent = after a fork happened?=E2=80=9D And intuitively, I would think that this = should also be dealt with by whatever consensus mechanism the DS uses. = Since the mechanism exists, and already has to do all the work to keep = track of forks and break ties. > On Jan 3, 2020, at 8:55 AM, Richard Barnes wrote: >=20 > Yeah, I'm on the same page here. My objective is to remove the = roadblock without trying to solve the whole problem. As Kelvin points = out, there's a lot of interesting thinking to be done about how to = manage a DAG of state. >=20 > In chatting with Raphael just now, he proposed a nice framing -- that = the tiebreaker bits could be used for fork *detection*. Even in the = case where the DS is trying to maintain order, there's a chance that = things go wrong. The tiebreaker bits would ensure that people don't try = to use the wrong keys for a message in that case. >=20 > Here's a quick PR implementing the "extended epoch" proposal: > https://github..com/mlswg/mls-protocol/pull/281 = >=20 >=20 >=20 > On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert > wrote: > I agree with Kelvin=E2=80=99s points in general. Allowing forks might = be an interesting goal, but it raises a wealth of new questions. > On the other hand I think Richard=E2=80=99s proposal of extending the = Epoch ID with a commit hash makes sense to detect potential forks. >=20 > I=E2=80=99d like to propose that we adopt that as a first step, but = only in the context of fork detection for now. This doesn=E2=80=99t = preclude us from building on top of that in the future, but we also = don=E2=80=99t introduce something dangerous right now. >=20 > Raphael >=20 >> On 3 Jan 2020, at 00:15, Kelvin Ritland = > wrote: >>=20 >> Not-pseudorandom implies some assumptions, e.g., that each sender = would only send one Commit on top of each epoch >> This isn't bad imo, it reduces complexity to some extent. I'm = somewhat in favour of a non-pseudorandom tiebreaker if there's no other = arguments against it. >>=20 >> How many bits of sequence number? >> Have we considered using varints? Similar to the CTLS proposal - = https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1 = >>=20 >>=20 >> Other forking considerations, I think there's more involved than just = changing the epoch identifier: >>=20 >> 1. We'll need merges as well, since forks can lead to inconsistent = group membership: >> Suppose in epoch 1 a group has A, B, and C >> A removes C in epoch 2A >> B adds D in epoch 2B >>=20 >> We now have two group states 2A with AB and 2B with ABCD - and it's = unclear which group to use to send with. We could mandate that any = client MUST send a "merge" commit on it's view of history before sending = any message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor. >>=20 >> 2. Forward secrecy issues. >> By allowing forks, devices must now keep the previous epoch around to = derive possible future forks - but this means we'll be re-using = init_secret_. A possible solution could be to use the nth app secret = from the ASTree instead of init_secret_ as the start for the new epoch = secret. This ties nicely with using a non-pseudorandom tiebreaker. >>=20 >> 3. Ordering implications >> It's unclear what a sensible ordering strategy is for the DS if we = allow forking. (simply ensuring that each commit is based on the = "current" epoch isn't well defined since there can be multiple "current" = epochs). >>=20 >> By allowing forks the DS need not enforce ordering at all imo.. This = means that apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense. >>=20 >> Generally I think getting rid of server ordering is good idea: >> - Helps Matrix and general federation use cases >> - A common consistent mutated state for group operations can cause = server side DB contention in my experience >>=20 >> Forks is one way to remove ordering, and if we need to support it = anyways it's a nice benefit. >>=20 >> On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes > wrote: >> Argh, hit send too soon. Continuing below... >>=20 >> On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes > wrote: >> Hey all, >>=20 >> Resurrecting this thread, as it seems that we never came to = resolution on this question. >>=20 >> I'd like to propose we scope down and solve a narrower problem, = namely the problem of enabling forks in the group's history. So we're = not going to try to provide any privacy properties, just remove the = impediment to forking. This seems like a worthwhile thing to me just = because it seems silly to have forking blocked just because of syntactic = constraint, in addition to it likely being necessary for some = decentralized use cases (e.g., Matrix). >>=20 >> To allow forks, we really just need some "tie breaker" bits in the = epoch ID so that if a given epoch has multiple successors, they end up = with different epoch IDs. And in order to avoid synchronization, each = participant needs to be able to generate those bits independently. = There are a couple of basic questions about how to construct the tie = breaker: >>=20 >> 1. Pseudorandom or not? >> - Not-pseudorandom example: tiebreaker =3D commitSenderID >> - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) >> - Not-pseudorandom implies some assumptions, e.g., that each sender = would only send one Commit on top of each epoch >> - Pseudorandom risks random collisions >> - Possible to do both: tiebreaker =3D commitSenderID || = H(MLSPlaintext(Commit)) >>=20 >> 2. How many bits of tiebreaker? >> - Non-pseudorandom size will be dictated by what we include >> - Pseudorandom size will be dictated by tolerable collision = probability >> - Probability of collision ~ (number of forks per seq no) / = 2^{number of bits} >>=20 >> 3. How many bits of sequence number? >> - DS might want to see sequence to help enforce ordering >> - Probably want this big enough to avoid wrapping. >>=20 >> (Note that this is a value that goes in every message, so there's = some incentive to keep things small.) >>=20 >> Personally, my proposal would be something like: >>=20 >> struct { >> uint64 sequence_number; >> uint64 commit_hash; // H(MLSPlaintext(Commit)) >> } EpochID; >>=20 >> That seems to strike a reasonable balance between low collision = probability (~2^-64) and a reasonably small identifier. If 128 bits is = good enough for IPv6, it can be good enough for us :) >>=20 >> Does that seem workable to folks? >>=20 >> --Richard >>=20 >> =20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche = > = wrote: >>=20 >> > On Apr 26, 2019, at 9:26 PM, Jon Callas > wrote: >> >=20 >> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg > wrote: >> >>=20 >> >> So why not remove epoch entirely? >> >=20 >> > An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader. >>=20 >> You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described. >>=20 >> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I = feel like having more than 2^32 group operations over the lifetime of a = group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message... >>=20 >> We could remove the epoch number if we really want but it is = necessary to give the Delivery Service some ordering information = (unpredictable or not is an interesting question) to handle concurrent = handshake messages which is, I believe, the main current goal of that = information. >>=20 >> Benjamin >> _______________________________________________ >> 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 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_FBE086C5-75B0-4BAA-A93F-93E915416E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Strictly speaking, it=E2=80=99s already possible to detect = forks. The content_type and epoch are left unencrypted, so if you have = two messages with content_type=3DCommit and the same epoch number, = that=E2=80=99s a fork. You can layer any sort of consensus mechanism you = want on top of the protocol to handle those situations, whether it=E2=80=99= s a central server, quorum voting, or something else.

It seems like the problem you=E2=80=99re = trying to solve now is =E2=80=9CHow do we know which fork a message = belongs to, if that message is sent after a fork happened?=E2=80=9D And = intuitively, I would think that this should also be dealt with by = whatever consensus mechanism the DS uses. Since the mechanism exists, = and already has to do all the work to keep track of forks and break = ties.

On Jan = 3, 2020, at 8:55 AM, Richard Barnes <rlb@ipv.sx> wrote:

Yeah, I'm on the same page here. My objective = is to remove the roadblock without trying to solve the whole = problem.  As Kelvin points out, there's a lot of interesting = thinking to be done about how to manage a DAG of state.

In chatting with Raphael = just now, he proposed a nice framing -- that the tiebreaker bits could = be used for fork *detection*.   Even in the case where the DS = is trying to maintain order, there's a chance that things go = wrong.  The tiebreaker bits would ensure that people don't try to = use the wrong keys for a message in that case.

Here's a quick PR implementing the = "extended epoch" proposal:
https://github..com/mlswg/mls-protocol/pull/281



On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert = <raphael@wire.com> wrote:
I agree with Kelvin=E2=80=99s points in general. = Allowing forks might be an interesting goal, but it raises a wealth of = new questions.
On the other hand I think Richard=E2=80=99s = proposal of extending the Epoch ID with a commit hash makes sense to = detect potential forks.

I=E2=80=99d like to propose that we adopt that as a first = step, but only in the context of fork detection for now. This doesn=E2=80=99= t preclude us from building on top of that in the future, but we also = don=E2=80=99t introduce something dangerous right now.

Raphael

On 3 Jan 2020, at 00:15, Kelvin Ritland <kelvinr=3D40google.com@dmarc.ietf.org> wrote:

Not-pseudorandom implies some = assumptions, e.g., that each sender would only send one Commit on top of = each epoch
This isn't bad imo, it reduces = complexity to some extent. I'm somewhat in favour of a non-pseudorandom = tiebreaker if there's no other arguments against it.

How many bits of sequence = number?
Have we considered using varints? = Similar to the CTLS proposal - https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.s= ection.3.1


Other forking = considerations, I think there's more involved than just changing the = epoch identifier:

1. We'll need merges as well, since forks can lead to = inconsistent group membership:
Suppose in epoch 1 a group has A, B, and C
A removes C in epoch 2A
B adds D in = epoch 2B

We = now have two group states 2A with AB and 2B with ABCD - and it's unclear = which group to use to send with. We could mandate that any client MUST = send a "merge" commit on it's view of history before sending any = message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor.

2. Forward secrecy issues.
By allowing = forks, devices must now keep the previous epoch around to derive = possible future forks - but this means we'll be re-using init_secret_. A = possible solution could be to use the nth app secret from the ASTree = instead of init_secret_ as the start for the new epoch secret. This = ties nicely with using a non-pseudorandom tiebreaker.

3. = Ordering implications
It's unclear what a sensible = ordering strategy is for the DS if we allow forking. (simply ensuring = that each commit is based on the "current" epoch isn't well defined = since there can be multiple "current" epochs).

By allowing forks the = DS need not enforce ordering at all imo.. This means that = apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense.

Generally I think getting rid of server ordering is good = idea:
- Helps Matrix and general federation use = cases
- A common consistent mutated state for group = operations can cause server side DB contention in my = experience

Forks= is one way to remove ordering, and if we need to support it anyways = it's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes = <rlb@ipv.sx> wrote:
Argh, hit send too soon.  Continuing = below...

On Thu, Jan = 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

Resurrecting this thread, as it seems that we never came to = resolution on this question.

I'd like to propose we scope down and = solve a narrower problem, namely the problem of enabling forks in the = group's history.  So we're not going to try to provide any privacy = properties, just remove the impediment to forking.  This seems like = a worthwhile thing to me just because it seems silly to have forking = blocked just because of syntactic constraint, in addition to it likely = being necessary for some decentralized use cases (e.g., = Matrix).

To = allow forks, we really just need some "tie breaker" bits in the epoch ID = so that if a given epoch has multiple successors, they end up with = different epoch IDs.  And in order to avoid synchronization, each = participant needs to be able to generate those bits independently.  = There are a couple of basic questions about how to construct the tie = breaker:

1. = Pseudorandom or not?
  - Not-pseudorandom = example: tiebreaker =3D commitSenderID
  - Pseudorandom example: tiebreaker =3D = H(MLSPlaintext(Commit))
  - Not-pseudorandom = implies some assumptions, e.g., that each sender would only send one = Commit on top of each epoch
  - Pseudorandom = risks random collisions
  - Possible to do = both: tiebreaker =3D commitSenderID || H(MLSPlaintext(Commit))

2. How many bits of = tiebreaker?
  - = Non-pseudorandom size will be dictated by what we include
  - Pseudorandom size will be dictated by tolerable = collision probability
  - Probability of = collision ~ (number of forks per seq no) / 2^{number of bits}

3. How many bits of = sequence number?
- DS might want to see sequence to = help enforce ordering
- Probably want this big = enough to avoid wrapping.

(Note that this is a value that goes in = every message, so there's some incentive to keep things small.)

Personally, my proposal would be something like:

struct {
  uint64 = sequence_number;
  uint64 commit_hash; // = H(MLSPlaintext(Commit))
} = EpochID;

That seems to strike a reasonable balance between low = collision probability (~2^-64) and a reasonably small identifier.  = If 128 bits is good enough for IPv6, it can be good enough for us = :)

Does that = seem workable to folks?

--Richard

 





On Fri, Apr 26, 2019 at 4:18 PM = Benjamin Beurdouche <benjamin.beurdouche@inria..fr> = wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:
>>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I = feel like having more than 2^32 group operations over the lifetime of a = group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message...

We could remove the epoch number if we really want but it is necessary = to give the Delivery Service some ordering information (unpredictable or = not is an interesting question) to handle concurrent handshake messages = which is, I believe, the main current goal of that information.

Benjamin
_______________________________________________
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

= --Apple-Mail=_FBE086C5-75B0-4BAA-A93F-93E915416E5B-- From nobody Mon Jan 6 19:45:44 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 90015120074 for ; Mon, 6 Jan 2020 19:45:43 -0800 (PST) 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 yVezCiFJcYKQ for ; Mon, 6 Jan 2020 19:45:42 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 0144F120058 for ; Mon, 6 Jan 2020 19:45:41 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id t129so41509564qke.10 for ; Mon, 06 Jan 2020 19:45:41 -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=WsK5w7CNcV2uqofy6bZdeHd7AkJUP5BgQROXvTEWQwg=; b=hGGK1xqZwRAU3vS1BfN1+jDkBwj5N80a5rWbrkWRx6lTGrEsjVIuh+pRrdHxuOOHYB QP+q0bX4YTFmIm0XGFkBDqdv1UPud8rgbJE/t3HRsjbY8ihhGAn/AHf6CO+kkFw4CYhJ rgiBrt9LRkzDqvCFOmRN1vIwlcfRoZ4JwN/lg= 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=WsK5w7CNcV2uqofy6bZdeHd7AkJUP5BgQROXvTEWQwg=; b=koQrD+4IZKRy0JKzLZyXW7oO3DmFShm6qUxbOabdTeYwswnUhawaV11AkC3Dm/qqBL AIRlamGeL6nsJcP60FjCveJIfKfC6CLvVXVGGtD+P7J4hKAo4n7ctD+HHuqO65ByJImI dVmGd20VUV70ema7jVA0czYGA9WZgLdzzEgtB6RYtKMQ7Hcs+V8igiwy8iP0fyVnXKve ElQmc8Lf2BQT33jqbLFLQ5s6QwH/4wRI1OVh4bF9HFicm+iIfMiokTXVhk/u2OdXPbgU px1RR69AgRNueBACGFLT42nvkR4obyyk1mkeuGBdH2UeT4rAFDClyqYhTXTW9Y/HTSYQ Lbxg== X-Gm-Message-State: APjAAAVBxtoGTSkBOM6TwXH6dCjnq4+TIQN3AXiSxNyVwSriFwVebi5y 0JJFfTmKYqpCmfKYC1aPSUzh80bcjGk= X-Google-Smtp-Source: APXvYqy8kFBbz1nynoq/WFmlagTUKArQgn8fNlQGqTxAjT/nKkDyVBtkoaKwxH3kzX/qlbZj7943xA== X-Received: by 2002:a05:620a:14a2:: with SMTP id x2mr87024661qkj.36.1578368740839; Mon, 06 Jan 2020 19:45:40 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id m68sm21458200qke.17.2020.01.06.19.45.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2020 19:45:40 -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: Mon, 6 Jan 2020 22:45:38 -0500 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] MLS Interim 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, 07 Jan 2020 03:45:43 -0000 All, The location has been finalized: Cisco has graciously offered to host us = at their NYC offices. The physical location is: One Penn Plaza 9th Floor=20 New York, NY 10119 I have updated the GH pages [0] with this information as well as the = information for remote attendees (aka the Webex details). Looking forward to the meeting! spt [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.M= D > On Dec 5, 2019, at 14:10, Nick Sullivan = wrote: >=20 > MLSWG, >=20 > After the poll we set a date and time for the January 2020 MLS = interim. It will be in New York City on January 11-12. This immediately = follows the Real World Cryptography conference. >=20 > We are working on confirming the location for event, and NYU in Lower = Manhattan is a strong possibility. >=20 > Nick & Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Jan 7 06:09:03 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 F03E2120123 for ; Tue, 7 Jan 2020 06:09:02 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 GZeydxlma1jG for ; Tue, 7 Jan 2020 06:09:00 -0800 (PST) Received: from mail.blinkt.de (mail.blinkt.de [IPv6:2001:638:502:390:20c:29ff:fee4:80a3]) (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 EC9351200E9 for ; Tue, 7 Jan 2020 06:08:59 -0800 (PST) Received: from p200300d027039f00e1ac7bdbff5d9437.dip0.t-ipconnect.de ([2003:d0:2703:9f00:e1ac:7bdb:ff5d:9437] helo=styx.fritz.box) by mail.blinkt.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1iopXV-0005WY-Ck for mls@ietf.org; Tue, 07 Jan 2020 15:08:57 +0100 From: Arne Schwabe Autocrypt: addr=arne@rfc2549.org; prefer-encrypt=mutual; keydata= mQINBFusyrsBEAC2Re1MmQjPiutRC8w4vzmHBiPCIRpCPd97rP+ZNdf4DMWlqvSl+Kw+8urP lbh6dQKVpdcUGu9iNcLyPDI4xjatvYXo7VKvI1zVri6qboZ2EypezpyekZXHFS5tv3Dnbf55 S0/MUBQVraIsc3kedeZGizv9alokgGAq3NTACuqFe6plm/+bFLpA51Qfex5FUrSz6bB59tgU LptPLVa10W6mSAL4pusdhUvHEeqxF1+fYsQ3KKEbry8Rnc6F2wExmSyicHOBjRstw7cIqWGG OdsSz68LXEtvXwEzuxv/YlSABTrs2AhouKRedRJx7XbEK+H9GboTRofqX4Ph4uZoJbU5cilV KWen0goCOzR6CohYC/fyjqSEGvhwfmtm3slqj4ZXLpdNrcsgwxmT1Az9S35Vm1Kxcn+RoG+R bHhFvv+gL+cuoiwnhWCozh/Ooy1SlSxqQtWl57WULEr9Pu/JyMwUG82xjQhgu2KhuBz2tvs9 WmQHT/N3ADEbHhtNLB/cXlY8LDwJ6D5diVBix2kaXRj9Ux5ERNDcbGGL5ztrOGyvbDIf2ZSQ 4DQyCYzvv6YMB/08R0tm/C7XCzTawcF0mdRYEkOQmP2H96NV167WxvxZxF6uLRJKQ7B0IxcW riayxsWe4jUmoso7cxB6M5sMtpPN8FoWgmcjacEDM7FCaVd+LQARAQABtB9Bcm5lIFNjaHdh YmUgPGFybmVAcmZjMjU0OS5vcmc+iQJOBBMBCAA4FiEE88wmPb+Azu8xbws3FRhsZwKxRFQF AlusyrsCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQFRhsZwKxRFSc1BAAsILrcC2B B8nC38cI8syth8eX3C1fBcPMN0HfxOc8EuTxb/JTSlkaE+m/EJk4swnDZlQcK1iiadvycZt/ mA6zx5vj9E4uM3IwQfuWNP/Y3HVE4qPImXTgzjJTRBG6w+iACgvgJP/xFfA7gt6/PWnRNDMf FCA7mdgmnATFrj4+DPcJT6/7IhtO4IQ52Xmd1ef0/+fS1pk9NBaEL6Ujf8JhdCjEwcuZ0sU4 QAcA2h98NeDW8WGRL8MdpULVkcpfcW06IReKZGxXy/Qzjh7HIppWqlm5G7u7kktdGWCetzpz 4QD5MSdGDeYO2nCK20N5KnAwPhu4mrWnPFtFnuq3R3fWvFQ8u1qtPsL8+ylXYLaQiOTV3FRV xUGK8qjal/nEX3ZcsDNpFb0o7eQPPnPatJlUl9ntMU/rDzO2xbq/ZBwBU9Y+6oJUMUgxaxZY 6SLe1giNPuFdMGxK5SoODzYVvZIBQkQe+pK74T4mmXtkCxy0Czqq8D+kCu/Ki4mTBXe3tzQm asPHqC4vJ0+MlVDJppBvMzu3PaEKJjVjm+37ck1AdrIVSywbz63oDdoAP4UMfO8hYngo7uhY wc7c3keWrfhpc6R+MLgMb2Jmnv07tIsswLUrN7MOHUrTAiyxW9BJTSpgE7jLw7Qv7204C7n9 1SxQepSkUj2bewoYzUBrCWs0RNa5Ag0EW6zK3QEQAN1LZ11oc6mAIw1Rh7wdG2eBzv/ifbdS 1g0j6wzZ/dIktvfYnkU5QvYwOn7j/dmYw1mlp3sh7Eumwmu4LDEAn93qQPE8hRJePLFThZx9 LP9RrY4D2BS7IAfNxIpoiTkxovIrLOzQqebm3qxzAJk0JTRtYIjneZff0MrYGP/Wnhnb9qIU dmT0UA5K1mynBpHfa31DjWWNSUWohS5245KedzmrrHoBRURcNFZmofk5L5I+Fw7gp22cSIOc 4lDYQI/KFXFdR1EhxZBUX3ITd81gINSzypTFdfmzyvhaFJaz5cHReUvFAG9TEBxpTFgPiXGE 3I+ORzpm8WJK76NTLFicJZ/B90T4p6HXLtoPixhCxY0c/xVta4B1r/sBnOnE0IkNgNMhJh6G 1VqKsXDrWyd96tvONw5cd3xq+SQp0CoXT5A7ExQGg7Lynel/pCJ5JWEWKLWvkKxLFXTUkSJh g5YU9i1uodWsvm0mQltTMooE+/yifhymKp/7tLZuguzQ+vto1jnc96V48DR6yIXB+c9CgMVq DYYk5o+XM5pcxAcyqVxAKQ7DGd/nriiZRUlvdGGgyjR0sJWMhWsWatNycVfruX7Zfz51PlEi 59nlNj5/ZDoXu0EYEhl4hrDLn8RUKjve+1mx6/YA8ixGE+RPOZ5PUNAouw/pXWD2ucRISe+s 8nbtABEBAAGJAjYEGAEIACAWIQTzzCY9v4DO7zFvCzcVGGxnArFEVAUCW6zK3QIbDAAKCRAV GGxnArFEVDUnD/wIkxMssF3u1GHcD+a8A1Iaa477dbMRgPUrsz2k0S601dwK8eJRuQWXOk+e SiwSwXRn3feAfYR2uRaE4lB+wsapkFZU+ZO9VVh1R2qWcetF8JJk/gEpPFYltT9bkdDmCRRx URePkpqlZMYOJSJWI6ZmqCteloV9ed/4XJVgknGISot7u4Umdl3RdNLMGACU3HvodUq6F8T8 n0x6XMvguG0t1G4br0DTL+fabBh50xFxpf5hII5K8Iw1r14GTYgxIMzIfcGWVQ+O2lq5UKsU Dm9o/z11QfxuukCqZWWGoteaW90Z8SynN3RhDr3d3Q/VyZ/xXCQhQ5VprMOyiNmm2EMXPFPr RKOz2ZdTcKIFO1Xj+7GmElnwlIrO2wrGre2fXHeaWbGLiTNlcyWnuEGI56OivfZne1uiY/GV k2W5FlpfJPeBVUKiKhCmp4hOb9mC7ICBSYS1UmCjguR8QSUuKQFiwZ4qi9hnko8b+OT7q8s7 NaYmgD04Jjgth0YKGZxd3Mf3ngg+hSU+B6ngLd0wkLsjzDwU9OJpuW9kTPrx0iwNZfnTU87k YuJAJRfZmG36ySM8JSPXjnkLiHTGc4vtwbS+FGrS6D7nV69+40JbvkKFfHWTyXLjE6+jkOvw ThNCJSdPKjl0MMk2QmY6TGjjrlR+yewhQ2VZfzflJwuAQ2SVog== To: mls@ietf.org Message-ID: Date: Tue, 7 Jan 2020 15:08:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] Keying Material Exporter 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, 07 Jan 2020 14:09:03 -0000 Hey, this is my first mail to an IETF mailing list, so please point out my mistakes to me. I also want to apologise if this the wrong way to interact with standardising working groups. My question is if there are any plans to add an interface for keying material export to MLS? Let me explain the background why I am asking this. Some might be familiar with RFC 5705. RFC 5705 adds a standardised interface to TLS to generate/derive keying material from a TLS session, so it can be used for example used in the encryption an UDP datastream. Since my background is being a OpenVPN core developer, I will write the rest a bit from that perspective. OpenVPN basically does a standard TLS session and then does a TLS inspired custom key derivation with normal messages over that secure channel to generate the session key for encryption of data packets. The TLS standardised key export (RFC5705) is planned to replace the custom key derivation schema. Typically, in a VPN you have have point to point encrypted links and the VPN server will decrypt the data and reencrypt it before sending it to a different client. And a compromise of the VPN server compromises all communication if not secured otherwise. The idea is to use MLS to create a VPN, where the VPN server (or some VPN "cloud") is not fully trusted but mainly would only route and forward the (encrypted) IP packets between the clients. MLS would then be used to create 2 member groups for direct communication and multiple member groups for multicast/broadcast communication. While also application messages could be used then to securely agree on a session key for the encrypted IP packets, having a keying material exporter function in MLS would be much better than to reinvent the wheel. I recognise that my intended use of MLS is probably not the focus/intended use of the MLS protocol. But it looks that MLS could solve my problem without the need to implement a custom protocol for the same purpose (which is never a good idea). And the additional feature are also nice to have. Arne From nobody Tue Jan 7 06:12:29 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 74171120123 for ; Tue, 7 Jan 2020 06:12:26 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 (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 NcDKn8ZCMT6n for ; Tue, 7 Jan 2020 06:12:24 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D1D1200E9 for ; Tue, 7 Jan 2020 06:12:23 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id u71so54850209lje.11 for ; Tue, 07 Jan 2020 06:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AWbtwwrRI2IusDa1r1DLYrt5bAeME+E5ZSCuZwJquqw=; b=UPaZPBrfmhiy99qzJT6cFi2XoK9ybSr9hEphH5grb6mYcdIsuCVHg160g371Rv+8IB L2YSnEbqa88yX8hhYtuN21XkAa9G2PC01Xz0+dyK/HVvTjWbRooJGw3rkPQk6Nva9q3+ z5kecSv0mcKQPQQmDJk5kx0k+mzhaG45/x4pNWHWdlBT3aL/9iojsL6OUYKo0zldyaBZ o0B/HMf3GoExNSgjaLPrzAFtM7sPWlZVy7a2pu3kPB3Ij+hVlIFK6Zm03BDnLwmk35TX yEiAWKoQ+HldhAxj6qs72jK7QT11ww4NeKpFiLB9M9ty+81AbwiERkCqHTvunio+/TiK Vi4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AWbtwwrRI2IusDa1r1DLYrt5bAeME+E5ZSCuZwJquqw=; b=hSKtCmCW9Mz0QO1Ffr4fP9JyOWVxbigRaHjPMHF+1ilD7o5iSvk2QI2XC04eStrxlu VQRnitOZRglVSV9uSIvupFAoaY5IghE9LqkfT3ZUSlLy34Ndy0EvNg3JHEr40pDoxdmA B+6gPvrPFmTVOAgvq2mWcG74B2IQKYYgkWLWNjU1zfEIxoUZrkOM5Rpbnvx/LLtyuG5P AVz0jDtSINUefj5Y0VLD8zRpPk/fgH6POPNN4Z/b2s8aIMYLNFde3qRAErst2kVveJRB jtcMnFolitNK+zXZG+Ud/Nj9JIVlXbXZrN+T/a9HiTMBplcbQnBG5Nk3tvooKKd7Eybk zZFw== X-Gm-Message-State: APjAAAUY3Re2Ra79F4JOyqfiJJKoRhAjFOo9IT3jBAF5sfIGvthheyJa Yllsp+Eil5VPCM7ekMk/unX+JBx+MzB3oQ== X-Google-Smtp-Source: APXvYqw733xiIWBC0WpHsqiqUSMIk2bgNjQfEtVYmtMSnIPCFOQGpqWMyZkUMPPG6zcPIoLPgcwQkw== X-Received: by 2002:a2e:83d5:: with SMTP id s21mr58437965ljh.95.1578406341752; Tue, 07 Jan 2020 06:12:21 -0800 (PST) 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 w8sm29663543ljd.13.2020.01.07.06.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 06:12:20 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FAE2F2B2-A82C-4F46-A375-5C277D52CD88" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 7 Jan 2020 15:12:19 +0100 In-Reply-To: Cc: mls@ietf.org To: Arne Schwabe References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Keying Material Exporter 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, 07 Jan 2020 14:12:26 -0000 --Apple-Mail=_FAE2F2B2-A82C-4F46-A375-5C277D52CD88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Arne, Yes, there is a way to export secrets from the key schedule. You can = find the details in the =E2=80=9CExporters=E2=80=9D section in the LS = protocol draft = (https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol= .md = ) I hope that helps, otherwise let us know. Thanks Raphael > On 7 Jan 2020, at 15:08, Arne Schwabe wrote: >=20 > Hey, >=20 > this is my first mail to an IETF mailing list, so please point out my > mistakes to me. I also want to apologise if this the wrong way to > interact with standardising working groups. >=20 > My question is if there are any plans to add an interface for keying > material export to MLS? >=20 > Let me explain the background why I am asking this. Some might be > familiar with RFC 5705. RFC 5705 adds a standardised interface to TLS = to > generate/derive keying material from a TLS session, so it can be used > for example used in the encryption an UDP datastream. >=20 > Since my background is being a OpenVPN core developer, I will write = the > rest a bit from that perspective. OpenVPN basically does a standard = TLS > session and then does a TLS inspired custom key derivation with normal > messages over that secure channel to generate the session key for > encryption of data packets. The TLS standardised key export (RFC5705) = is > planned to replace the custom key derivation schema. Typically, in a = VPN > you have have point to point encrypted links and the VPN server will > decrypt the data and reencrypt it before sending it to a different > client. And a compromise of the VPN server compromises all = communication > if not secured otherwise. >=20 > The idea is to use MLS to create a VPN, where the VPN server (or some > VPN "cloud") is not fully trusted but mainly would only route and > forward the (encrypted) IP packets between the clients. MLS would then > be used to create 2 member groups for direct communication and = multiple > member groups for multicast/broadcast communication. While also > application messages could be used then to securely agree on a session > key for the encrypted IP packets, having a keying material exporter > function in MLS would be much better than to reinvent the wheel. >=20 > I recognise that my intended use of MLS is probably not the > focus/intended use of the MLS protocol. But it looks that MLS could > solve my problem without the need to implement a custom protocol for = the > same purpose (which is never a good idea). And the additional feature > are also nice to have. >=20 > Arne >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_FAE2F2B2-A82C-4F46-A375-5C277D52CD88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Arne,

Yes, there is = a way to export secrets from the key schedule. You can find the details = in the =E2=80=9CExporters=E2=80=9D section in the LS protocol draft (https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-ml= s-protocol.md)
I hope that helps, otherwise let = us know.

Thanks

Raphael

On 7 Jan 2020, at 15:08, Arne = Schwabe <arne@rfc2549.org> wrote:

Hey,

this is my first mail to an = IETF mailing list, so please point out my
mistakes to me. = I also want to apologise if this the wrong way to
interact = with standardising working groups.

My = question is if there are any plans to add an interface for keying
material export to MLS?

Let me = explain the background why I am asking this. Some might be
familiar with RFC 5705. RFC 5705 adds a standardised = interface to TLS to
generate/derive keying material from a = TLS session, so it can be used
for example used in the = encryption an UDP datastream.

Since my = background is being a OpenVPN core developer, I will write the
rest a bit from that perspective. OpenVPN basically does a = standard TLS
session and then does a TLS inspired custom = key derivation with normal
messages over that secure = channel to generate the session key for
encryption of data = packets. The TLS standardised key export (RFC5705) is
planned to replace the custom key derivation schema. = Typically, in a VPN
you have have point to point encrypted = links and the VPN server will
decrypt the data and = reencrypt it before sending it to a different
client. And = a compromise of the VPN server compromises all communication
if not secured otherwise.

The = idea is to use MLS to create a VPN, where the VPN server (or some
VPN "cloud") is not fully trusted but mainly would only route = and
forward the (encrypted) IP packets between the = clients. MLS would then
be used to create 2 member groups = for direct communication and multiple
member groups for = multicast/broadcast communication. While also
application = messages could be used then to securely agree on a session
key for the encrypted IP packets, having a keying material = exporter
function in MLS would be much better than to = reinvent the wheel.

I recognise that my = intended use of MLS is probably not the
focus/intended use = of the MLS protocol. But it looks that MLS could
solve my = problem without the need to implement a custom protocol for the
same purpose (which is never a good idea). And the additional = feature
are also nice to have.

Arne

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_FAE2F2B2-A82C-4F46-A375-5C277D52CD88-- From nobody Tue Jan 7 06:33:59 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 8BAE712001A for ; Tue, 7 Jan 2020 06:33:57 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 ZPeM0L-IYavp for ; Tue, 7 Jan 2020 06:33:55 -0800 (PST) Received: from mail.blinkt.de (mail.blinkt.de [IPv6:2001:638:502:390:20c:29ff:fee4:80a3]) (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 E2C3C120881 for ; Tue, 7 Jan 2020 06:33:49 -0800 (PST) Received: from p200300d027039f00e1ac7bdbff5d9437.dip0.t-ipconnect.de ([2003:d0:2703:9f00:e1ac:7bdb:ff5d:9437] helo=styx.fritz.box) by mail.blinkt.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1iopvY-0005dU-66; Tue, 07 Jan 2020 15:33:48 +0100 To: Raphael Robert Cc: mls@ietf.org References: From: Arne Schwabe Autocrypt: addr=arne@rfc2549.org; prefer-encrypt=mutual; keydata= mQINBFusyrsBEAC2Re1MmQjPiutRC8w4vzmHBiPCIRpCPd97rP+ZNdf4DMWlqvSl+Kw+8urP lbh6dQKVpdcUGu9iNcLyPDI4xjatvYXo7VKvI1zVri6qboZ2EypezpyekZXHFS5tv3Dnbf55 S0/MUBQVraIsc3kedeZGizv9alokgGAq3NTACuqFe6plm/+bFLpA51Qfex5FUrSz6bB59tgU LptPLVa10W6mSAL4pusdhUvHEeqxF1+fYsQ3KKEbry8Rnc6F2wExmSyicHOBjRstw7cIqWGG OdsSz68LXEtvXwEzuxv/YlSABTrs2AhouKRedRJx7XbEK+H9GboTRofqX4Ph4uZoJbU5cilV KWen0goCOzR6CohYC/fyjqSEGvhwfmtm3slqj4ZXLpdNrcsgwxmT1Az9S35Vm1Kxcn+RoG+R bHhFvv+gL+cuoiwnhWCozh/Ooy1SlSxqQtWl57WULEr9Pu/JyMwUG82xjQhgu2KhuBz2tvs9 WmQHT/N3ADEbHhtNLB/cXlY8LDwJ6D5diVBix2kaXRj9Ux5ERNDcbGGL5ztrOGyvbDIf2ZSQ 4DQyCYzvv6YMB/08R0tm/C7XCzTawcF0mdRYEkOQmP2H96NV167WxvxZxF6uLRJKQ7B0IxcW riayxsWe4jUmoso7cxB6M5sMtpPN8FoWgmcjacEDM7FCaVd+LQARAQABtB9Bcm5lIFNjaHdh YmUgPGFybmVAcmZjMjU0OS5vcmc+iQJOBBMBCAA4FiEE88wmPb+Azu8xbws3FRhsZwKxRFQF AlusyrsCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQFRhsZwKxRFSc1BAAsILrcC2B B8nC38cI8syth8eX3C1fBcPMN0HfxOc8EuTxb/JTSlkaE+m/EJk4swnDZlQcK1iiadvycZt/ mA6zx5vj9E4uM3IwQfuWNP/Y3HVE4qPImXTgzjJTRBG6w+iACgvgJP/xFfA7gt6/PWnRNDMf FCA7mdgmnATFrj4+DPcJT6/7IhtO4IQ52Xmd1ef0/+fS1pk9NBaEL6Ujf8JhdCjEwcuZ0sU4 QAcA2h98NeDW8WGRL8MdpULVkcpfcW06IReKZGxXy/Qzjh7HIppWqlm5G7u7kktdGWCetzpz 4QD5MSdGDeYO2nCK20N5KnAwPhu4mrWnPFtFnuq3R3fWvFQ8u1qtPsL8+ylXYLaQiOTV3FRV xUGK8qjal/nEX3ZcsDNpFb0o7eQPPnPatJlUl9ntMU/rDzO2xbq/ZBwBU9Y+6oJUMUgxaxZY 6SLe1giNPuFdMGxK5SoODzYVvZIBQkQe+pK74T4mmXtkCxy0Czqq8D+kCu/Ki4mTBXe3tzQm asPHqC4vJ0+MlVDJppBvMzu3PaEKJjVjm+37ck1AdrIVSywbz63oDdoAP4UMfO8hYngo7uhY wc7c3keWrfhpc6R+MLgMb2Jmnv07tIsswLUrN7MOHUrTAiyxW9BJTSpgE7jLw7Qv7204C7n9 1SxQepSkUj2bewoYzUBrCWs0RNa5Ag0EW6zK3QEQAN1LZ11oc6mAIw1Rh7wdG2eBzv/ifbdS 1g0j6wzZ/dIktvfYnkU5QvYwOn7j/dmYw1mlp3sh7Eumwmu4LDEAn93qQPE8hRJePLFThZx9 LP9RrY4D2BS7IAfNxIpoiTkxovIrLOzQqebm3qxzAJk0JTRtYIjneZff0MrYGP/Wnhnb9qIU dmT0UA5K1mynBpHfa31DjWWNSUWohS5245KedzmrrHoBRURcNFZmofk5L5I+Fw7gp22cSIOc 4lDYQI/KFXFdR1EhxZBUX3ITd81gINSzypTFdfmzyvhaFJaz5cHReUvFAG9TEBxpTFgPiXGE 3I+ORzpm8WJK76NTLFicJZ/B90T4p6HXLtoPixhCxY0c/xVta4B1r/sBnOnE0IkNgNMhJh6G 1VqKsXDrWyd96tvONw5cd3xq+SQp0CoXT5A7ExQGg7Lynel/pCJ5JWEWKLWvkKxLFXTUkSJh g5YU9i1uodWsvm0mQltTMooE+/yifhymKp/7tLZuguzQ+vto1jnc96V48DR6yIXB+c9CgMVq DYYk5o+XM5pcxAcyqVxAKQ7DGd/nriiZRUlvdGGgyjR0sJWMhWsWatNycVfruX7Zfz51PlEi 59nlNj5/ZDoXu0EYEhl4hrDLn8RUKjve+1mx6/YA8ixGE+RPOZ5PUNAouw/pXWD2ucRISe+s 8nbtABEBAAGJAjYEGAEIACAWIQTzzCY9v4DO7zFvCzcVGGxnArFEVAUCW6zK3QIbDAAKCRAV GGxnArFEVDUnD/wIkxMssF3u1GHcD+a8A1Iaa477dbMRgPUrsz2k0S601dwK8eJRuQWXOk+e SiwSwXRn3feAfYR2uRaE4lB+wsapkFZU+ZO9VVh1R2qWcetF8JJk/gEpPFYltT9bkdDmCRRx URePkpqlZMYOJSJWI6ZmqCteloV9ed/4XJVgknGISot7u4Umdl3RdNLMGACU3HvodUq6F8T8 n0x6XMvguG0t1G4br0DTL+fabBh50xFxpf5hII5K8Iw1r14GTYgxIMzIfcGWVQ+O2lq5UKsU Dm9o/z11QfxuukCqZWWGoteaW90Z8SynN3RhDr3d3Q/VyZ/xXCQhQ5VprMOyiNmm2EMXPFPr RKOz2ZdTcKIFO1Xj+7GmElnwlIrO2wrGre2fXHeaWbGLiTNlcyWnuEGI56OivfZne1uiY/GV k2W5FlpfJPeBVUKiKhCmp4hOb9mC7ICBSYS1UmCjguR8QSUuKQFiwZ4qi9hnko8b+OT7q8s7 NaYmgD04Jjgth0YKGZxd3Mf3ngg+hSU+B6ngLd0wkLsjzDwU9OJpuW9kTPrx0iwNZfnTU87k YuJAJRfZmG36ySM8JSPXjnkLiHTGc4vtwbS+FGrS6D7nV69+40JbvkKFfHWTyXLjE6+jkOvw ThNCJSdPKjl0MMk2QmY6TGjjrlR+yewhQ2VZfzflJwuAQ2SVog== Message-ID: <5417c110-6a20-f98d-18ff-61d8a8f61492@rfc2549.org> Date: Tue, 7 Jan 2020 15:33:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Keying Material Exporter 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, 07 Jan 2020 14:33:58 -0000 Am 07.01.20 um 15:12 schrieb Raphael Robert: > Hi Arne, > > Yes, there is a way to export secrets from the key schedule. You can > find the details in the “Exporters” section in the LS protocol draft > (https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md) > I hope that helps, otherwise let us know. Thanks. Yes, that looks like what I am looking for. I did not realise that the draft-08 was that outdated compared to the version of GitHub. Arne From nobody Tue Jan 7 15:34:39 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 CAA35120018 for ; Tue, 7 Jan 2020 15:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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] 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 hCFOUsen5UsF for ; Tue, 7 Jan 2020 15:34:35 -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 535A2120020 for ; Tue, 7 Jan 2020 15:34:35 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id l14so641057qvu.12 for ; Tue, 07 Jan 2020 15:34:35 -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=lwM57TPo6tHoBP/Y7QbWyzyIPNazdOqEwirJrtSaTDc=; b=1d5gVl/k3gf4TdIoDdVFbsdr2tcbCKyXZSPmCpiQA1NpqwVwEdgwm8AtUsV2pWcHA0 rdUybrKPNUFqHz0SOQuhczmbIA/P4yXWJ8BFeJc+c4HoXP8+SuAquI8DMGzOld2ONNLz IDbGZafGcH7vPVe8FVpuHLebqJVNepgdWEwDAa8cZDKugmDMYgQcExAHJvS07advuMUe frRMMR+H3A4pqfYu1LQHfxnjhvwPQPtv4ZjT9jdL2v9/joEsy0KDimWXXgj89bgVa/2l Z6c0I7e2vL6ewCTyuHXcRhCjkBxWKeVeH2t+y3kTNWrWjctHZTShoyjAA9Pb3a784xEn jWoQ== 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=lwM57TPo6tHoBP/Y7QbWyzyIPNazdOqEwirJrtSaTDc=; b=f2xtNunv7/6sIey1mzlASFp4NiTKXzsKDJ5Vikm1HE7WH/6lxMezIPbyAoxAPU68qV elJnHARl/Ne0214L/5jZDb+gv8ziopjiigrBIjxizV9Vx65WEE6eRvdEwEWzX55ckJCb glEqYV9gysQGQwAakC9soAuDkoqBAGo5GFMmk6ExcBvOAcwCEJYGVPWgVMnW5dkt41pq ALlxNOeocfEDo8HEHzxyaJ1oqAA6kMA80VJyiDT3TS+BkNfRr9nPN9wvGgNUCu3iRYRf UYY/D/peSQtkrEniBfQzlzs+E3wGcaLGz4D9QdilG8MOYtNqxr4E7YZlsmMFXIoM+vto fdog== X-Gm-Message-State: APjAAAVkoJUJfmUBMOnqkeyP1ZsngtELtLDgvDNv47//m3AG1ycdS1Ax lkb/p1V9ggju5IWkUvOIwBmCWpwfUsivXFury+oNKA== X-Google-Smtp-Source: APXvYqxVao61WlTzhCSgyE8HfypMPoxnZ0euvM5iiWcL0iYWZRxFWRwpwOixcl063lWnjF5VmNng2sYoMUlKyfKchHY= X-Received: by 2002:a05:6214:13ef:: with SMTP id ch15mr1734531qvb.183.1578440074116; Tue, 07 Jan 2020 15:34:34 -0800 (PST) MIME-Version: 1.0 References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> In-Reply-To: From: Richard Barnes Date: Tue, 7 Jan 2020 18:34:14 -0500 Message-ID: To: Brendan McMillion Cc: Raphael Robert , Kelvin Ritland , Michael Rosenberg , Messaging Layer Security WG , Benjamin Beurdouche , Jon Callas Content-Type: multipart/alternative; boundary="000000000000ead1fe059b953798" Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 07 Jan 2020 23:34:39 -0000 --000000000000ead1fe059b953798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Strictly speaking, yes, but only if everyone sees everything. If a member doesn't see one of the two commits, they'll have no idea, and they'll try to decrypt with (potentially) the wrong keys. Indicating the fork in the epoch identifier means that this case fails instead. --Richard On Sat, Jan 4, 2020 at 7:41 PM Brendan McMillion wrote: > Strictly speaking, it=E2=80=99s already possible to detect forks. The con= tent_type > and epoch are left unencrypted, so if you have two messages with > content_type=3DCommit and the same epoch number, that=E2=80=99s a fork. Y= ou can layer > any sort of consensus mechanism you want on top of the protocol to handle > those situations, whether it=E2=80=99s a central server, quorum voting, o= r > something else. > > It seems like the problem you=E2=80=99re trying to solve now is =E2=80=9C= How do we know > which fork a message belongs to, if that message is sent after a fork > happened?=E2=80=9D And intuitively, I would think that this should also b= e dealt > with by whatever consensus mechanism the DS uses. Since the mechanism > exists, and already has to do all the work to keep track of forks and bre= ak > ties. > > On Jan 3, 2020, at 8:55 AM, Richard Barnes wrote: > > Yeah, I'm on the same page here. My objective is to remove the roadblock > without trying to solve the whole problem. As Kelvin points out, there's= a > lot of interesting thinking to be done about how to manage a DAG of state= . > > In chatting with Raphael just now, he proposed a nice framing -- that the > tiebreaker bits could be used for fork *detection*. Even in the case > where the DS is trying to maintain order, there's a chance that things go > wrong. The tiebreaker bits would ensure that people don't try to use the > wrong keys for a message in that case. > > Here's a quick PR implementing the "extended epoch" proposal: > https://github..com/mlswg/mls-protocol/pull/281 > > > > > On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert wrote: > >> I agree with Kelvin=E2=80=99s points in general. Allowing forks might be= an >> interesting goal, but it raises a wealth of new questions. >> On the other hand I think Richard=E2=80=99s proposal of extending the Ep= och ID >> with a commit hash makes sense to detect potential forks. >> >> I=E2=80=99d like to propose that we adopt that as a first step, but only= in the >> context of fork detection for now. This doesn=E2=80=99t preclude us from= building >> on top of that in the future, but we also don=E2=80=99t introduce someth= ing >> dangerous right now. >> >> Raphael >> >> On 3 Jan 2020, at 00:15, Kelvin Ritland < >> kelvinr=3D40google.com@dmarc.ietf.org> wrote: >> >> Not-pseudorandom implies some assumptions, e.g., that each sender would >>> only send one Commit on top of each epoch >> >> This isn't bad imo, it reduces complexity to some extent. I'm somewhat i= n >> favour of a non-pseudorandom tiebreaker if there's no other arguments >> against it. >> >> How many bits of sequence number? >> >> Have we considered using varints? Similar to the CTLS proposal - >> https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.= 1 >> >> >> Other forking considerations, I think there's more involved than just >> changing the epoch identifier: >> >> 1. We'll need merges as well, since forks can lead to inconsistent group >> membership: >> Suppose in epoch 1 a group has A, B, and C >> A removes C in epoch 2A >> B adds D in epoch 2B >> >> We now have two group states 2A with AB and 2B with ABCD - and it's >> unclear which group to use to send with. We could mandate that any clien= t >> MUST send a "merge" commit on it's view of history before sending any >> message. This commit could just be the list of epochs that are being mer= ged >> (+a usual DirectPath update?), and processing it would mean replaying al= l >> proposals up to the common ancestor for those epochs on the common ances= tor. >> >> 2. Forward secrecy issues. >> By allowing forks, devices must now keep the previous epoch around to >> derive possible future forks - but this means we'll be re-using >> init_secret_. A possible solution could be to use the nth app secret fro= m >> the ASTree instead of init_secret_ as the start for the new epoch secret= . >> This ties nicely with using a non-pseudorandom tiebreaker. >> >> 3. Ordering implications >> It's unclear what a sensible ordering strategy is for the DS if we allow >> forking. (simply ensuring that each commit is based on the "current" epo= ch >> isn't well defined since there can be multiple "current" epochs). >> >> By allowing forks the DS need not enforce ordering at all imo.. This >> means that apps need to keep around old epochs, but this is already >> required per (2). A different question is how many we need to keep aroun= d - >> perhaps a TTL or the past N epochs after a topological sort would make >> sense. >> >> Generally I think getting rid of server ordering is good idea: >> - Helps Matrix and general federation use cases >> - A common consistent mutated state for group operations can cause serve= r >> side DB contention in my experience >> >> Forks is one way to remove ordering, and if we need to support it anyway= s >> it's a nice benefit. >> >> On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes wrote: >> >>> Argh, hit send too soon. Continuing below... >>> >>> On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes wrote: >>> >>>> Hey all, >>>> >>>> Resurrecting this thread, as it seems that we never came to resolution >>>> on this question. >>>> >>>> I'd like to propose we scope down and solve a narrower problem, namely >>>> the problem of enabling forks in the group's history. So we're not go= ing >>>> to try to provide any privacy properties, just remove the impediment t= o >>>> forking. This seems like a worthwhile thing to me just because it see= ms >>>> silly to have forking blocked just because of syntactic constraint, in >>>> addition to it likely being necessary for some decentralized use cases >>>> (e.g., Matrix). >>>> >>>> To allow forks, we really just need some "tie breaker" bits in the >>>> epoch ID so that if a given epoch has multiple successors, they end up= with >>>> different epoch IDs. And in order to avoid synchronization, each >>>> participant needs to be able to generate those bits independently. Th= ere >>>> are a couple of basic questions about how to construct the tie breaker= : >>>> >>>> 1. Pseudorandom or not? >>>> - Not-pseudorandom example: tiebreaker =3D commitSenderID >>>> - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) >>>> - Not-pseudorandom implies some assumptions, e.g., that each sender >>>> would only send one Commit on top of each epoch >>>> - Pseudorandom risks random collisions >>>> - Possible to do both: tiebreaker =3D commitSenderID || >>>> H(MLSPlaintext(Commit)) >>>> >>>> 2. How many bits of tiebreaker? >>>> >>> - Non-pseudorandom size will be dictated by what we include >>> - Pseudorandom size will be dictated by tolerable collision probabili= ty >>> - Probability of collision ~ (number of forks per seq no) / 2^{number >>> of bits} >>> >>> 3. How many bits of sequence number? >>> - DS might want to see sequence to help enforce ordering >>> - Probably want this big enough to avoid wrapping. >>> >>> (Note that this is a value that goes in every message, so there's some >>> incentive to keep things small.) >>> >>> Personally, my proposal would be something like: >>> >>> struct { >>> uint64 sequence_number; >>> uint64 commit_hash; // H(MLSPlaintext(Commit)) >>> } EpochID; >>> >>> That seems to strike a reasonable balance between low collision >>> probability (~2^-64) and a reasonably small identifier. If 128 bits is >>> good enough for IPv6, it can be good enough for us :) >>> >>> Does that seem workable to folks? >>> >>> --Richard >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche < >>>> benjamin.beurdouche@inria..fr > wrote: >>>> >>>>> >>>>> > On Apr 26, 2019, at 9:26 PM, Jon Callas wrote: >>>>> > >>>>> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg >>>>> wrote: >>>>> >> >>>>> >> So why not remove epoch entirely? >>>>> > >>>>> > An epoch lets you deal with things happening neither too often nor >>>>> not often enough. Presume there is a client that is either malicious = or >>>>> just stupid. You want to keep it from forcing a rekey every 100=C2=B5= s. You want >>>>> to force a rekey every so often. Hence epochs. Yeah, picking the righ= t >>>>> epoch size is an exercise left to the reader. >>>>> >>>>> You can=E2=80=99t use the epoch number for that as it is just global = counter >>>>> for group operations, we will have to keep track of the latest group >>>>> operation =E2=80=9Ctimestamp=E2=80=9D for each member within the grou= p state to check >>>>> =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations = you described. >>>>> >>>>> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I >>>>> feel like having more than 2^32 group operations over the lifetime of= a >>>>> group is not unrealistic in certain extreme use cases, especially wit= h >>>>> large groups forcing PCS for application messages by triggering an up= date >>>>> after each app message... >>>>> >>>>> We could remove the epoch number if we really want but it is necessar= y >>>>> to give the Delivery Service some ordering information (unpredictable= or >>>>> not is an interesting question) to handle concurrent handshake messag= es >>>>> which is, I believe, the main current goal of that information. >>>>> >>>>> Benjamin >>>>> >>>> _______________________________________________ >>> 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 > > > --000000000000ead1fe059b953798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Strictly speaking, yes, but only if everyone sees eve= rything.=C2=A0 If a member doesn't see one of the two commits, they'= ;ll have no idea, and they'll try to decrypt with (potentially) the wro= ng keys.=C2=A0 Indicating the fork in the epoch identifier means that this = case fails instead.

--Richard

On Sat, Jan 4= , 2020 at 7:41 PM Brendan McMillion <brendan@cloudflare.com> wrote:
Stri= ctly speaking, it=E2=80=99s already possible to detect forks. The content_t= ype and epoch are left unencrypted, so if you have two messages with conten= t_type=3DCommit and the same epoch number, that=E2=80=99s a fork. You can l= ayer any sort of consensus mechanism you want on top of the protocol to han= dle those situations, whether it=E2=80=99s a central server, quorum voting,= or something else.

It seems like the problem you=E2=80= =99re trying to solve now is =E2=80=9CHow do we know which fork a message b= elongs to, if that message is sent after a fork happened?=E2=80=9D And intu= itively, I would think that this should also be dealt with by whatever cons= ensus mechanism the DS uses. Since the mechanism exists, and already has to= do all the work to keep track of forks and break ties.

On Jan 3, 2020, at 8:55 AM, Richar= d Barnes <rlb@ipv.sx= > wrote:

Yeah, I'm on the same p= age here. My objective is to remove the roadblock without trying to solve t= he whole problem.=C2=A0 As Kelvin points out, there's a lot of interest= ing thinking to be done about how to manage a DAG of state.

<= /div>
In chatting with Raphael just now, he proposed a nice framing -- = that the tiebreaker bits could be used for fork *detection*.=C2=A0=C2=A0 Ev= en in the case where the DS is trying to maintain order, there's a chan= ce that things go wrong.=C2=A0 The tiebreaker bits would ensure that people= don't try to use the wrong keys for a message in that case.
=
Here's a quick PR implementing the "extended epoch&= quot; proposal:



On Fri, Jan 3, 2020 at 10:32 AM Raphael R= obert <raphael@wir= e.com> wrote:
I agree with Kelvin=E2=80=99s points in general. Allowing forks m= ight be an interesting goal, but it raises a wealth of new questions.
O= n the other hand I think Richard=E2=80=99s proposal of extending the Epoch = ID with a commit hash makes sense to detect potential forks.

=
I=E2=80=99d like to propose that we adopt that as a first step, = but only in the context of fork detection for now. This doesn=E2=80=99t pre= clude us from building on top of that in the future, but we also don=E2=80= =99t introduce something dangerous right now.

Raph= ael

On 3 Jan 2020, at 00:15, Kel= vin Ritland <kelvinr=3D40google.com@dmarc.ietf.org> wrote:
<= br>
Not-ps= eudorandom implies some assumptions, e.g., that each sender would only send= one Commit on top of each epoch
This isn't bad imo, i= t reduces complexity to some extent. I'm somewhat in favour of a non-ps= eudorandom tiebreaker if there's no other arguments against it.

How man= y bits of sequence number?
Have we considered using varint= s? Similar to the CTLS proposal - https://tool= s.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1


Other forking considerations, I = think there's more involved than just changing the epoch identifier:

1. We'll need merges as well, since forks = can lead to inconsistent group membership:
Suppose in epoch = 1 a=C2=A0group has A, B, and C
A removes C in epoch 2A
= B adds D in epoch 2B

We now have two group states = 2A with AB and 2B with ABCD - and it's unclear which group to use to se= nd with. We could mandate that any client MUST send a "merge" com= mit on it's view of history before sending any message. This commit cou= ld just be the list of epochs that are being merged (+a usual DirectPath u= pdate?), and processing it would mean replaying all proposals up to the com= mon ancestor for those epochs on the common ancestor.
=

2. Forward secrecy issues.
By all= owing forks, devices must now keep the previous epoch around to derive poss= ible future forks - but this means we'll be re-using init_secret_. A po= ssible solution could be to use the nth app secret from the ASTree instead = of init_secret_ as the start=C2=A0for the new epoch secret. This ties nicel= y with using a non-pseudorandom=C2=A0tiebreaker.

3. Ordering implications
It's unclear what a sensible orde= ring strategy is for the DS if we allow forking. (simply ensuring that each= commit is based on the "current" epoch isn't well defined si= nce there can be multiple "current" epochs).

=
By allowing forks the DS=C2=A0need=C2=A0not=C2=A0enforce ordering at a= ll imo.. This means that apps need to keep around old epochs, but this is a= lready required=C2=A0per (2). A different question is how many we need to k= eep around - perhaps a TTL or the past N epochs after a topological sort wo= uld make sense.

Generally I think getting rid of s= erver ordering is good idea:
- Helps Matrix and general federatio= n use cases
- A common consistent mutated state for group operati= ons can cause server side DB contention in my experience

Forks is one way to remove ordering, and if we need to support it an= yways it's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes <rlb@ipv.sx> wrote:
Argh, hit send too soon.=C2=A0 Continuing below...

<= div class=3D"gmail_quote">
On Thu, Jan= 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

Resurrecting this thread, as it seems that we never came to resolution o= n this question.

I'd like to propose we sc= ope down and solve a narrower problem, namely the problem of enabling forks= in the group's history.=C2=A0 So we're not going to try to provide= any privacy properties, just remove the impediment to forking.=C2=A0 This = seems like a worthwhile thing to me just because it seems silly to have for= king blocked just because of syntactic constraint, in addition to it likely= being necessary for some decentralized use cases (e.g., Matrix).

To allow forks, we really just need some "tie breaker&= quot; bits in the epoch ID so that if a given epoch has multiple successors= , they end up with different epoch IDs.=C2=A0 And in order to avoid synchro= nization, each participant needs to be able to generate those bits independ= ently.=C2=A0 There are a couple of basic questions about how to construct t= he tie breaker:

1. Pseudorandom or not?
= =C2=A0 - Not-pseudorandom example: tiebreaker =3D commitSenderID
<= div>=C2=A0 - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit))
=C2=A0 - Not-pseudorandom implies some assumptions, e.g., that eac= h sender would only send one Commit on top of each epoch
=C2=A0 -= Pseudorandom risks random collisions
=C2=A0 - Possible to do bot= h: tiebreaker =3D commitSenderID || H(MLSPlaintext(Commit))

<= /div>
2. How many bits of tiebreaker?
=C2= =A0 - Non-pseudorandom size will be dictated by what we include
= =C2=A0 - Pseudorandom size will be dictated by tolerable collision probabil= ity
=C2=A0 - Probability of collision ~ (number of forks per seq = no) / 2^{number of bits}

3. How many bits of seque= nce number?
- DS might want to see sequence to help enforce order= ing
- Probably want this big enough to avoid wrapping.
<= div>
(Note that this is a value that goes in every message, s= o there's some incentive to keep things small.)

Personally, my proposal would be something like:

=
struct {
=C2=A0 uint64 sequence_number;
=C2=A0= uint64 commit_hash; // H(MLSPlaintext(Commit))
} EpochID;

That seems to strike a reasonable balance betwee= n low collision probability (~2^-64) and a reasonably small identifier.=C2= =A0 If 128 bits is good enough for IPv6, it can be good enough for us :)

Does that seem workable to folks?

--Richard

=C2=A0





On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beu= rdouche <benjamin.beurdouche@inria..fr> wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:<= br> >>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor not= often enough. Presume there is a client that is either malicious or just s= tupid. You want to keep it from forcing a rekey every 100=C2=B5s. You want = to force a rekey every so often. Hence epochs. Yeah, picking the right epoc= h size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global counte= r for group operations, we will have to keep track of the latest group oper= ation =E2=80=9Ctimestamp=E2=80=9D for each member within the group state to= check =E2=80=9Cupdate frequency=E2=80=9D and handle some of the situations= you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel = like having more than 2^32 group operations over the lifetime of a group is= not unrealistic in certain extreme use cases, especially with large groups= forcing PCS for application messages by triggering an update after each ap= p message...

We could remove the epoch number if we really want but it is necessary to g= ive the Delivery Service some ordering information (unpredictable or not is= an interesting question) to handle concurrent handshake messages which is,= I believe, the main current goal of that information.

Benjamin
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div>
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div> --000000000000ead1fe059b953798-- From nobody Wed Jan 8 19:18:04 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 8CACA120077 for ; Wed, 8 Jan 2020 19:18:02 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 YtZ4_She33wd for ; Wed, 8 Jan 2020 19:17:59 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 EDEAE12004F for ; Wed, 8 Jan 2020 19:17:58 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id s94so441352pjc.1 for ; Wed, 08 Jan 2020 19:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tpv3dhn3ln3NGb2wqWbYhy0wDDEn0Jeb9HpghYooMVA=; b=S5nG3P/ZawaGpzMq8Jni7WhyAKe7WmCDkQkAx04waZjsRLVNfXJ1EHOGQxZx+s/70W A/sjM25GhLK2TCt+2HrLEsAQ47ml8e25mK3dxYfEKahhiaagiY/uZpsOn0lL4KJoO1yF G2I82+B9zSGj5slRwbRPNFeklkgOpyIFPRxqQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Tpv3dhn3ln3NGb2wqWbYhy0wDDEn0Jeb9HpghYooMVA=; b=F6dg4d17pdqo/tANtWUWHNrq7XZZx49okheFU3tSxmpsnfWWfPY/oQdwPd8PjJIGni h1Ky9QdBuqG31qNfx1mOUbadwLAwbzVHii7AY5gyBD3ZEY6DHe5HaK/Bcz7NUgDXn9iD AkZ8hmguTc3+3RQsQ++dqXmWT+KcGHdpBk300WuXf6B0neUmfJlENITdSAYABfUvIapS 2bk49g4MyOp575BAM9vSpst2vY9gz8+42Ah7FxFWicaUsjgcGCfokt69p9c80iUvJMlm GJqJfJliXZnLxBfx8sWwZhnwDZS5xe/PBzJExHg23PNAuUjG+jTg1o0O2vLdwi4onu3j cCvA== X-Gm-Message-State: APjAAAWDU6AZEM+mmYkPXPrkznLMYalbxT1S5JZuIIaGGpgC4ZZW9xNx ie2eowihjlr4bwHK8SVV+HRajw== X-Google-Smtp-Source: APXvYqw1GCsWTUuH74w9yCZ0fNYb01d1myRTjHAomUasnIBtwTaEKUU5ba7kwJxWoCBR7tnBH04GBQ== X-Received: by 2002:a17:902:9f92:: with SMTP id g18mr9001864plq.161.1578539878136; Wed, 08 Jan 2020 19:17:58 -0800 (PST) Received: from [192.168.7.29] (c-73-15-208-167.hsd1.ca.comcast.net. [73.15.208.167]) by smtp.gmail.com with ESMTPSA id b17sm5357390pfb.146.2020.01.08.19.17.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 19:17:57 -0800 (PST) From: Brendan McMillion Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B1E4EA24-7B8E-485A-BC34-D723CD1133AA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 8 Jan 2020 19:17:54 -0800 In-Reply-To: Cc: Raphael Robert , Kelvin Ritland , Michael Rosenberg , Messaging Layer Security WG , Benjamin Beurdouche , Jon Callas To: Richard Barnes References: <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <80ABB08C-AEE6-4E94-A972-4983E12241B6@inria.fr> <4E8A7725-EBC6-4BD4-8D3A-5C52D4712D39@wire.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Unpredictable epochs? 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, 09 Jan 2020 03:18:03 -0000 --Apple-Mail=_B1E4EA24-7B8E-485A-BC34-D723CD1133AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Whether the channel is lossy or not doesn=E2=80=99t change what I=E2=80=99= m saying. In an eventually consistent deployment, there has to be some = mechanism for detecting and managing forks in the members' state. The = question is whether the mechanism for telling which messages belong to = which fork should be part of the consensus mechanism, which knows best = how/why forks will occur, or part of the protocol, which doesn=E2=80=99t = know why forks will occur. To make my point, the PR you=E2=80=99ve opened uses a truncated hash of = the last Commit message. This is not strong enough for some use-cases = (where we might worry about adversary-generated collisions), and a waste = of bandwidth in many other use-cases (where forks may never occur). > On Jan 7, 2020, at 3:34 PM, Richard Barnes wrote: >=20 > Strictly speaking, yes, but only if everyone sees everything. If a = member doesn't see one of the two commits, they'll have no idea, and = they'll try to decrypt with (potentially) the wrong keys. Indicating = the fork in the epoch identifier means that this case fails instead. >=20 > --Richard >=20 > On Sat, Jan 4, 2020 at 7:41 PM Brendan McMillion = > wrote: > Strictly speaking, it=E2=80=99s already possible to detect forks. The = content_type and epoch are left unencrypted, so if you have two messages = with content_type=3DCommit and the same epoch number, that=E2=80=99s a = fork. You can layer any sort of consensus mechanism you want on top of = the protocol to handle those situations, whether it=E2=80=99s a central = server, quorum voting, or something else. >=20 > It seems like the problem you=E2=80=99re trying to solve now is =E2=80=9C= How do we know which fork a message belongs to, if that message is sent = after a fork happened?=E2=80=9D And intuitively, I would think that this = should also be dealt with by whatever consensus mechanism the DS uses. = Since the mechanism exists, and already has to do all the work to keep = track of forks and break ties. >=20 >> On Jan 3, 2020, at 8:55 AM, Richard Barnes > wrote: >>=20 >> Yeah, I'm on the same page here. My objective is to remove the = roadblock without trying to solve the whole problem. As Kelvin points = out, there's a lot of interesting thinking to be done about how to = manage a DAG of state. >>=20 >> In chatting with Raphael just now, he proposed a nice framing -- that = the tiebreaker bits could be used for fork *detection*. Even in the = case where the DS is trying to maintain order, there's a chance that = things go wrong. The tiebreaker bits would ensure that people don't try = to use the wrong keys for a message in that case. >>=20 >> Here's a quick PR implementing the "extended epoch" proposal: >> https://github..com/mlswg/mls-protocol/pull/281 = >>=20 >>=20 >>=20 >> On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert > wrote: >> I agree with Kelvin=E2=80=99s points in general. Allowing forks might = be an interesting goal, but it raises a wealth of new questions. >> On the other hand I think Richard=E2=80=99s proposal of extending the = Epoch ID with a commit hash makes sense to detect potential forks. >>=20 >> I=E2=80=99d like to propose that we adopt that as a first step, but = only in the context of fork detection for now. This doesn=E2=80=99t = preclude us from building on top of that in the future, but we also = don=E2=80=99t introduce something dangerous right now. >>=20 >> Raphael >>=20 >>> On 3 Jan 2020, at 00:15, Kelvin Ritland = > wrote: >>>=20 >>> Not-pseudorandom implies some assumptions, e.g., that each sender = would only send one Commit on top of each epoch >>> This isn't bad imo, it reduces complexity to some extent. I'm = somewhat in favour of a non-pseudorandom tiebreaker if there's no other = arguments against it. >>>=20 >>> How many bits of sequence number? >>> Have we considered using varints? Similar to the CTLS proposal - = https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.section.3.1 = >>>=20 >>>=20 >>> Other forking considerations, I think there's more involved than = just changing the epoch identifier: >>>=20 >>> 1. We'll need merges as well, since forks can lead to inconsistent = group membership: >>> Suppose in epoch 1 a group has A, B, and C >>> A removes C in epoch 2A >>> B adds D in epoch 2B >>>=20 >>> We now have two group states 2A with AB and 2B with ABCD - and it's = unclear which group to use to send with. We could mandate that any = client MUST send a "merge" commit on it's view of history before sending = any message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor. >>>=20 >>> 2. Forward secrecy issues. >>> By allowing forks, devices must now keep the previous epoch around = to derive possible future forks - but this means we'll be re-using = init_secret_. A possible solution could be to use the nth app secret = from the ASTree instead of init_secret_ as the start for the new epoch = secret. This ties nicely with using a non-pseudorandom tiebreaker. >>>=20 >>> 3. Ordering implications >>> It's unclear what a sensible ordering strategy is for the DS if we = allow forking. (simply ensuring that each commit is based on the = "current" epoch isn't well defined since there can be multiple "current" = epochs). >>>=20 >>> By allowing forks the DS need not enforce ordering at all imo.. This = means that apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense. >>>=20 >>> Generally I think getting rid of server ordering is good idea: >>> - Helps Matrix and general federation use cases >>> - A common consistent mutated state for group operations can cause = server side DB contention in my experience >>>=20 >>> Forks is one way to remove ordering, and if we need to support it = anyways it's a nice benefit. >>>=20 >>> On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes > wrote: >>> Argh, hit send too soon. Continuing below... >>>=20 >>> On Thu, Jan 2, 2020 at 3:38 PM Richard Barnes > wrote: >>> Hey all, >>>=20 >>> Resurrecting this thread, as it seems that we never came to = resolution on this question. >>>=20 >>> I'd like to propose we scope down and solve a narrower problem, = namely the problem of enabling forks in the group's history. So we're = not going to try to provide any privacy properties, just remove the = impediment to forking. This seems like a worthwhile thing to me just = because it seems silly to have forking blocked just because of syntactic = constraint, in addition to it likely being necessary for some = decentralized use cases (e.g., Matrix). >>>=20 >>> To allow forks, we really just need some "tie breaker" bits in the = epoch ID so that if a given epoch has multiple successors, they end up = with different epoch IDs. And in order to avoid synchronization, each = participant needs to be able to generate those bits independently. = There are a couple of basic questions about how to construct the tie = breaker: >>>=20 >>> 1. Pseudorandom or not? >>> - Not-pseudorandom example: tiebreaker =3D commitSenderID >>> - Pseudorandom example: tiebreaker =3D H(MLSPlaintext(Commit)) >>> - Not-pseudorandom implies some assumptions, e.g., that each = sender would only send one Commit on top of each epoch >>> - Pseudorandom risks random collisions >>> - Possible to do both: tiebreaker =3D commitSenderID || = H(MLSPlaintext(Commit)) >>>=20 >>> 2. How many bits of tiebreaker? >>> - Non-pseudorandom size will be dictated by what we include >>> - Pseudorandom size will be dictated by tolerable collision = probability >>> - Probability of collision ~ (number of forks per seq no) / = 2^{number of bits} >>>=20 >>> 3. How many bits of sequence number? >>> - DS might want to see sequence to help enforce ordering >>> - Probably want this big enough to avoid wrapping. >>>=20 >>> (Note that this is a value that goes in every message, so there's = some incentive to keep things small.) >>>=20 >>> Personally, my proposal would be something like: >>>=20 >>> struct { >>> uint64 sequence_number; >>> uint64 commit_hash; // H(MLSPlaintext(Commit)) >>> } EpochID; >>>=20 >>> That seems to strike a reasonable balance between low collision = probability (~2^-64) and a reasonably small identifier. If 128 bits is = good enough for IPv6, it can be good enough for us :) >>>=20 >>> Does that seem workable to folks? >>>=20 >>> --Richard >>>=20 >>> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, Apr 26, 2019 at 4:18 PM Benjamin Beurdouche = > = wrote: >>>=20 >>> > On Apr 26, 2019, at 9:26 PM, Jon Callas > wrote: >>> >=20 >>> >> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg = > wrote: >>> >>=20 >>> >> So why not remove epoch entirely? >>> >=20 >>> > An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader. >>>=20 >>> You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described. >>>=20 >>> Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and = I feel like having more than 2^32 group operations over the lifetime of = a group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message... >>>=20 >>> We could remove the epoch number if we really want but it is = necessary to give the Delivery Service some ordering information = (unpredictable or not is an interesting question) to handle concurrent = handshake messages which is, I believe, the main current goal of that = information. >>>=20 >>> Benjamin >>> _______________________________________________ >>> 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 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 --Apple-Mail=_B1E4EA24-7B8E-485A-BC34-D723CD1133AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Whether the channel is lossy or not doesn=E2=80=99t change = what I=E2=80=99m saying. In an eventually consistent deployment, there = has to be some mechanism for detecting and managing forks in the = members' state. The question is whether the mechanism for telling which = messages belong to which fork should be part of the consensus mechanism, = which knows best how/why forks will occur, or part of the protocol, = which doesn=E2=80=99t know why forks will occur.

To make my point, the PR you=E2=80=99ve = opened uses a truncated hash of the last Commit message. This is not = strong enough for some use-cases (where we might worry about = adversary-generated collisions), and a waste of bandwidth in many other = use-cases (where forks may never occur).

On Jan = 7, 2020, at 3:34 PM, Richard Barnes <rlb@ipv.sx> wrote:

Strictly speaking, yes, but only if everyone = sees everything.  If a member doesn't see one of the two commits, = they'll have no idea, and they'll try to decrypt with (potentially) the = wrong keys.  Indicating the fork in the epoch identifier means that = this case fails instead.

--Richard

On Sat, Jan 4, 2020 at 7:41 PM Brendan McMillion = <brendan@cloudflare.com> wrote:
Strictly speaking, it=E2=80=99s already possible = to detect forks. The content_type and epoch are left unencrypted, so if = you have two messages with content_type=3DCommit and the same epoch = number, that=E2=80=99s a fork. You can layer any sort of consensus = mechanism you want on top of the protocol to handle those situations, = whether it=E2=80=99s a central server, quorum voting, or something = else.

It seems like = the problem you=E2=80=99re trying to solve now is =E2=80=9CHow do we = know which fork a message belongs to, if that message is sent after a = fork happened?=E2=80=9D And intuitively, I would think that this should = also be dealt with by whatever consensus mechanism the DS uses. Since = the mechanism exists, and already has to do all the work to keep track = of forks and break ties.

On Jan 3, 2020, at 8:55 AM, Richard Barnes = <rlb@ipv.sx> wrote:

Yeah, I'm on the = same page here. My objective is to remove the roadblock without trying = to solve the whole problem.  As Kelvin points out, there's a lot of = interesting thinking to be done about how to manage a DAG of = state.

In = chatting with Raphael just now, he proposed a nice framing -- that the = tiebreaker bits could be used for fork *detection*.   Even in = the case where the DS is trying to maintain order, there's a chance that = things go wrong.  The tiebreaker bits would ensure that people = don't try to use the wrong keys for a message in that case.

Here's a quick PR = implementing the "extended epoch" proposal:
https://github..com/mlswg/mls-protocol/pull/281



On Fri, Jan 3, 2020 at 10:32 AM Raphael Robert = <raphael@wire.com> wrote:
I agree with = Kelvin=E2=80=99s points in general. Allowing forks might be an = interesting goal, but it raises a wealth of new questions.
On the other hand I think Richard=E2=80=99s proposal of = extending the Epoch ID with a commit hash makes sense to detect = potential forks.

I=E2=80=99d like to propose that we adopt that as a first = step, but only in the context of fork detection for now. This doesn=E2=80=99= t preclude us from building on top of that in the future, but we also = don=E2=80=99t introduce something dangerous right now.

Raphael

On 3 Jan 2020, at 00:15, Kelvin Ritland <kelvinr=3D40google.com@dmarc.ietf.org> wrote:

Not-pseudorandom implies some assumptions, e.g., = that each sender would only send one Commit on top of each = epoch
This isn't bad imo, it reduces = complexity to some extent. I'm somewhat in favour of a non-pseudorandom = tiebreaker if there's no other arguments against it.

How many bits of sequence = number?
Have we considered using varints? = Similar to the CTLS proposal - https://tools.ietf.org/id/draft-rescorla-tls-ctls-02.html#rfc.s= ection.3.1


Other forking = considerations, I think there's more involved than just changing the = epoch identifier:

1. We'll need merges as well, since forks can lead to = inconsistent group membership:
Suppose in epoch 1 a group has A, B, and C
A removes C in epoch 2A
B adds D in = epoch 2B

We = now have two group states 2A with AB and 2B with ABCD - and it's unclear = which group to use to send with. We could mandate that any client MUST = send a "merge" commit on it's view of history before sending any = message. This commit could just be the list of epochs that are being = merged (+a usual DirectPath update?), and processing it would mean = replaying all proposals up to the common ancestor for those epochs on = the common ancestor.

2. Forward secrecy issues.
By allowing = forks, devices must now keep the previous epoch around to derive = possible future forks - but this means we'll be re-using init_secret_. A = possible solution could be to use the nth app secret from the ASTree = instead of init_secret_ as the start for the new epoch secret. This = ties nicely with using a non-pseudorandom tiebreaker.

3. = Ordering implications
It's unclear what a sensible = ordering strategy is for the DS if we allow forking. (simply ensuring = that each commit is based on the "current" epoch isn't well defined = since there can be multiple "current" epochs).

By allowing forks the = DS need not enforce ordering at all imo.. This means that = apps need to keep around old epochs, but this is already = required per (2). A different question is how many we need to keep = around - perhaps a TTL or the past N epochs after a topological sort = would make sense.

Generally I think getting rid of server ordering is good = idea:
- Helps Matrix and general federation use = cases
- A common consistent mutated state for group = operations can cause server side DB contention in my = experience

Forks= is one way to remove ordering, and if we need to support it anyways = it's a nice benefit.

On Thu, Jan 2, 2020 at 12:52 PM Richard Barnes = <rlb@ipv.sx> wrote:
Argh, hit send too soon.  Continuing = below...

On Thu, Jan = 2, 2020 at 3:38 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

Resurrecting this thread, as it seems that we never came to = resolution on this question.

I'd like to propose we scope down and = solve a narrower problem, namely the problem of enabling forks in the = group's history.  So we're not going to try to provide any privacy = properties, just remove the impediment to forking.  This seems like = a worthwhile thing to me just because it seems silly to have forking = blocked just because of syntactic constraint, in addition to it likely = being necessary for some decentralized use cases (e.g., = Matrix).

To = allow forks, we really just need some "tie breaker" bits in the epoch ID = so that if a given epoch has multiple successors, they end up with = different epoch IDs.  And in order to avoid synchronization, each = participant needs to be able to generate those bits independently.  = There are a couple of basic questions about how to construct the tie = breaker:

1. = Pseudorandom or not?
  - Not-pseudorandom = example: tiebreaker =3D commitSenderID
  - Pseudorandom example: tiebreaker =3D = H(MLSPlaintext(Commit))
  - Not-pseudorandom = implies some assumptions, e.g., that each sender would only send one = Commit on top of each epoch
  - Pseudorandom = risks random collisions
  - Possible to do = both: tiebreaker =3D commitSenderID || H(MLSPlaintext(Commit))

2. How many bits of = tiebreaker?
  - = Non-pseudorandom size will be dictated by what we include
  - Pseudorandom size will be dictated by tolerable = collision probability
  - Probability of = collision ~ (number of forks per seq no) / 2^{number of bits}

3. How many bits of = sequence number?
- DS might want to see sequence to = help enforce ordering
- Probably want this big = enough to avoid wrapping.

(Note that this is a value that goes in = every message, so there's some incentive to keep things small.)

Personally, my proposal would be something like:

struct {
  uint64 = sequence_number;
  uint64 commit_hash; // = H(MLSPlaintext(Commit))
} = EpochID;

That seems to strike a reasonable balance between low = collision probability (~2^-64) and a reasonably small identifier.  = If 128 bits is good enough for IPv6, it can be good enough for us = :)

Does that = seem workable to folks?

--Richard

 





On Fri, Apr 26, 2019 at 4:18 PM = Benjamin Beurdouche <benjamin.beurdouche@inria..fr> = wrote:

> On Apr 26, 2019, at 9:26 PM, Jon Callas <jon@callas.org> wrote:
>
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <micro@fastmail.com> wrote:
>>
>> So why not remove epoch entirely?
>
> An epoch lets you deal with things happening neither too often nor = not often enough. Presume there is a client that is either malicious or = just stupid. You want to keep it from forcing a rekey every 100=C2=B5s. = You want to force a rekey every so often. Hence epochs. Yeah, picking = the right epoch size is an exercise left to the reader.

You can=E2=80=99t use the epoch number for that as it is just global = counter for group operations, we will have to keep track of the latest = group operation =E2=80=9Ctimestamp=E2=80=9D for each member within the = group state to check =E2=80=9Cupdate frequency=E2=80=9D and handle some = of the situations you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I = feel like having more than 2^32 group operations over the lifetime of a = group is not unrealistic in certain extreme use cases, especially with = large groups forcing PCS for application messages by triggering an = update after each app message...

We could remove the epoch number if we really want but it is necessary = to give the Delivery Service some ordering information (unpredictable or = not is an interesting question) to handle concurrent handshake messages = which is, I believe, the main current goal of that information.

Benjamin
_______________________________________________
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


= --Apple-Mail=_B1E4EA24-7B8E-485A-BC34-D723CD1133AA-- From nobody Sun Jan 12 15:05:24 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 79013120071 for ; Sun, 12 Jan 2020 15:05:22 -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 TTo642zm_gEr for ; Sun, 12 Jan 2020 15:05:21 -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 12C84120048 for ; Sun, 12 Jan 2020 15:05:21 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id x1so3275274qvr.8 for ; Sun, 12 Jan 2020 15:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ygRGO4QlOshzlP2ynftnEmUb/W0HYO7x8Tbhwrk/QTo=; b=nFtmvl4lsbi9JGdm8I3E+CJEKRmc1PoA3O1N6WT5Y3P2F1hn44g++TLx07L7PIMyoB +srpMKv07axp2hjyJbNWLRDwFhDbZcjZ/rwWtfpY2oxKBSsek0hgcvPH3g9/+GorndR0 9Qas/+KiFNe1zLmWfahFdr4AYFB041sqPrKBz/a1GdR39KqXG8JdtrUkmSL0KUCQmGcR 1NF9RyfkhpZXhbFLqgp/QfT+eZSyoJTGUY/jUjpbUnlBlcZqJdlpc6CWVJCS62YYIajh Bmfu7Z5QO7ukX6PqveCLShdhtwc6tgj8rRiSMOH4K+Ro2mbgJXtYf2Eax8YjexH4mEZO iceg== 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=ygRGO4QlOshzlP2ynftnEmUb/W0HYO7x8Tbhwrk/QTo=; b=dDHHl6KStA19NzpGuGAqkydiDgTkno/ND12LNPVt3lJZjuwyfzxckYJ+IsSkJAs/Kb YrmwIWNboW1sEKBhvgYo6L/wYbr+G7sEx71vJplC9261IIhKfPdnOT+ylpL7ohUsinn4 4/M5AHrUbgk5wJGpVkCqC5n9zeuH+WHhWA9UBdjQ22dqqLHro9c7EtWZrmS5bZv0I496 PZ8/vN10QT07nNnQBbJAWzSbAp3grM0mzfIthSwwxKlKPTgSjkaOxkdK6Y4atjru/bdy XaEoyb39tfyvadlHXO9hyfnvci0cqfHls8aYaegGtlcjZEi5RLS3cmnUE/T3LLTpyuml WZxg== X-Gm-Message-State: APjAAAVOYZMwVaYq+xV1h3NA878+iH8JNi382GefldwrfmJGHrYkc4F0 6t1q5+XlZedrHeghALA8gsOilSgQk5z7P7ceVWcbrsBdRCw= X-Google-Smtp-Source: APXvYqxXSwNrip9gmTpkU9LUq1ietfjgyVL+DeRckAo4QwxNGYRgIdJ+gvHHEcZet5vZlweJEtUhPZKpk7Rf6oNF7n8= X-Received: by 2002:a05:6214:1348:: with SMTP id b8mr9006832qvw.137.1578870319877; Sun, 12 Jan 2020 15:05:19 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Sun, 12 Jan 2020 18:05:05 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000009024c8059bf964bb" Archived-At: Subject: [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: Sun, 12 Jan 2020 23:05:22 -0000 --0000000000009024c8059bf964bb Content-Type: text/plain; charset="UTF-8" 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: https://doodle.com/poll/bg2q65phrvfip5zb 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. --Richard --0000000000009024c8059bf964bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to have some weekly calls to make faster= progress on our outstanding PRs.=C2=A0 Here's a Doodle to find a good = time:


<= div>I believe these will need to be official Virtual Interims per IETF proc= ess.=C2=A0 Chairs, I assume you can do whatever announcements are necessary= once we pick a time.

--Richard
--0000000000009024c8059bf964bb-- From nobody Mon Jan 13 08:51:11 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 9061412085D for ; Mon, 13 Jan 2020 08:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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] 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 J1fWjzzMDnGF for ; Mon, 13 Jan 2020 08:51:07 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 C1179120867 for ; Mon, 13 Jan 2020 08:51:07 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id 21so9123242qky.4 for ; Mon, 13 Jan 2020 08:51:07 -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; bh=umKynEOOZ+aSvewQ+x9quoXFa0BDeqFJEhWd7uoZJeA=; b=ppki2nHbceuV0DM8hiC+h71HL8BumKBQ4s2xZxnmE1Opoh4foJ8+Ot0RchPI4HWr8m W+DJ60gEZn+LoS/kmEiI0zcYQLKqz4Wt8fST8EsscoPBI1pbd7w7TB7ly/gITO7NsuUi wJRZGTyGvTOF0xGIdZckkaGjudEwp+aqkf4Bp51jstKW/o6dBb9ZDUKO6kvvA1lCiE+l ivgqREkPsp4GDvr7SLkgw0G2OBJak5rWV0TBvhLmYKsnb/n5TwX3izC7moCPfgMzKASe bJSSFGyzaRc2xXQgQgNXEtvfJtn01H+A48eABG0sjA3r0R6hxiuWZKYbOieIeY6eE6GN KCQA== 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; bh=umKynEOOZ+aSvewQ+x9quoXFa0BDeqFJEhWd7uoZJeA=; b=RufF0ziuvP/ujVSDEQr7b0B1Sbam+omqkfH9c+oVL3dj34aSE59sg+ba8h2v6wY5my eJ3agyT8k+5aDo79aZ/5/gZoifNsJ3tNMlPqumKHE2X66ken0xb43E37zE6lmD04fbWw qslEM+0xW3e0dqLcqcFfC/ND/OfKwVdAphsS0IV5ZwU5FxaFV63suCu5cJrcXh65Xdfq 8YmRTZbM/r2PzqAKn+dGb9MsYX0lSuIqty/O43gCIo/s8hJYZrWXu9xJAkUSh0YjfeYn KKddHSzopAllgTz4wBupNI/mJRwMkfuhjvyi0otW2LTPVtIZg+THIjIJHRWq8os7hxp5 KrBg== X-Gm-Message-State: APjAAAWOm23DSOAN47RV6joP2kVCJPCshjzElVgEjs7LkT85RLLzcBF8 UZY+FNBCsX9PVHagybdQqic3MaY51xd08/HxULdkHQc/ X-Google-Smtp-Source: APXvYqxKi7Na7Ei9hCeF04gUVp7Qf5UZyt2lE//SYWzOgVk5BB8KCxuDhJ1y6sg2p6MXJLch7+I0L62IXamkHZVUkek= X-Received: by 2002:a37:8684:: with SMTP id i126mr12197313qkd.132.1578934266447; Mon, 13 Jan 2020 08:51:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 13 Jan 2020 11:50:48 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000136069059c084895" 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: Mon, 13 Jan 2020 16:51:10 -0000 --000000000000136069059c084895 Content-Type: text/plain; charset="UTF-8" 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. 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: > > https://doodle.com/poll/bg2q65phrvfip5zb > > 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. > > --Richard > --000000000000136069059c084895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also: Note that despite this poll listing specific dates, = the intent is to set up a weekly recurring meeting.=C2=A0 In fact, these da= tes will definitely not be the dates when the calls happen, because IETF re= quires one week notice.

On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes &= lt;rlb@ipv.sx> wrote:
I would like to have some weekly calls to = make faster progress on our outstanding PRs.=C2=A0 Here's a Doodle to f= ind a good time:


I believe these will need to be official V= irtual Interims per IETF process.=C2=A0 Chairs, I assume you can do whateve= r announcements are necessary once we pick a time.

--Richard
--000000000000136069059c084895-- From nobody Mon Jan 13 08:57: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 81F421208EE for ; Mon, 13 Jan 2020 08:57:55 -0800 (PST) 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 QJ3QTqIINaH3 for ; Mon, 13 Jan 2020 08:57:53 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 CAF801208EA for ; Mon, 13 Jan 2020 08:57:53 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id v25so9683887qto.7 for ; Mon, 13 Jan 2020 08:57:53 -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:message-id:date :to; bh=8AD+wqpB6FR776RkvVBwr9ICPIkKn3tadlTU9MxFzME=; b=YsFJABM2mFz70LXo4ayb1VlFzPYLzTzzw1Y/wq9AQPE9PGrenbmMahw1xQI2xHXOfJ +37rnVCWETm3knMEBtb71uE/4kE4TI7rH0UVrfVb9a2nsT6s1RyN1J9dZsSIql/VOHCn OR+iYTTvIq5z3uFHzMkDRBFkhT9fNjimRiJaE= 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=8AD+wqpB6FR776RkvVBwr9ICPIkKn3tadlTU9MxFzME=; b=tkU2OliroMFV59eOxdowx1p6nshDKWMPtWn1Hwq2oOzvjFP4aEJNu54Q9YJw8aIS4j sJwLUf5OvtSfeLxccU4d8tyAYdKw6bCOjVD0V/HMyBLyt3ejdS9SHRQEbpPg+3Z/fQ5/ k87jWqj0tW1/Dc+vvaAZN7KroY0/YFDIUzxBh9nWyTuutvF1yLExRxyx8fC4aVyv0lK8 bc03SQ+hhzMujl0EhAIVy0HpD4sjMkXLDDEUmXa6K9it8EI5oipj1Z1b4ZREpe3gxG+T ixZ4Oz32n4KKuWC7w/hZWasknZHWFYbz5MnSNQRWOzRIfOMMa6t5gonDooRXv0xehmA9 bbew== X-Gm-Message-State: APjAAAVNpEtiTmWBR43N+YuacJwiUFGOSfDtm3OJGJbOfy2VoodKT9tz OYJHQiuDaegk1myvUWKKDmuywq7PpCg= X-Google-Smtp-Source: APXvYqxL1mKuej/7A0MhVO+X544RhBvt9SCRJ9n7jwi8f59SOTdj7MEe73IxK6jJCXoAxt8JUELdnA== X-Received: by 2002:ac8:1196:: with SMTP id d22mr11122071qtj.344.1578934672557; Mon, 13 Jan 2020 08:57:52 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id q5sm5186313qkf.14.2020.01.13.08.57.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jan 2020 08:57:52 -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\)) Message-Id: <2D478053-DBB9-440C-BF19-35BD489D7814@sn3rd.com> Date: Mon, 13 Jan 2020 11:57:51 -0500 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [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: Mon, 13 Jan 2020 16:57:55 -0000 All, 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: https://doodle.com/poll/cd5zr7aeax3dx4e7 Cheers, Nick & Sean From nobody Mon Jan 20 03:46: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 B4405120114 for ; Mon, 20 Jan 2020 03:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWpWyK91DRH1 for ; Mon, 20 Jan 2020 03:46:38 -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 291A6120111 for ; Mon, 20 Jan 2020 03:46:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,341,1574118000"; d="scan'208,217";a="336397201" Received: from wifi-pro-82-249.paris.inria.fr ([128.93.82.249]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2020 12:46:36 +0100 From: Benjamin Beurdouche Content-Type: multipart/alternative; boundary="Apple-Mail=_FF42CE13-BB6B-485C-9E48-3F0FE926D365" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: Date: Mon, 20 Jan 2020 12:46:35 +0100 Cc: Raphael Robert To: ML Messaging Layer Security X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [MLS] Notes on the abstract MLS Architecture 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, 20 Jan 2020 11:46:44 -0000 --Apple-Mail=_FF42CE13-BB6B-485C-9E48-3F0FE926D365 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 During the interim I presented an "abstract" MLS architecture through = which I was looking at the functional, security and privacy aspects of MLS. Obviously it might look very different from the existing, or future, = architectures but I thought it was quite useful for Raphael and I to elaborate on = potential questions and solutions related to the server assist [0] functionality based on = *some* design. Since multiple participants at the interim asked me about the drawing, I = uploaded my notes online [1]. These are just extremely informal wip notes for now but I intend to make = them more formal and extend=20 them with more and more information as we go, hopefully keeping track of = the official WG documents [2][3][4]=E2=80=A6 Best, B. [0] = https://github.com/raphaelrobert/mls-delivery-service/blob/master/draft-ro= bert-mls-delivery-service.md = [1] https://hal.inria.fr/hal-02439526/ = [2] = https://github.com/mlswg/mls-architecture/blob/master/draft-ietf-mls-archi= tecture.md = [3] = https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.= md = [4] = https://github.com/mlswg/mls-federation/blob/federation-import/draft-ietf-= mls-federation.md = --Apple-Mail=_FF42CE13-BB6B-485C-9E48-3F0FE926D365 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

During = the interim I presented an "abstract" MLS architecture through = which
I was looking at the functional, security and = privacy aspects of MLS.

Obviously it might look very different from the existing, or = future, architectures
but I thought it was quite = useful for Raphael and I to elaborate on potential questions
and solutions related to the server assist [0] functionality = based on *some* design.

Since multiple participants at the interim asked me about the = drawing, I uploaded my notes online [1].
These are = just extremely informal wip notes for now but I intend to make them more = formal and extend 
them with more and more = information as we go, hopefully keeping track of the official WG = documents [2][3][4]=E2=80=A6

Best,
B.

[0] https://github.com/raphaelrobert/mls-delivery-service/blob/mast= er/draft-robert-mls-delivery-service.md
[1] https://hal.inria.fr/hal-02439526/
[2] https://github.com/mlswg/mls-architecture/blob/master/draft-iet= f-mls-architecture.md
[3] https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-ml= s-protocol.md
[4] https://github.com/mlswg/mls-federation/blob/federation-import/= draft-ietf-mls-federation.md

= --Apple-Mail=_FF42CE13-BB6B-485C-9E48-3F0FE926D365-- From nobody Tue Jan 21 13:09:15 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 7973F120020 for ; Tue, 21 Jan 2020 13:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 sAd97Oo1Z76C for ; Tue, 21 Jan 2020 13:09:09 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 BB632120019 for ; Tue, 21 Jan 2020 13:09:09 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id 5so3919385qtz.1 for ; Tue, 21 Jan 2020 13:09:09 -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=refsfXwr+QM6UcGs37xGt8FEGN3fNguK8KTmkPQ6Ljc=; b=U4bnYXRNQC0BgXMt9wNnRHARmuqFlp8sMFH1WfM9UcURPHGD1Z5iIHKGYW726O3UGU qyCcU0YCPJmji1kT166KgjV5ld2jm78fvPPzx/2Q1eNNtRS+kMuPYmjyjFH4Fz5KjriV wkWsXePQ4mYL7wXTcgetZh+7WD9B0muYUJ4ds= 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=refsfXwr+QM6UcGs37xGt8FEGN3fNguK8KTmkPQ6Ljc=; b=pz57e0M62mENdJd0wWSbc/+OdhSJH+qxkxlnNnYg//fEhU7WtEm5B2Ta6AGFO3FO50 +SRCZmHfxq/uWT1ta58tYHsPyp2tfA1q1YsRoXr44YoxKCUw7I4lNXTulL0gBoJFc4eP UkyI83BWIrkrD6GlEMBGqVm4/ozIz0Rd4tbNgg3aNEmlBB47Qr/uwBrlnT5lt/k002WQ Jz7IBDx6EbvANt5ZCPGlE41Tvz72jhu4/1CTIkuiQuwxMCJgry88qnvPx2pavNrTze3G xC9Uo88OJVxxiroLvxDDIu60TyfIIMtsHh6srAcabZDcre4UkNulV2DXBHVS13GLg91c c1BA== X-Gm-Message-State: APjAAAWNA0jC+C56PpRJrfX1Irj4kS/jdaNX8EAXlXNYdRk+naHgncbw DOYpcKI6e0rEWKMmN2Ck5lSvjiY/CYw= X-Google-Smtp-Source: APXvYqz225AW8ANjPm5wUJXoeh8KmAwU+CWdd+TnhdDLn6BMCsG2Bun7Fb2uUHKhj+0FZsB/zHHSRw== X-Received: by 2002:ac8:f02:: with SMTP id e2mr6378122qtk.216.1579640948760; Tue, 21 Jan 2020 13:09:08 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id j194sm17835507qke.83.2020.01.21.13.09.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 13:09:08 -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: Tue, 21 Jan 2020 16:09:07 -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: <8CC2164D-3E29-45E4-B88D-3CF6900ABE29@sn3rd.com> 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: Tue, 21 Jan 2020 21:09:13 -0000 Just a gentle reminder! 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 Tue Jan 21 18:17:34 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 59245120289 for ; Tue, 21 Jan 2020 18:17:30 -0800 (PST) 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 WP170kVMARws for ; Tue, 21 Jan 2020 18:17:29 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 096E412081F for ; Tue, 21 Jan 2020 18:17:29 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id q15so4239027qke.9 for ; Tue, 21 Jan 2020 18:17:28 -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:message-id:date :to; bh=kp0zV6HGm3cjhsFf8ms7xJA66XCv1jP6MWumQ2qmp64=; b=CqC+mmqFDlcDWP7LVJdLlgD5UrN1eaX6ktcv4QbOd+t9a9VCPrEf7Yrs8VDdRokALo oaAOLLXCuGQ7TC9f3kpnCQ37kJRkm2XaePhtr83oWiwN9piD+uVNNF9xWoPrGJa9ZvW8 i1wW58YG6WOgvCmornLuYtGq01PMTSZb3xtqc= 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=kp0zV6HGm3cjhsFf8ms7xJA66XCv1jP6MWumQ2qmp64=; b=YjO7JZ2NR1p6NGVDVE/JGnoQK0gkgVrhpOj/gQOAOAdkD0FMFIx3+l2AhuLatahP7T HstoWVq7U0RHsXwPZsYdyTKJBwU6avE0jU61dJhCqHaxrvwheL83LJFXKgL5EdihggCU trNiKqS1GGyb10xnLKFFQV9hyfB3b3UVg9ghl7bJYFohPPy9uYayC4lTmKZqbigCh7wt Is5yjoHqW2UUMZnfjCAMDFF0z1bWvmOaNE2/K1XnbesTlVyfHpyT58/KhL9a414/E45P +6g6meKTC5LI65DkGQuheJxHm4PsvnVQ0aUCBrV+EDp/MLvPDnSoPnqECeksWHiL2wWv CgGQ== X-Gm-Message-State: APjAAAUM+ItiuYsBOoyjVaS42ZxnluEQiPkgl3Bi/bEJvZ9UkG++5jzb Niul8EnHBpXDvMLsoBh30E4xnx8I3JA= X-Google-Smtp-Source: APXvYqz1zx6Wc+4MQ5teY/p3UL6rbFpb0WJ0rpVH/U7VGox7Vn4X9WgpEI7AFMxeRS6yY1UN5MtAng== X-Received: by 2002:a37:e203:: with SMTP id g3mr7804899qki.479.1579659447869; Tue, 21 Jan 2020 18:17:27 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id b21sm18214917qka.129.2020.01.21.18.17.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 18:17:27 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <3BF849A5-6BF1-468B-B947-B491654EDE83@sn3rd.com> Date: Tue, 21 Jan 2020 21:17:26 -0500 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] 202001 Interim Minutes Posted 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, 22 Jan 2020 02:17:34 -0000 Please review the minutes that can be found at: https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.md Let us know if you have any corrections by 2359 UTC 28 January 2020. Cheers, spt From mathias@hall-andersen.dk Wed Jan 22 06:34:24 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 7AD491200F4 for ; Wed, 22 Jan 2020 06:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hall-andersen.dk 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 EsNBurcbXSWu for ; Wed, 22 Jan 2020 06:34:21 -0800 (PST) Received: from mailrelay1-2.pub.mailoutpod1-cph3.one.com (mailrelay1-2.pub.mailoutpod1-cph3.one.com [46.30.212.0]) (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 282AF1200E9 for ; Wed, 22 Jan 2020 06:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hall-andersen.dk; s=20191106; h=content-transfer-encoding:content-type:mime-version:date:message-id:to: subject:from:from; bh=/I7oHqcjaVDYzaQKy+EfMa3A3vNsvautIbTB/zwTBqs=; b=o2HzoTF8qqTY2QltY6KsQToFfGyk2cNM4X2Z2kcd8Iyyn7mCmgwS5rPuRuwuSiNiFe0kgpnMTAuYm +/w/e3GelWLcMgf94wWseczsjZbVimi9TX7ktfL4VzJQ0OGKUYcauDyCrfPoWxV14SgoTFrmi9RDIY EZ167zupajoecsr4bIgyn+x57LKdiZreoN71kuw4/ZSLLkjkmuIRtCH8NKjckZ8Xa4DI9FY4ksu1wf zRDjevk5xb/hVn7+Tw9ZcOuE/HZPiHa4SnRt594NyMSck248OxDBqJMd97416Q62/U8QTjYsvxs7x+ csDicNhJeBbvR7PYjj8vwY8ZnxGMI3g== X-HalOne-Cookie: d4c35728b72d44a9e8350ef7208f3c31e9abf47d X-HalOne-ID: 451a8ca3-3d24-11ea-a05e-d0431ea8a283 Received: from [IPv6:2a03:8600:1001:4000::f8c] (unknown [2a03:8600:1001:1337::2001]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 451a8ca3-3d24-11ea-a05e-d0431ea8a283; Wed, 22 Jan 2020 14:34:17 +0000 (UTC) From: Mathias Hall-Andersen Autocrypt: addr=mathias@hall-andersen.dk; keydata= mQINBFdJtPsBEAD5nXy+MWGA5JjWMaT9Si8pgzSI8RTxHWxBTnun5pEqFMmNflhUk3FDCSvW 5zdm5zccYH+bqoHX7hHuDl9IhCGhzgbiTtVOctQMz0DN5SBMVrrwz/ziaAxsYQT0pfWey4A7 q6TSTZhToZOQH+mjR+b6p9w0t1HP73YqNjr7OEFBdaJS9RZGsxD142PubPn1PV2Db7xP+nXx Pal884Okbwy2gjrITG91x9IoDYa6Z+RtVwM8E10/i8b6sGHXoN8Yk5adcj9NmXz2q2kVT7nG Ur93mx0zzjDnYNEhFJg+gHyRB5W8ru5m9IaKyrHWLJZoGYYw6ttWX5Q8AyyTYWSZ58eChfAT +BKSLnTYLpYfpeWVXdpd4tyYnQqYGOn2gpBZtTzzRuyDX6ONnQVA/e6fFBCsOkSvUQ2mVALZ q1VZ+DTmosTm6mbvtAwMfABALXYi5oiyPoyFO/P24/LC2tbgwrcHDXfJRmyI0B+3F6tk7RbX QjZn8cuEsek1WRzc4bcEZdWWDigNxLSmh8X2ddBWnJ/cFFAneXf6ffDURChtP8i6Rz9BbLzs bUO1kOk87+1ZmGG3fIOzlEHzL23wdoDfrkeZ1X7EewTT/e/FTznmg8Yw5xwnbbxNVAzEwfmt e52lcfqPEJHK/XrTB73XZJiM0FpjQEXZFhrEY0DykuApqLb9AQARAQABtDBNYXRoaWFzIEhh bGwtQW5kZXJzZW4gPG1hdGhpYXNAaGFsbC1hbmRlcnNlbi5kaz6JAk8EEwEIADkCGwMCHgEC F4AECwkIBwQVCgkIAhYAFiEEceHsK3eHRXEGZ9UdrjMbILPIpcIFAl11SRIFCQgMx5cACgkQ rjMbILPIpcIiMQ/9FLvQ9uqlZgiF2QJv0a2UD0ZXZ3t9R2bUR8K8M8iuwHjoJURS/kbeGJCH J4Z+V5Kswh/C018TNwuXsQ44bTI5MxgAYBsxQQb2gGwJc8eNqDvOgdUgLP0R6SNbEwUrd52z ZPMXTGlEaik/4wnkOqc1LKC/ATvE3yy/Snv7iLe3mKSIy6QmtjqlrZ9RrNni7OEqp3VEhfkP Nx8w0Z6o7dHJIdw9v2Feh1dcGJFQDg6zD7PV0BPE82CzQcJzWa50+zEnQABlTZSZb909WBVk pDCtAhMsS5lsQGwy9BFBqx/l/p+6dMb/uOKRKH4BqT27u8+4+/anGgmF3TK3RWaXvIunqIlc 6oYJ7HZO2wReVHwHyuM0rY15hLOIdIzlS4PYXIuP7aV4ByAlDCBeD6cdYn/TGdCe1DYmvf7N fQumnxXi3od7lAxeIb8hYrwdYNXbJHVnhRoJXuGUe/ajn8y41GvTMmXj+UMeU31Dc/Fog+yk 4DBenTNem40vaZyhoejzb4Azb/rKDL6LGhk1UhySLE9tPr8H2cigPmP1Nnj2/Sm1ydILLwVv fdpoYTPvxBJ1dCCn0DDZt4fW7RNd/sLvomHyeiJumYFvQk2XWdSZxjardR87lf772T7RMfYf mJI22m1V/FGsIs+eJWBEqT7R5ldZYebbsE5ulG7o0wEJFGMi30K5AY0EW5Fy8AEMANje3aYX afeLWkAYBJBQJFP+VOjmE4cdjWjVXCNeQpvp1P34g3Qn7KYMUmul8zYtQEjJdkQDR5r2pZU6 pQyaotoukJfBHWGhuoURhpyNqsUpqqi87prpL384MRjYko4zFvwJ5+wTLHBv/v6xvcoMkEA+ 7FrOVnip0khVDrKVuTAU9yXy4AEUY4t27vQVjOGpt0Edp8pbLS/7sCBelMIMYsQrtO9fcQrm Exjh0uQPleJNw9+fnZTwSRRmsW4wdMexzS6sAY8BodSfk4IYYHsJe0EB71qARUEkB5/73WzK Bxj4da4OPIep/bInTgaHrvU3qFJ2JqogSWDY+LdXn9uV7cNKQERSuwfqsYJnagwq4Um46ucM xZKurvVrZ+N8dI3DADZWy72FVHmLxoN4m/swqIw/lJ67/3z55ebMlTFtQFvWQsUJEGpd4La4 7k0dInGsJBZQWHH61eMzd4YSVHPDl+WAxk94D+Xnu79Esck3G8xZZhIJxpuIGyivc1txWo1t 0wARAQABiQPyBBgBCAAmFiEEceHsK3eHRXEGZ9UdrjMbILPIpcIFAluRcvACGwIFCQPCZwAB wAkQrjMbILPIpcLA9CAEGQEIAB0WIQSSt85lBh7XyseHy+Y/bnj7qjtU2QUCW5Fy8AAKCRA/ bnj7qjtU2UojDACt5kZtcXZrYiWrmdyeMUSQbGqx+qRTy2Rdd0VYCfyLeZ5GvdbBew1K9wxZ xWOa/LNWBdt8FqgITnuAu239ULLoiIgwSr5iZWS93R7Nf0nfKOIBTYhbbWs95HPR+Y9ylnE9 O9OWVcQvlkaWsaXWBqUd8DtisQAcXg0iM1UF6yeuDg/8+Vo75WmId1QiQVXU0R2rT/TzbhHL jKttm7Kc5Nzu/GVovMKPqbfqUtAqUGpfWAn8Xz4blrdvgdmkopUufOYdjwij/7f52CTeG9zL hThRhwotClARdQPlj9FlxHUq4a+a0EEykWqwDeem01FP5QnU6nIPI96y9dM8AKtPIifbFaIA Lml9sL51mImm0eL52xoiIfhgm1PCCkg2os1nVCeLlK/09sz9eY8JBN24BDSd0KGEq0LhNSOZ AeUgyPtAVhuvwrNYBflpbIp9KiJzpCkhw5m+abiZaExtkr2/zgY3afGRPUGumW2Wan3aSx+V qQMroh4kQzd61iKJHUFnhSqq3A//Rl9hDZ2QY3aKrnG1QJrN8ky2p16imwNTk6V8TMssGVhT 4TZIEl6qrBfee+UIzz28h1RAMtV2bW27OLAf3ZVeUGBg5vzfjStox2pkdCgJz1SgU606aQgO HYOvUSlc7BUpQ6DTqbwRMBqnAXGBL3SHdQpzSyf8CCxwZ03TUTMcbibcKjXU9atgsD3Vyn0z HiIuclVLz1vfqx155o7TvLx2UlbLYWpm/ljvJbuNVqA7AHRtNkr4gsrisgA6XHmzSyPFxTQt VyzJRssLqBX8uOISwdnHdbcdmTqGusf7aV82VfW+LDhEdKiXMzd1qbMmhDI7vQnxlFxXAKZk DOxo8x9EkldkWrVRPV8E7UQ387wdZFVRsdbXAWXmW1fRCFjDVaKuVKxeenk57ho//9xzBhAb toTM6wiWwscSJVPcG1b5+vOmAQPnqskRiS5h3rgbw0W60P7scvMlv0OMrUsuqZi2RKHTCfJl HpVH9kNaGyI3fJeZnj9voRHgZaOEpCvWxgfLTavshcvQAAC2NpLpYMqEwJBF/TlvQIlslsIk Z+qWVhWlbMUeeDVU70AuEHGEDnK5vJ0uQ6T0w3PsKNfjsyMDJQghvV/UBqRuit4H4o9p5bA/ +cQn5z5Rpj1tryX2eD5BODd2DiM4lf4h/NDma4OkonnbjG7bIVWJs66w4+bJ6py5Ag0EW5F0 KQEQAOd6Fjr2dctjm+LtOQzfKNJ3zrnzg3jNhv+VvZY5Rx59pxQG29sYdh2sCGZF3dKLME0u B33npTZ/AqjqNyq71KwSWJOygO2Bz1oFDM2R3x193b2LrCWpdL8BRkn74e2UJIxEEUrT0iPh mw7dlzB/NHdMlJPYhXyrJBWg1sPuqwyqUkqgxxeetaQW4lr59uejAHG3HoPjTZcuE8Iuz1jm gKTuC8QHdGkNScu5Ys05VRKzDLFzePN8j3NJ8ZnUoEpO3p4oW4vELarGSB9TibjVhCf9S0xN ejrcAIGHPcDx52h15H9HkR3SNSqxqpHAOkz/AIyIsL3i6rZ/OosK/AxBYenBivEBWa3KEMFq ynpQT6T5/yaDlGclYzXqJ1mcKNxDFqnt2yzbB0NiAc0Co0kHq+pQCcdNBiocPhnCwYV62JVg aYGQ4ip/nFKZpqZ8dGf2x9F/tuuf/y59neFMSzMt6jxhYhKpZYNxmcNTKGmL7gqivLBYcT7T ExafCcqDbtxpZhuqZRaXsbcGzcrwevV+zRQM7k2gYxbdlt7qcmfiVCA7x7vD/69TxFZnvLyX 6mNw4QO41kyKcrxXWs/+rhJMa3uynLRudI7dTSS8m604eRRSv/uRcdFsmaR8ENoMy/7ImCDe mFVlVYJ9nmTrIEmmjG5oDb+xarnvFPDaISLR7dmZABEBAAGJAjwEGAEIACYWIQRx4ewrd4dF cQZn1R2uMxsgs8ilwgUCW5F0KQIbDAUJA8JnAAAKCRCuMxsgs8ilwhopEADCM4+Mz8Ea+DR8 kr1xURXb5NcO38AMk63yRPH1KSfqAcwmUP/4yXzedlmyih20PZEJier4CxiGNWNp5QFoTlpG z8OMRxKSw3wMpaSFizfGuVXtAuIxQWWsMbN3tiVjTAi4nkmMZISG0emoFdTkmWV/LpCV/1Mx GAuFW6UKVeKnqK7i2Sc/KI81GJWajzgNCiSiZwCSpSk3QULba0LgB++BXJwzzQHhl/qMJ0Cb nWF2PaUwgI2ZoVqgAF10Yw7zVL5jE7CB1n1MK/jyi/KfqW2z//aJGLeV6GPU2CQPZRwCW9El 9y20J/kiwcWMqJs1PKA6rydwa1IpTX6cq9PSy1WE6LbOzsnrX/w/kbkrYswPsInO2nUWrkdf OqzpnjBiqk9GuAiPd29w1h+6XibDFxeLrItZz2jREW1A0T77y4YXH6yBSrEZcwEB9hK5jQy3 56vHs16BTh3OACqrNoDDATiujjy2WTVY73uNLE4MvuBRPVO/pxSoXy+v4jo6tV+4tYovP/tt C/w+lY1vhRJH5m+L67R3B+MHVeY6kGErE04FkyKR2+NCaVf/6HJ54tSOJ46JOJ1vdFR35G6D K5Xc6EQIsNlAPZQLkK8mWK6xkNA+o7SLnsv78oy0c9klEspI478nZTfRXvBkqtrLQHOBFZY7 ZVHHJNWtNRM7CqRKtPDkCw== To: mls@ietf.org Message-ID: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> Date: Wed, 22 Jan 2020 15:34:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MLS] Deniability without pairwise channels. 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, 22 Jan 2020 14:35:06 -0000 Dear MLS group, In MLS: since all group members share the same secret, the application of an AEAD does not provide authentication within the group, MLS mitigates this using sign-then-encrypt with a long-term signing key. > [[ OPEN ISSUE: Signatures under the identity keys, while simple, have the side-effect of preclude deniability. > We may wish to allow other options, such as (ii) a key chained off of the identity key, > or (iii) some other key obtained through a different manner, > such as a pairwise channel that provides deniability for the message contents.]] > > -- Section 12.2 Authentication If deniability (without pairwise channels) is a desired feature in MLS, has the group discussed the feasibility of applying a "sign & reveal" type scheme? There are essentially two different options: 1. Short-term credentials: Clients would generate temporary "credentials" pk_{temp} for the group, by creating a certificate under their long term credential pk_{long term}: S <- Sign(sk_{long term}, ) Publish (S, pk_{temp}) to the group. Then when sending messages apply sign-then-encrypt using the short-term credential: S_{msg} <- Sign(sk_{term}, m) c <- Seal(k, .., .., ) Later, e.g. in lock-step with updates to the ratchet tree, the client publishes sk_{temp} to the group and generates a new short-term credential. 2. One-time credentials: When sending messages apply sign-then-encrypt using a one-time credential: S_{cert} <- Sign(sk_{long term}, ) S_{msg} <- Sign(sk_{term}, m) Then encrypt: c <- Seal(k, .., .., ) Where k is the group key and sk_{old} is the sk_{temp} from the previous message. Best Regards, Mathias From nobody Wed Jan 22 07:54:55 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 1424912087C for ; Wed, 22 Jan 2020 07:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 bmGSID_j0TtJ for ; Wed, 22 Jan 2020 07:54:46 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 D4287120639 for ; Wed, 22 Jan 2020 07:54:45 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id f129so7729836wmf.2 for ; Wed, 22 Jan 2020 07:54:45 -0800 (PST) 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=wesCKHUbh35VVA78IwLSmw87fd1d4DzNLO9+HKAoSF8=; b=hpmZ9KcR1fWgowdTU7iTk+F9sbgC1lFcvKjbtmw/SbgXWcN/7yMTjG6GfLeEEUX3iX kOdDn0TrIV1BttG+m1PjkhjqY81TPVRvDZPJhJq1MFMpGfNekaIN59WJ3S9XLiFD9N8m 0D0PBlNIscjdVEbUMWuBvIXzTM9M0OwA3Lf6AXY45P7Ow0dYwrTvjmiZ+fecod3Alz5I sihpGXm29fn7N3pMk4rihKhNbNxPg/foTr8p3L8QqNZEF8fgiw2SPzlPuTkw7GKbK/yy pKMsMqh6VnkzbBiPp94i+WIHprfd51Tc7wtWMbTjtW7erTc0QPJj7yF9FG1sT6sjgwF4 +86g== 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=wesCKHUbh35VVA78IwLSmw87fd1d4DzNLO9+HKAoSF8=; b=T40Ox8vKZsP8Qksoxen4b+Gn9vHm44CNW2IfFWFV/ii5tpylyL6AJEDu50zgW7JKUH zYuINfooRWAgkGVRxKiUXJoy4QVV2tQoPd3/0Nkas1n8SycvsVHmOzMzdBTvI0XJ/Mfy wJ/8ZdGswvIxVB/UiJ2ekpUQCIGETkMYLQZ/viOpAdU6HO8KUT+fd2JR0R9k2WL51tXk wNH3gvEKfE+RGs1oH2fJbzkXG+YUMtHQSA1vvjbKwKkYbt4rhivdK2SkIpVqyJo97Piv PRMAzEqo2tODgr+Vdt+mCBx267asFrb7Apz+uWGZBN1ZacWK60rAzV83zFSoAZPGLwF5 zTtA== X-Gm-Message-State: APjAAAXkWjwqleZqSGLYTtr8YCW4VJx7vljTg2UsSVSMtTaCYL4icyXC T3dMNcNpHN7LXPESMZTi5+dDcmJwmz+ELg== X-Google-Smtp-Source: APXvYqzPpHX1sFNwJtMjvfRALtjyoINs69flr+3fCvdTtsO8fSuu9IsiUPwNzLVGE4e+QaVpkwe5cQ== X-Received: by 2002:a05:600c:2042:: with SMTP id p2mr3788654wmg.79.1579708484203; Wed, 22 Jan 2020 07:54:44 -0800 (PST) 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 124sm4835512wmc.29.2020.01.22.07.54.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 07:54:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Raphael Robert In-Reply-To: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> Date: Wed, 22 Jan 2020 16:54:41 +0100 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> To: Mathias Hall-Andersen X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 22 Jan 2020 15:54:54 -0000 Hi Mathias, For general context: Deniability is something that is being discussed = right now and we should send some update to the list as soon as we have = sorted things a bit better. I hope I understood your correctly, you are essentially proposing a = =E2=80=9Csign & reveal=E2=80=9D scheme. If not, I=E2=80=99m sorry, and = please let me know. What has become clearer in some of the discussion is that a =E2=80=9Csign = & reveal=E2=80=9D scheme puts the burden of proof on the victim to some = (large) extent. The attacker can publish a signature chain that starts = with the public identity of the victim and ends with the signature of a = specific message. This signature chain will most likely look valid to a = third party at first sight. It then becomes the duty of the victim to = prove that they indeed published secret keys and that therefore anyone = could have signed the last part in the signature chain. For the victim, = this is painful at best and impossible at worst. It would be much nicer = if the attacker couldn=E2=80=99t publish such a signature chain in the = first place. There might be another problem, regarding synchronicity: since MLS is = completely asynchronous no one should publish a secret key too early = (i.e. before others have consumed the encrypted messages) otherwise we = might not be able to trust the authentication any longer.=20 But I fully agree that your proposal is obviously much more efficient = than a 1:1 fanout. Thanks Raphael > On 22 Jan 2020, at 15:34, Mathias Hall-Andersen = wrote: >=20 > Dear MLS group, >=20 > In MLS: since all group members share the same secret, > the application of an AEAD does not provide authentication within the = group, > MLS mitigates this using sign-then-encrypt with a long-term signing = key. >=20 >> [[ OPEN ISSUE: Signatures under the identity keys, while simple, have = the side-effect of preclude deniability. >> We may wish to allow other options, such as (ii) a key chained off of = the identity key, >> or (iii) some other key obtained through a different manner, >> such as a pairwise channel that provides deniability for the message = contents.]] >>=20 >> -- Section 12.2 Authentication >=20 > If deniability (without pairwise channels) is a desired feature in = MLS, > has the group discussed the feasibility of applying a "sign & reveal" = type scheme? > There are essentially two different options: >=20 > 1. Short-term credentials: >=20 > Clients would generate temporary "credentials" pk_{temp} for the = group, > by creating a certificate under their long term credential pk_{long = term}: >=20 > S <- Sign(sk_{long term}, ) >=20 > Publish (S, pk_{temp}) to the group. >=20 > Then when sending messages apply sign-then-encrypt using the = short-term credential: >=20 > S_{msg} <- Sign(sk_{term}, m) > c <- Seal(k, .., .., ) >=20 > Later, e.g. in lock-step with updates to the ratchet tree, > the client publishes sk_{temp} to the group and generates a new = short-term credential. >=20 >=20 > 2. One-time credentials: >=20 > When sending messages apply sign-then-encrypt using a one-time = credential: >=20 > S_{cert} <- Sign(sk_{long term}, ) > S_{msg} <- Sign(sk_{term}, m) >=20 > Then encrypt: >=20 > c <- Seal(k, .., .., ) >=20 > Where k is the group key and sk_{old} is the sk_{temp} from the = previous message. >=20 > Best Regards, > Mathias >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Jan 22 09:21: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 E882B120108 for ; Wed, 22 Jan 2020 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 Z7hdBP46Vdtp for ; Wed, 22 Jan 2020 09:21:36 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99199120807 for ; Wed, 22 Jan 2020 09:21:36 -0800 (PST) Received: from [127.0.0.1] (sam.net.in.tum.de [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by sam.net.in.tum.de (Postfix) with ESMTP id 84CDF1C00D2; Wed, 22 Jan 2020 18:24:58 +0100 (CET) From: Jeff Burdges Message-Id: <74E2C77F-5C0C-4DDB-904E-B9194BB10597@gnunet.org> Content-Type: multipart/signed; boundary="Apple-Mail=_8283065D-D3AF-4761-8FBF-1B91B098730B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 Jan 2020 12:21:26 -0500 In-Reply-To: Cc: Sasa Radomirovic , Raphael Robert , Ian Miers To: Messaging Layer Security WG References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 22 Jan 2020 17:21:39 -0000 --Apple-Mail=_8283065D-D3AF-4761-8FBF-1B91B098730B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jan 2020, at 10:54, Raphael Robert = wrote: > I hope I understood your correctly, you are essentially proposing a = =E2=80=9Csign & reveal=E2=80=9D scheme. If not, I=E2=80=99m sorry, and = please let me know. >=20 > What has become clearer in some of the discussion is that a =E2=80=9Csig= n & reveal=E2=80=9D scheme puts the burden of proof on the victim to = some (large) extent. The attacker can publish a signature chain that = starts with the public identity of the victim and ends with the = signature of a specific message. This signature chain will most likely = look valid to a third party at first sight. It then becomes the duty of = the victim to prove that they indeed published secret keys and that = therefore anyone could have signed the last part in the signature chain. = For the victim, this is painful at best and impossible at worst. It = would be much nicer if the attacker couldn=E2=80=99t publish such a = signature chain in the first place. Interesting thanks! I suppose the victim could often be prevented from providing this proof = too, like by evidence being =E2=80=9Clost=E2=80=9D, making this worse = than no deniability. It appears the golden rule for deniability is (*) anytime the parties have unequal power then deniability heavily = favours party with more power, so your observation provides a case when =E2=80=9Csign & reveal=E2=80=9D = just makes (*) even worse. I=E2=80=99ve never seen a =E2=80=9Cuser story=E2=80=9D that contradicts = (*) but please do let me know if you think you know one, maybe off list = if that=E2=80=99s a derail here. I=E2=80=99d love to participate in = some more user oriented formalisation of deniability eventually. I do = think deniability becomes useful when both parties have relatively equal = power, although maybe the user interface suffices for the common = messaging cases, but presumably properties related to full deniability = become really useful in layer 2 blockchain scaling solutions like state = channels. Anyways in the vein of "sign & reveal=E2=80=9D making (*) worse, I also = want to caution that deniability schemes based on ring signatures = actually make (*) worse because they prove that some party made the = comment. If you assume the parties have unequal power, as in a court = case, then a ring signature effectively means the more powerful party = can convince the court that the less powerful party signed the document. Jeff --Apple-Mail=_8283065D-D3AF-4761-8FBF-1B91B098730B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEBA1bLpAiCdPXvXG3q6x/0cwQCnQFAl4ohJcACgkQq6x/0cwQ CnTBoBAAi2bm8Hko8GFm/nlGXzpkGkojEO4bWbnD92Rpb/0689VVSMNlFwabnr4q dgZFhWHLAJvTlW00q4we5RQ3VK/u+Iab+Bmd2bMX+puO8pAfIRNkCqqbe2Wz/Etl PiZ7a0rdAmu1F/RpJKx2WIP8JxVh5qqeKGIKPQ/Jn+s1DROY5siHqcpVxZ/3bk7M Zhqr7arYyPg7t90BbePfGa2mpbg0+z4scubnSJpT4hfi4bDtc0xwzTHHblG2JYxT GbVbxs9lhHwmX64Hbex8D4oiHkngjcmvSn9QB6w9V4RNANPcq1Bcp9hsknuVgQRj M3HukIusC/ISQ3AeF2A93YT0AKAlRYw0STq+i+vP8xkMq0p3sUAyo7e+C84QjC1k oIydEKFBIeQkNRD8lL49+wdXTMvY3ogDR6lADN42E3BMjrx0YSeAJ9HQLZqllf4C bptSzNjrrHbUkyAaJlAquAFmwpLRAH+y4MuKfvvpvMbXTRsC2g/mSk97JxWQn+p3 ehC/SWj/IAd/ZFsYA8IsIObYty1r3UzdtIGU71X+rEfS0ZDRkmu1LTPNBODU5nfC IWp9Y5Dv0EPY2YYAte+uFo7cfdmuvCa9jjMFy6MPVp10EaM/Dn1woz/izU1lwrgm QKS61rHQJOzvHGn/tboULCVwTtz9wTLa3JGCAp+WmJ1cSYA7hHE= =/3mO -----END PGP SIGNATURE----- --Apple-Mail=_8283065D-D3AF-4761-8FBF-1B91B098730B-- From nobody Wed Jan 22 11:05:10 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 4A06F120804 for ; Wed, 22 Jan 2020 11:05:09 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 lizMqqfStN9Q for ; Wed, 22 Jan 2020 11:05:06 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 1F995120802 for ; Wed, 22 Jan 2020 11:05:06 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id s142so236974vkd.9 for ; Wed, 22 Jan 2020 11:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I4oL5/CIVnrfQgJfd58bUwJxAhYgPD4rCtD7G7K+81c=; b=wLEyyBspklqxLg5UVAuJPG01+C8zkMt2ZN1duWqEj7y/hmDz9a+2pHSEkECmtp3r92 6MrUg5JvWkczcS4n4RqEyAVllW4JB5CjBuoGFiGkxunj/fpE2SeWnZkyXwhkwL8s60Nf xUSm0g5d459GXuuqcaLOYRkme6QELgrc3mVoY= 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=I4oL5/CIVnrfQgJfd58bUwJxAhYgPD4rCtD7G7K+81c=; b=OI+EIYm/9SmiU7L6DmnGkzTRD/JzNgWyUuHXdVIRjnf0ichDIFbqy9dLKYPHkHsOiI bzhKbywZxVcT8mapcwB+4SJsjLHe8iu15XXJgaMUWhhW7occAcCah5F9b45VO0yTHGCi TN+tpd8+ZIV0+u5uUg+qpZcRjdp/MW6j6S3fTA5UnSjzRpyUy6eXOPupjCPsJ8udzAe6 OVEDuod4L60rtauqYKnKCpB4CJKRcHY+HWW+q2Jke21FBYWhokbYI3/NE8gHd6DDA80w xAh7JRmOVRMfcD6JapEw2V5r6vDWcnAv8WJ2uIJhagZtWOehJBCd0bXbG5VY5984rmw0 NDsA== X-Gm-Message-State: APjAAAUdMg/Fh48rfmEN7QHznm4SuMRIXTDif2bc2m5Yu5bmdtdl+piw BegXn//Q/zPlGA0VX4RM0P2d9JwS409Lnh8oPfhLdg== X-Google-Smtp-Source: APXvYqwr15RRCflC2Fs/ZL1q8CS9dcexIpwXoQe1Ie/SYc6K14B3SPP2utNeSTYM84HMEGkVf/sZqcmzUVrC6NzLZUc= X-Received: by 2002:a1f:8fc3:: with SMTP id r186mr7602590vkd.87.1579719903551; Wed, 22 Jan 2020 11:05:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 22 Jan 2020 11:04:30 -0800 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG , Benjamin Kaduk , secretary@ietf.org, Roman Danyliw Content-Type: multipart/alternative; boundary="000000000000b24b9f059cbf3394" 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, 22 Jan 2020 19:05:09 -0000 --000000000000b24b9f059cbf3394 Content-Type: text/plain; charset="UTF-8" It looks like Wednesday at 1400-1500 GMT is the least bad time. 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. 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 ). Links to the conference calls are forthcoming. Nick & Sean 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. > > 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: >> >> https://doodle.com/poll/bg2q65phrvfip5zb >> >> 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. >> >> --Richard >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000b24b9f059cbf3394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It looks like Wednesday at 1400-150= 0 GMT is the least bad time.

Th= ese calls will be recurring virtual interims, and as such are covered by th= e note well.=C2=A0As a reminder, decisions made at interim meetings are not= final and must be confirmed on the list.

Here'= ;s the proposed schedule (subject to AD approval):
Time: 1= 400-1500 GMT on Wednesdays
Agenda: the set of active PRs f= or the active documents on Github (https://github.com/mlswg).

<= /div>
Links to the conference calls are forthcoming.

Nick & Sean

On Mon, Jan 13, = 2020 at 8:51 AM Richard Barnes <rlb@ipv.sx> wrote:
Also: Note that d= espite this poll listing specific dates, the intent is to set up a weekly r= ecurring meeting.=C2=A0 In fact, these dates will definitely not be the dat= es when the calls happen, because IETF requires one week notice.
<= br>
On Sun,= Jan 12, 2020 at 6:05 PM Richard Barnes <rlb@ipv.sx> wrote:
=
I w= ould like to have some weekly calls to make faster progress on our outstand= ing PRs.=C2=A0 Here's a Doodle to find a good time:


I b= elieve these will need to be official Virtual Interims per IETF process.=C2= =A0 Chairs, I assume you can do whatever announcements are necessary once w= e pick a time.

--Richard
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000b24b9f059cbf3394-- From nobody Wed Jan 22 11:59:55 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 0A7FF120271 for ; Wed, 22 Jan 2020 11:59:54 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=callas.org 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 nAtQ3EandNtR for ; Wed, 22 Jan 2020 11:59:51 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 CC1091201E5 for ; Wed, 22 Jan 2020 11:59:51 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id d5so19089pjz.5 for ; Wed, 22 Jan 2020 11:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y/boFjXMVOGreGOtbPJQk5Fn+9rVktkSsgySPATe1bA=; b=a5ygXHfM70yGgxOpZnwkVwOz1DKkR28JBOoZ792EHRnFKaPnNZfL2XjhhNP0Jr5vio pE7745QElaQU/HdjeKWvjwUlqf93+77R+fbVYYI+njobBTl7SaLKE4aLgOBUc3bcbzJx opjlr5Kjg3TL29RZYydpe52JL8FloagzoE+j4IeS8ZIlUGU2k5613GP5RKrIDhgSdbjC 6i305WWqx/hzbc1KiFYLADkK9EnWO0lC3fJSszfI230S4d3H5VpL26Ift+H4s98MsuOO n4PTi+0QnyLuXhQwalGMDq+kduxGmEJNBBGjmUwT7v6VIg/Ik/qS4tv1IRObnjnS+iAI 6Y9g== 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=y/boFjXMVOGreGOtbPJQk5Fn+9rVktkSsgySPATe1bA=; b=ilsmEBChuFmhi5bQ/DT3suYvlaD5iQiZ/5B/ZULxLdWeZfuHkZsSu/h6HKEv6vn6XP Lk/zcefmvzjvFQEUhhfsza9Ea/ZhRWOdsnluSSIMVxSIRlY8+vzmyDuO7UXC445RR1EY MW3Mj8zsV//ee0CFpwimv1S80DkH8AjF6z0Yw2n+5AB2p1DQ8P99DDIGjqYrGwzCEax4 36oTWB4CjxD2V1SxwZzKa33h7go7Hdk+xw1mNleJ9PYMeMhgaiMNOGpA/ZsRNyP2v0FN mVV5K50Ja5RotYPtcL52GOKMpDOGzutqWg3q012l5PvAtj3crY6srzhxWiuzV+uIHKfp GLcw== X-Gm-Message-State: APjAAAU+u2cX0V0+B6Gg19yiPJryymFd+qwcD4B7VXN5aLR+acJfbrJQ 8RZt69oEtshv5WtYKOUxAk/WEA== X-Google-Smtp-Source: APXvYqwUPCMJWnQEx5NIEVjRPZ2/DlKxKHwSzSeNJavbLCHp92KVxiN5fb7Mg6lnNSM7Ng7LkdBwdA== X-Received: by 2002:a17:90a:cf08:: with SMTP id h8mr112279pju.81.1579723191056; Wed, 22 Jan 2020 11:59:51 -0800 (PST) Received: from [10.125.12.115] (67-207-120-150.static.wiline.com. [67.207.120.150]) by smtp.gmail.com with ESMTPSA id 136sm44546194pgg.74.2020.01.22.11.59.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 11:59:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jon Callas In-Reply-To: Date: Wed, 22 Jan 2020 11:59:48 -0800 Cc: Jon Callas , Mathias Hall-Andersen , Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <9CA95CA6-14B2-4DD0-A888-7FFFC42E77AE@callas.org> References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> To: Raphael Robert X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 22 Jan 2020 19:59:54 -0000 > On Jan 22, 2020, at 7:54 AM, Raphael Robert = wrote: >=20 > For general context: Deniability is something that is being discussed = right now and we should send some update to the list as soon as we have = sorted things a bit better. >=20 Please do. I have some tart opinions about deniability, and don't want = to waste anyone's time before we know what we're really talking about. It's also probably best not to talk about things like courts and so on. There are a number of reasons, starting with jurisdictional issues. = Inevitably, each of us will talk about legal issues through the lens of = our own native jurisdiction and that lens is cracked with our own = misunderstandings of law and procedure, not to mention that these things = do change over time. A procedural stage setting of today may not be the = setting of a decade from now. Lots of protocols talk about "deniability" and it's often a weird = concept that is a term of art and doesn't mean at all what a reasonable = person might think. I've had some discussions with people about the = "deniability" of OTR and others, where it doesn't mean what any = non-expert would think it does. There are other deniability issues that are peculiar. A way that I've = characterized this issue is that deniability assumes that your adversary = is either stupid or good. By "stupid" I mean that they understand what = deniability is, and might not even look for it. (e.g. hidden volumes in = Truecrypt). By "good" I mean that you're going to give some mathematical = explanation and they'll accept it. If the adversary is smart and evil, = deniability can be a weakness, not a strength. Here's an example, again with Truecrypt hidden volumes. I once talked to = some customs officials in a country that's not mine, and I asked them = about hidden volumes. They said, "Oh, yeah, we know about hidden volumes = and if we see Truecrypt, we *assume* there's a hidden volume. Why would = anyone use Truecrypt and not have a hidden volume?" That might not be = precisely evil, but it shows a basic issue. True evil would be that = after getting to the hidden volume, they ask you to open up the hidden = volume in the hidden volume. You reply that there's only one level of = hidden volume and they reply (knowing that you're right, but because = they're evil), "That's your story. This is open source software. Open up = the other hidden volume." Another form of assumption as either smartness or evil is that if you = have a ring signature that could have been made by Alice, Bob, or = Charlie, they just assume that Alice made it and let Alice know that's = they're working hypothesis since she's their suspect. (I don't want to = go too far down this rathole, but it might be the smart way to bet. = Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is = the only European in that set -- it's a reasonable hypothesis that Alice = made it.) Thus, when we talk about deniability, let's talk about the specific = security property and not an aspirational thing like "deniable" that = might not work out the way we think. If the property is that a signature = could be made by any element of a set, that's a nice property, even if = there are externalities that can winnow that set down, even to a single = member. Jon From nobody Wed Jan 22 12:40:58 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 1EB0B120832 for ; Wed, 22 Jan 2020 12:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 K-LX1nOjaD-S for ; Wed, 22 Jan 2020 12:40:49 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 1919A120821 for ; Wed, 22 Jan 2020 12:40:49 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id cy15so1000086edb.4 for ; Wed, 22 Jan 2020 12:40:49 -0800 (PST) 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=gbAmetz8fH0yBvI45/FwL12jwdwSPxiWY6kFws/U1bQ=; b=Sh+yBFfX+QDQJ0yBvSyVAD1T0nuCWULiXg3U0BC+tFqnhPBS7c/Dsn5IKoEU1MFm4g Hrsn5AQtmH3JRXdI7yBTKiG6FXVko5Keu2s1uJYhzRcqayBOegscqaTn1sZGNuOFLlZ7 IDbw1P9Yc38U0z1WgzjRT0XA+porHhgQ6/z4+l4ajjLMCJgn/0ywkxcwo/eMbtNOWn4S n2bwZtVN/qRyNPf3oJrSQTqELecR0oAw3T8CtTo/XhZFpVUFGOsPHLOJz8fdiKTXtgUa uz+lBCm2xGZIagbRP9ADnfm2oKaF2qr7J/HLSjcVBUXvQS3Ue+YztBVuilgRpBVWFwnq dWSQ== 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=gbAmetz8fH0yBvI45/FwL12jwdwSPxiWY6kFws/U1bQ=; b=E89K6rxw5A/28nvUT1xFO6WAvY8MABlLb3wNBeImLyHeYtJaGOdIgf9sEkCYsiRKw6 Uh2bNHw52tbqnbMr4uhoHeROVL8ITUBjz5zCCjxrA4u0CWROEj3wA3j4PGj0eExOe9cf mV95p3OOmiboAAhuX+EO0I15/J7441CtPwx/nRRak7HJxrHlrp291PyAIioFsTdF/CdY ahx1ZvLJ5at6DAFu3giJWe8oUVy835V8yxOqU9wz1b9XDcshaEWHc6YmQlcJ24DK8UMi KME3EEr7V5E3OwWXc3GT/gxM6IzErV/yp+nNAGRKugoAS9hmphZnRp7YWPyXEkIbq4pK IpEQ== X-Gm-Message-State: APjAAAUNbbLlSH94c+SXjMI+CmwtXMvKXYYUQdmI01OodDhs3YMNUQ1n Npu7zqA8kUHMSexZ1fdtd5nLy25DFvS+2w== X-Google-Smtp-Source: APXvYqy/s8hEuytdGrw28z9xEcwBsrY2u8tC1RMg64tpU8l78Ueg+GItE2nWG6KbRYqRO6wprXx9QA== X-Received: by 2002:a17:906:d4a:: with SMTP id r10mr4082552ejh.125.1579725647568; Wed, 22 Jan 2020 12:40:47 -0800 (PST) Received: from ?IPv6:2a02:8109:9f40:7754:553d:954a:3eff:4157? ([2a02:8109:9f40:7754:553d:954a:3eff:4157]) by smtp.gmail.com with ESMTPSA id o7sm1500784edv.71.2020.01.22.12.40.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 12:40:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Raphael Robert In-Reply-To: <9CA95CA6-14B2-4DD0-A888-7FFFC42E77AE@callas.org> Date: Wed, 22 Jan 2020 21:40:44 +0100 Cc: Mathias Hall-Andersen , Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <9DDC1E59-8EB6-4221-8C7B-465E65C46417@wire.com> References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> <9CA95CA6-14B2-4DD0-A888-7FFFC42E77AE@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 22 Jan 2020 20:40:51 -0000 > On 22 Jan 2020, at 20:59, Jon Callas wrote: >=20 >=20 >=20 >> On Jan 22, 2020, at 7:54 AM, Raphael Robert = wrote: >>=20 >> For general context: Deniability is something that is being discussed = right now and we should send some update to the list as soon as we have = sorted things a bit better. >>=20 >=20 > Please do. I have some tart opinions about deniability, and don't want = to waste anyone's time before we know what we're really talking about. >=20 > It's also probably best not to talk about things like courts and so = on. >=20 > There are a number of reasons, starting with jurisdictional issues. = Inevitably, each of us will talk about legal issues through the lens of = our own native jurisdiction and that lens is cracked with our own = misunderstandings of law and procedure, not to mention that these things = do change over time. A procedural stage setting of today may not be the = setting of a decade from now. >=20 > Lots of protocols talk about "deniability" and it's often a weird = concept that is a term of art and doesn't mean at all what a reasonable = person might think. I've had some discussions with people about the = "deniability" of OTR and others, where it doesn't mean what any = non-expert would think it does. >=20 > There are other deniability issues that are peculiar. A way that I've = characterized this issue is that deniability assumes that your adversary = is either stupid or good. By "stupid" I mean that they understand what = deniability is, and might not even look for it. (e.g. hidden volumes in = Truecrypt). By "good" I mean that you're going to give some mathematical = explanation and they'll accept it. If the adversary is smart and evil, = deniability can be a weakness, not a strength. >=20 > Here's an example, again with Truecrypt hidden volumes. I once talked = to some customs officials in a country that's not mine, and I asked them = about hidden volumes. They said, "Oh, yeah, we know about hidden volumes = and if we see Truecrypt, we *assume* there's a hidden volume. Why would = anyone use Truecrypt and not have a hidden volume?" That might not be = precisely evil, but it shows a basic issue. True evil would be that = after getting to the hidden volume, they ask you to open up the hidden = volume in the hidden volume. You reply that there's only one level of = hidden volume and they reply (knowing that you're right, but because = they're evil), "That's your story. This is open source software. Open up = the other hidden volume." >=20 > Another form of assumption as either smartness or evil is that if you = have a ring signature that could have been made by Alice, Bob, or = Charlie, they just assume that Alice made it and let Alice know that's = they're working hypothesis since she's their suspect. (I don't want to = go too far down this rathole, but it might be the smart way to bet. = Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is = the only European in that set -- it's a reasonable hypothesis that Alice = made it.) >=20 > Thus, when we talk about deniability, let's talk about the specific = security property and not an aspirational thing like "deniable" that = might not work out the way we think. If the property is that a signature = could be made by any element of a set, that's a nice property, even if = there are externalities that can winnow that set down, even to a single = member. >=20 > Jon >=20 I agree with the above. Ideally we would like to combine academic = precision with common sense definitions and be clear about the threat = model too. I also agree that we should leave aside legal considerations = for all the reasons you mentioned and focus on the social aspect of the = facets of deniability. We=E2=80=99ll chew through the existing material to see what could make = sense in terms of properties and how we could achieve them in practical = terms. Obviously not all aspects of deniability are straight forward in = a group messaging protocol, all the more so since MLS has strong = authentication guarantees that 1:1 protocols might not have. Raphael= From nobody Thu Jan 23 05:47:52 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 77C6B1200DB for ; Thu, 23 Jan 2020 05:47:50 -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, 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=yahoo.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 KObpRvwXlYPz for ; Thu, 23 Jan 2020 05:47:47 -0800 (PST) Received: from sonic303-54.consmr.mail.ne1.yahoo.com (sonic303-54.consmr.mail.ne1.yahoo.com [66.163.188.180]) (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 504E81200D6 for ; Thu, 23 Jan 2020 05:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579787266; bh=/PNXgZuYPU/hUpA4KpozJZKboyCWT4uAO/kJfRww0HU=; h=Date:From:To:Subject:References:From:Subject; b=qH+VAI+nUtjMS1GHNd7JqAPv/SzQFMDrhz6PmsYaWMAkj3iPtvLg7VLKITmU73yweOxvie193pebs/UM4Hfm2PQjIqCz3v6fr6p7o2516jhlFo5shhO01q2ULU8CAPUAAoMON0AN4MZbwP2iKl1ORS/tiiLLreNvBisoLhpPArZ/uLgQ3H0n6hjcI9zCJZsmVnGeu1oy6+1S9fipgeKtA1ttTxfmPOXHyfe7CzHMLIMR9hCtQdOgSULWF2mYjrhmPvmEA/T1TWJTX/4M6YeZbkxF4aUDLdpUp1nRO4YOXeh3ezrLfO1S5vSNizT1CfDEHuNeVUXFZAeULNSD3tW7qQ== X-YMail-OSG: 1MaD2jAVM1nVl.z8DMabPMysU1WNrpZn7MVC0yhTaPIPgmGCFDziCC7jNVRc5cR R5ZQhpKZ4e6W8S4R0zso56S8qfAoFOe0V4S7MfJfdD4eLeg6UBA1LCEmdz94iZGNtfbTU1DTmAjt A6cIbFJDFSGH6bAOO047Ae4pzvdy2FAiJ6TRp65fei8zeeecF9lhh.OJaU.Kuf2FdIj_TFocnATH 6be_1Lga82u6l76Pzj_mBmpdlocYJd8teWmJQkQuKM6_YWmjFWRwvgfrVm9E6WRyP2fRt.Ok7L2T Eolgf6ae9JyotF3QO.cuHnhRQT.q8UAA_eDOq_FpXpC7tZPTQZUffWGn319Hi9J1XreYvYeQeUDU jwDxtkh0Wp03DZT8goUyeetena2NvoVf5CxA0lUQ_2ZzJiEaj0Eu01XnXz0ytIMHlvqj4E9INbIQ GN7V1T.i.WzMzCuLZvWnCJa7NDAzjRnOu7p4MLyx2lvEREnX3NHsBQGkSMxe3ViOc51RBtJq_41z V3gRWXa0oEvQvbwufDTTPl_jhKgH0fr1bHbMi9R2EbjoyFz2KNeU_sMGVsizut9u3cmRE9Bop8vp nwnyX0N7PEofuMwSLL0UTX0eWqwzH_iFH3rkqYHjT6ZfJJZ54UFclA__xguj0Cj0SkXlOWdtRVk0 _AzkEa9iDUNyXfN_WtR6s2VDt1i87gXa2FzF6oPSH0xjnoKLGgGp2tPPLGC8GvrkOX7KnLuq2tun dcMQQC3Hz55XjcbiCVmTvJdjUGhkJJ0vJLiUY.sgsrf4lySApOKYgF9HlbPgZX448y_GvJ9HFQr_ 8X3jaCQ4VX9zzR7mwjo6MTZ3IdZCqY3qJa4oSAXxxhd4jORHK5yqKqS8jGoMb5U7zx2gr.kx0nYr 7Q1z94IvaUYIFV61aLsHxXNBC66rm5lI.bs6AQul_O5jqCTnvIlPhICGVpLg0m3f3SpfMuFhiWIi QwoaRYraxnKNJ7N1GtiotULdGraAGi5BL.f9LzYDZq9FbR76ExWvpWkc2nCyM1KpUi5NFgdcjzff 0kqwLM_RmYMq_KV_RZk3NtVt5IUhM3dZ6f9ufhKC1hmPlxpvCUfIZTXJaj_hvuNwqHqaN2Qw0R6j ZpLLIGw9MXMvkwFR4Fkh3kB9N_9qZc97ZBCTex112Unwy9CcXGiN6odlEhRFbXrNH_6D8LObGvK9 BCwh7Ixm.EcrkelRcMYk4tedCDOGExRiwJZRnUoscOdRyYTw3vFZ1DQgEtDj9xXutrqsoZBh1ASg XkX0Pt8Dwm4Y3kSSd_5z3JBFyTK4sDk1xxNPvylhF8iloVW5Y5r971RHGLWanlrXf.WrxZ8hHUV5 8ogtL0tByjx9zZ0EHlnofk8OxYdtxXP_Nz0_oRd0kqvQtW3Gs1StFIOkB5bYUukLtnkkrHVYtP8o TrhTmUw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 13:47:46 +0000 Date: Thu, 23 Jan 2020 13:45:45 +0000 (UTC) From: "nalini.elkins@insidethestack.com" To: "jon@callas.org" , "raphael=40wire.com@dmarc.ietf.org" , "mls@ietf.org" Message-ID: <2060195243.218290.1579787145340@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_218289_1905556058.1579787145338" References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> X-Mailer: WebService/1.1.14873 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36 Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 23 Jan 2020 13:47:50 -0000 ------=_Part_218289_1905556058.1579787145338 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, >> On 22 Jan 2020, at 20:59, Jon Callas > wrote:>>>>>>>>>> = On Jan 22, 2020, at 7:54 AM, Raphael Robert > wrote:>>>>>>>> For general context: Deniability is something that i= s being discussed right now and we should send some update to the list as s= oon as we have sorted things a bit better.>>>>>>>> Please do. I have some t= art opinions about deniability, and don't want to waste anyone's time befor= e we know what we're really talking about.>>>> It's also probably best not = to talk about things like courts and so on.>>>> There are a number of reaso= ns, starting with jurisdictional issues. Inevitably, each of us will talk a= bout legal issues through the lens of our own native jurisdiction and that = lens is cracked with our own misunderstandings of law and procedure, not to= mention that these things do change over time. A procedural stage setting = of today may not be the setting of a decade from now.>>>> Lots of protocols= talk about "deniability" and it's often a weird concept that is a term of = art and doesn't mean at all what a reasonable person might think. I've had = some discussions with people about the "deniability" of OTR and others, whe= re it doesn't mean what any non-expert would think it does.>>>> There are o= ther deniability issues that are peculiar. A way that I've characterized th= is issue is that deniability assumes that your adversary is either stupid o= r good. By "stupid" I mean that they understand what deniability is, and mi= ght not even look for it. (e.g. hidden volumes in Truecrypt). By "good" I m= ean that you're going to give some mathematical explanation and they'll acc= ept it. If the adversary is smart and evil, deniability can be a weakness, = not a strength.>>>> Here's an example, again with Truecrypt hidden volumes.= I once talked to some customs officials in a country that's not mine, and = I asked them about hidden volumes. They said, "Oh, yeah, we know about hidd= en volumes and if we see Truecrypt, we *assume* there's a hidden volume. Wh= y would anyone use Truecrypt and not have a hidden volume?" That might not = be precisely evil, but it shows a basic issue. True evil would be that afte= r getting to the hidden volume, they ask you to open up the hidden volume i= n the hidden volume. You reply that there's only one level of hidden volume= and they reply (knowing that you're right, but because they're evil), "Tha= t's your story. This is open source software. Open up the other hidden volu= me.">>>> Another form of assumption as either smartness or evil is that if = you have a ring signature that could have been made by Alice, Bob, or Charl= ie, they just assume that Alice made it and let Alice know that's they're w= orking hypothesis since she's their suspect. (I don't want to go too far do= wn this rathole, but it might be the smart way to bet. Suppose the signatur= e was made at 4am Pacific or 12pm GMT and Alice is the only European in tha= t set -- it's a reasonable hypothesis that Alice made it.)>>>> Thus, when w= e talk about deniability, let's talk about the specific security property a= nd not an aspirational thing like "deniable" that might not work out the wa= y we think. If the property is that a signature could be made by any elemen= t of a set, that's a nice property, even if there are externalities that ca= n winnow that set down, even to a single member.>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0Jon>> >I agree with the above. Ideally we would like to combine academic precisio= n with common sense definitions and be clear about ?>the threat model too. = I also agree that we should leave aside legal considerations for all the re= asons you mentioned and focus on >the social aspect of the facets of deniab= ility. >We=E2=80=99ll chew through the existing material to see what could make se= nse in terms of properties and how we could achieve them in >practical term= s. Obviously not all aspects of deniability are straight forward in a group= messaging protocol, all the more so since >MLS has strong authentication g= uarantees that 1:1 protocols might not have. Without getting into any solutions, I just wanted to put forth some common = sense requirements.=C2=A0 I hope that I am understanding=C2=A0 how deniabil= ity might work.=C2=A0 =C2=A0Please correct me if I have any misconceptions. Companies doing financial transactions and wishing to use MLS might have a = hard time if there were some aspects of deniability.=C2=A0 For example, if = you do a stock trade, it is required to be recorded.=C2=A0 If the stock tra= ding company cannot prove that it was indeed you that did the trade, then i= t becomes quite problematic.=C2=A0 Also, for example, if you are getting advice from a medical professional an= d they wish to know that it is indeed you that they are talking to.=C2=A0 T= his is important for privacy and other issues.=C2=A0 One does not wish to g= ive health information to just anyone. I believe I had stated in this group before that the "recording" would be d= one by a completely transparent group member known to all parties.=C2=A0 Fo= r example, when you call a business and you receive the message "You are on= a recorded line."=C2=A0 =C2=A0There are quite a few use cases for such a s= cenario in the business and medical worlds.=C2=A0 I would support a common sense explanation of the various aspects of deniab= ility along with what cryptographic schemes would do and not do, if I am am= making any sense!=C2=A0 =C2=A0I would be happy to work in a team dedicated= to this effort. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ------=_Part_218289_1905556058.1579787145338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

= >> On 22 Jan 2020, at 20:59, Jon Callas <jon@callas.org>> wr= ote:
>>
>>
>>
>= ;>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert <raphael=3D40w= ire.com@dmarc.ietf.org>> wrote:
>>>>
= >>>> For general context: Deniability is something that is bein= g discussed right now and we should send some update to the list as soon as= we have sorted things a bit better.
>>>>
&= gt;>
>> Please do. I have some tart opinions about denia= bility, and don't want to waste anyone's time before we know what we're rea= lly talking about.
>>
>> It's also probably= best not to talk about things like courts and so on.
>>
>> There are a number of reasons, starting with jurisdictiona= l issues. Inevitably, each of us will talk about legal issues through the l= ens of our own native jurisdiction and that lens is cracked with our own mi= sunderstandings of law and procedure, not to mention that these things do c= hange over time. A procedural stage setting of today may not be the setting= of a decade from now.
>>
>> Lots of protoc= ols talk about "deniability" and it's often a weird concept that is a term = of art and doesn't mean at all what a reasonable person might think. I've h= ad some discussions with people about the "deniability" of OTR and others, = where it doesn't mean what any non-expert would think it does.
&g= t;>
>> There are other deniability issues that are pecul= iar. A way that I've characterized this issue is that deniability assumes t= hat your adversary is either stupid or good. By "stupid" I mean that they u= nderstand what deniability is, and might not even look for it. (e.g. hidden= volumes in Truecrypt). By "good" I mean that you're going to give some mat= hematical explanation and they'll accept it. If the adversary is smart and = evil, deniability can be a weakness, not a strength.
>>
>> Here's an example, again with Truecrypt hidden volumes. I o= nce talked to some customs officials in a country that's not mine, and I as= ked them about hidden volumes. They said, "Oh, yeah, we know about hidden v= olumes and if we see Truecrypt, we *assume* there's a hidden volume. Why wo= uld anyone use Truecrypt and not have a hidden volume?" That might not be p= recisely evil, but it shows a basic issue. True evil would be that after ge= tting to the hidden volume, they ask you to open up the hidden volume in th= e hidden volume. You reply that there's only one level of hidden volume and= they reply (knowing that you're right, but because they're evil), "That's = your story. This is open source software. Open up the other hidden volume."=
>>
>> Another form of assumption as either= smartness or evil is that if you have a ring signature that could have bee= n made by Alice, Bob, or Charlie, they just assume that Alice made it and l= et Alice know that's they're working hypothesis since she's their suspect. = (I don't want to go too far down this rathole, but it might be the smart wa= y to bet. Suppose the signature was made at 4am Pacific or 12pm GMT and Ali= ce is the only European in that set -- it's a reasonable hypothesis that Al= ice made it.)
>>
>> Thus, when we talk abou= t deniability, let's talk about the specific security property and not an a= spirational thing like "deniable" that might not work out the way we think.= If the property is that a signature could be made by any element of a set,= that's a nice property, even if there are externalities that can winnow th= at set down, even to a single member.
>>
>>=        Jon
>>

= >I agree with the above. Ideally we would like to combine academic preci= sion with common sense definitions and be clear about ?>the threat model= too. I also agree that we should leave aside legal considerations for all = the reasons you mentioned and focus on >the social aspect of the facets = of deniability.

>We=E2=80=99ll chew through the= existing material to see what could make sense in terms of properties and = how we could achieve them in >practical terms. Obviously not all aspects= of deniability are straight forward in a group messaging protocol, all the= more so since >MLS has strong authentication guarantees that 1:1 protoc= ols might not have.

Without getting into any solutions, I just wanted to put forth s= ome common sense requirements.  I hope that I am understanding  h= ow deniability might work.   Please correct me if I have any misc= onceptions.

Companies doing financial transactions and w= ishing to use MLS might have a hard time if there were some aspects of deni= ability.  For example, if you do a stock trade, it is required to be r= ecorded.  If the stock trading company cannot prove that it was indeed= you that did the trade, then it becomes quite problematic. 

Also, for example, if you are getting advice from a medical prof= essional and they wish to know that it is indeed you that they are talking = to.  This is important for privacy and other issues.  One does no= t wish to give health information to just anyone.

I belie= ve I had stated in this group before that the "recording" would be done by = a completely transparent group member known to all parties.  For examp= le, when you call a business and you receive the message "You are on a reco= rded line."   There are quite a few use cases for such a scenario= in the business and medical worlds. 

I would suppor= t a common sense explanation of the various aspects of deniability along wi= th what cryptographic schemes would do and not do, if I am am making any se= nse!   I would be happy to work in a team dedicated to this effor= t.

Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insid= ethestack.com
(831) 659-8360
------=_Part_218289_1905556058.1579787145338-- From nobody Thu Jan 23 05:59:44 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 2A57D1200C1 for ; Thu, 23 Jan 2020 05:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 CUe5QBn6qNCc for ; Thu, 23 Jan 2020 05:59:39 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0255B12009C for ; Thu, 23 Jan 2020 05:59:39 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id j42so3143114wrj.12 for ; Thu, 23 Jan 2020 05:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c1KqrqygBYYq7I6eWMDzJSN0BF0jVHJtAPT0qO2pCbw=; b=R8C3VEIuSRFyGt73L7nfxgrIuj/Bbyr2L+EyNUeX10jhGGzwCZgpUZon+bjcBq3j7o dkE2A2RjV6/MJzZx9GWRPStdTcGnlPVTFDQmrmly2BNS6NoFQdioSEEFAAcP55QTyBlE T2ImOztUAbVImhBMPe2HLVPBeO5AvpAIEY3azBbgC0trZZNeJ4jFQzvmPLpQeIF9zXlv AT7R2iVx6PxiVB9BIToNNwBKc59lrMjQLsS1v5IwRLVCYAPoLRPA73qkwq89Vb9IAOLC tJ6SF17S7AiM+1KVcFYCkOVwPX0HIPZttj76/EoRAzxP6THvJHrDfF2cto1IyiHK+L81 umaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c1KqrqygBYYq7I6eWMDzJSN0BF0jVHJtAPT0qO2pCbw=; b=sRC9lb8a0xln8eXTIJy+zOZa51vJS/CGFn7FDZq8AhsI4of9OgWrJUHpEntsWLMdGs qFIGMET984sPGoJ5OvVNb3BpvHdWAugXZzTH7AiDNrxd5C3fiwtK4VwGo3Fglj5NNvvM NliOMlXHE8NLVMlaFAzBx/6vtbSxUYEq2qyJIxJy9SqjxRpFccqTdn5qioDdkqt6sXeY kIicORAGsNSfStV4rLgPvp49iMG2ZgnOl21ye1oWgujjBlZH2Nx9zap3RzxL65fAmZjB WIguixPCCf/iSDN3RRhBlIM4JxlduRtjSkoMI9tpkMSF1CU7gFhUlnwFw3iPqI3lB1A0 nFqA== X-Gm-Message-State: APjAAAVCRzkp5Ir1DdgA/Omj8YfQM22j0aWqEG+81E1gNtAaGNOUSfh3 yrQrI5vRaw6pTqC8O8zW5cDnDBMk X-Google-Smtp-Source: APXvYqy9+HP7bpX9q1Z1W7WEzOcjIywVL9r51prwu7aUMct34eob6SjO3UxqhcFtzfhB1k8HLKDcmQ== X-Received: by 2002:adf:e6c6:: with SMTP id y6mr17533685wrm.284.1579787976939; Thu, 23 Jan 2020 05:59:36 -0800 (PST) Received: from [134.96.225.154] (mbpc41.cs.uni-saarland.de. [134.96.225.154]) by smtp.gmail.com with ESMTPSA id b17sm3115617wrp.49.2020.01.23.05.59.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jan 2020 05:59:36 -0800 (PST) To: "nalini.elkins@insidethestack.com" , "jon@callas.org" , "raphael=40wire.com@dmarc.ietf.org" , "mls@ietf.org" References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> From: Cas Cremers Autocrypt: addr=cas.cremers@gmail.com; keydata= mQGNBFyjFJQBDADNlXG/t7Nd15sfLSf+jaDMUZJvnz59PW5OYoubAWqqNGQBK6A6ahPb6ebX epYdBp/ilE+n1KP/evaV8dMaktooeptOB7D3neOvRox73o2JEjNTC+8OU90dNmGo9UxAVPS9 HuEuJsmvvssiWg97hZBeaPf2F/Hfg2U+RlAKIpR+c+wdc2lTRMqhQXN8OskzQZzlEP8LrMER 1ZT9q22/bdN7nKnpsXSEB8hj8y1dErZHA3+6m73srG7Q7Muw5Kr6zCF4OTXrXsajHHsEyZFj L7qm9BYyrWQ9yXb0l0vWb+i1tzTEK20NoSJiapk3/0prU54dgK3FqQM8SRm7R1wd5mFGN+4x c8pMd/CvHZfJmN4WT581dxaKFMsTFRXMefMKrzbKTgYLsa6tjpFL/sVf06PSkihk/Tc6qrf0 0nxs6pmGHycfC70zwqqqgFdyYQqTUqMforH5cLpms55O4ONCJ6fk+r0fuQO4qXSRK2z00Rpz mJi0WcKyfiHbB/guH5Rqdc8AEQEAAbQjQ2FzIENyZW1lcnMgPGNhcy5jcmVtZXJzQGdtYWls LmNvbT6JAdQEEwEIAD4WIQRIa4Hi/W0N8sfSgzj/8IKxn6kiTQUCXKMUlgIbAwUJAeEzgAUL CQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD/8IKxn6kiTZlWDACFkJBQwDlyCwbp8/hoo4MM awQiLC43SZs8YcTYhX11JVBYvFX3JaphqNdzO8rabtEurHY+R3HOXtHOmMrh+dvDqHIt9q9F dW2B0b7Cs2ayvsI/wRjjS6YTMv8ufGDyLc+DvPvabiEMhCHCA1JQ/qBbzIM9D6DqcJqySR1V /nZjWWAgODQ6BN5xaDXZ8IZGv3s0BIvoCV4E0G5oTQY+3I2pxK40A/0yQERkG+P3xYx71QXQ EPQNOTou/JdWtoehpS5WK8z1PEhWTyVfhin0VXr29cCnKi/d7GIVMmniiEBH9R7QqYPqyJEb DvyUifwaS3HkJtjt1zFURBzeHW+usFza+5cN70qeHVyljjeNrMUAFa0aV1MuCDi4NQOMWkYu 3kjNEqELH+YCi16helZLy1X+AgYjiuzy58/O+WqgqOpnOVWTSBy79XX59ca47vS7BBrmGZTr 5ZvVIXGBHFmSHm0Lkn7TOeszR3L+TZUt8vv50M/+7b0mh+jl6J4i4vb1LsS5AY0EXKMUlQEM AMnddlUgDeoW5jU0pmylA2jtexsT/0EiY+Z0h1cBjP4vWcPJua9K/dBJwPujfshRBSYw97+W Z8h9CoFyK8nWVhRLtALwa9PrlpJ0T2PKbspnb1FTu+eTMEM05YxRD5y0eTY7Q/vdauZ/r1x8 CCOimBZ63Djh5xBogXBUUOm+aLArWaL0/Y/3OUdu00ztrL/IRUF3bDvJch58D6vxvw6IDGMG TzUWGcV0WDyYleUZ1qBEYRsa7JTJ71uJLLRc8NRnaEsD2XkHDhcwHoqk+DIwhuWAdo+i0TGJ fmTcqT2U+3X3WCkEh2Oj4PTA1eb1suEDoicueFGm1tcJ5q9dVuY3weZVDycfMmpzHl3bPhP4 EVkfXvOjUgO0E5UnIo24NnmugBBslEW3+DEd38IUZPjmzYFU8v+OMShJ8siVS7+BTL/na3/g lBhrvNjFNG9p5Wxe+572lZuNa+7tphVb+ipnt2h+3RH/I83fekUODm/+CeVhwYMAhKRfLWhi sfpHogOkNQARAQABiQG8BBgBCAAmFiEESGuB4v1tDfLH0oM4//CCsZ+pIk0FAlyjFJUCGwwF CQHhM4AACgkQ//CCsZ+pIk0YGgv/YENZhZTtgBRVP9FeGTnpJ+YHwzfIXXExj/kbV0c/pSdQ j4vhKclmDRd/rX/IpEpvipfPNgJMfAbiq0uPYgmmoIlGecOQAzYWJxsMPNs5Coz0xDU2hRx+ OnY1ueusLvJN/msxxhdT0lnnQiaGKw5dntnu8dUjdG1vvESd2Mg5rmXalo3MfERF465PYz4r ewIyELT8oaCyqldDrNyNxn64fsDqoYx/md8yQQJJl//LHuVXTy7ylN/NiuF9FWO8z19Ttc/E JeHwCASU24+S4o5gj0A2HgUoxNDzhpxtUGfRH3shGnJ1KeqsRtgxwocd6XL8kaXzYmVOgOyW CN6pu6PpISxW82HogdcblVhvudLoZdO5enwHoWwxfqH6lc0O2jZ86eZb8NiFPi5hxXjEzm9d UBBj4bryCnq9z3UtBX+WUW1bkCCjjrtGVI/peZWP3TyNkgZ6Xwt/tj2Vpqf/2ujnDnWPnztB hoF/x6+xCfXBkpKQD8RbIoBO1sJ6VEDwpIks Message-ID: Date: Thu, 23 Jan 2020 14:59:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <2060195243.218290.1579787145340@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 13:59:42 -0000 Hi, The "recording" / "non-deniable" properties you are suggesting are not part of the desired properties described in the charter, so I think it is best to first try to meet the intended MLS goals -- it's complex enough as it is. But perhaps more importantly, I think that applications that wish to explicitly break any deniability properties can easily do so at the application layer, and this has no impact on the underlying design of MLS. I don't see why we would need to cater for this at the MLS layer even if some messaging applications would like that functionality. For the doctor scenario you mention one would of course aim for authentication, but that's a different property altogether. We're aiming for security first, I think. Best, Cas On 1/23/20 2:45 PM, nalini.elkins@insidethestack.com wrote: > All, > >>> On 22 Jan 2020, at 20:59, Jon Callas > wrote: >>> >>> >>> >>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert > > wrote: >>>>> >>>>> For general context: Deniability is something that is being > discussed right now and we should send some update to the list as soon > as we have sorted things a bit better. >>>>> >>> >>> Please do. I have some tart opinions about deniability, and don't > want to waste anyone's time before we know what we're really talking about. >>> >>> It's also probably best not to talk about things like courts and so on. >>> >>> There are a number of reasons, starting with jurisdictional issues. > Inevitably, each of us will talk about legal issues through the lens of > our own native jurisdiction and that lens is cracked with our own > misunderstandings of law and procedure, not to mention that these things > do change over time. A procedural stage setting of today may not be the > setting of a decade from now. >>> >>> Lots of protocols talk about "deniability" and it's often a weird > concept that is a term of art and doesn't mean at all what a reasonable > person might think. I've had some discussions with people about the > "deniability" of OTR and others, where it doesn't mean what any > non-expert would think it does. >>> >>> There are other deniability issues that are peculiar. A way that I've > characterized this issue is that deniability assumes that your adversary > is either stupid or good. By "stupid" I mean that they understand what > deniability is, and might not even look for it. (e.g. hidden volumes in > Truecrypt). By "good" I mean that you're going to give some mathematical > explanation and they'll accept it. If the adversary is smart and evil, > deniability can be a weakness, not a strength. >>> >>> Here's an example, again with Truecrypt hidden volumes. I once talked > to some customs officials in a country that's not mine, and I asked them > about hidden volumes. They said, "Oh, yeah, we know about hidden volumes > and if we see Truecrypt, we *assume* there's a hidden volume. Why would > anyone use Truecrypt and not have a hidden volume?" That might not be > precisely evil, but it shows a basic issue. True evil would be that > after getting to the hidden volume, they ask you to open up the hidden > volume in the hidden volume. You reply that there's only one level of > hidden volume and they reply (knowing that you're right, but because > they're evil), "That's your story. This is open source software. Open up > the other hidden volume." >>> >>> Another form of assumption as either smartness or evil is that if you > have a ring signature that could have been made by Alice, Bob, or > Charlie, they just assume that Alice made it and let Alice know that's > they're working hypothesis since she's their suspect. (I don't want to > go too far down this rathole, but it might be the smart way to bet. > Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is > the only European in that set -- it's a reasonable hypothesis that Alice > made it.) >>> >>> Thus, when we talk about deniability, let's talk about the specific > security property and not an aspirational thing like "deniable" that > might not work out the way we think. If the property is that a signature > could be made by any element of a set, that's a nice property, even if > there are externalities that can winnow that set down, even to a single > member. >>> >>>       Jon >>> > >>I agree with the above. Ideally we would like to combine academic > precision with common sense definitions and be clear about ?>the threat > model too. I also agree that we should leave aside legal considerations > for all the reasons you mentioned and focus on >the social aspect of the > facets of deniability. > >>We’ll chew through the existing material to see what could make sense > in terms of properties and how we could achieve them in >practical > terms. Obviously not all aspects of deniability are straight forward in > a group messaging protocol, all the more so since >MLS has strong > authentication guarantees that 1:1 protocols might not have. > > Without getting into any solutions, I just wanted to put forth some > common sense requirements.  I hope that I am understanding  how > deniability might work.   Please correct me if I have any misconceptions. > > Companies doing financial transactions and wishing to use MLS might have > a hard time if there were some aspects of deniability.  For example, if > you do a stock trade, it is required to be recorded.  If the stock > trading company cannot prove that it was indeed you that did the trade, > then it becomes quite problematic.  > > Also, for example, if you are getting advice from a medical professional > and they wish to know that it is indeed you that they are talking to.  > This is important for privacy and other issues.  One does not wish to > give health information to just anyone. > > I believe I had stated in this group before that the "recording" would > be done by a completely transparent group member known to all parties.  > For example, when you call a business and you receive the message "You > are on a recorded line."   There are quite a few use cases for such a > scenario in the business and medical worlds.  > > I would support a common sense explanation of the various aspects of > deniability along with what cryptographic schemes would do and not do, > if I am am making any sense!   I would be happy to work in a team > dedicated to this effort. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Thu Jan 23 06:30:27 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 B3245120801 for ; Thu, 23 Jan 2020 06:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 ZPRjznacqZJu for ; Thu, 23 Jan 2020 06:30:23 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 694CE120133 for ; Thu, 23 Jan 2020 06:30:23 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id z26so2412936lfg.13 for ; Thu, 23 Jan 2020 06:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YTZuZoyVNtZ/RqoU8JBleYTipq3+8KqODW4JFMdC2dM=; b=ZM2aDinE5S1PfverChah5uuthXsjdAJRxU+nZtDA+a6zCPTdo4vx27p5NowFMfP8hr JHHysvRhd2BfsNo0VQRQOxrokWumKP7V1yoj6ykCA1Nihb6HCQIG1tWAb9eWL9C+bftl R0RW9vTtabpBKaGc5JmnTVuytYMSUVb855oXE= 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=YTZuZoyVNtZ/RqoU8JBleYTipq3+8KqODW4JFMdC2dM=; b=fzQAN89V65U9CV7YHf31SMTlZz3xa1FCh1bIl+fW1qaO4e/ruC1AN1PxjyEkeij8Yq tpAKwGlS4F0Z8sFHCi1IjTKeHwP+2PofKzMOeyTVTwa7fHdC3qnTjbXpgIeDubq3IAC/ JYRpktSYPdLFUJdeSYQidyE/7eE2lkpSsQkt5eNSO4a1qrQ0DCgQzgGSCIL/oaOlEp4F kC4vmbc9VNcdzv4X3nKKW+VOOQ4I5Ynobtm/ZewP4jr5hm4ALuyUAxRF20K/mjN2zStk zkAVDQ3TpPBwnvYhyGFOYanZDHD1Rg5O9kptjPoFfo+TkUxNrOhwigye/q9ciAEAbwGL nz/w== X-Gm-Message-State: APjAAAUXCl6Eu6XPK3BuoJYTBwl96gTw6DYzCQnm1nDovOdlebEjgQkH QHxjtM21HkBs3RO3UQtixV2uR/s+vAM1eCR9MI1G9w== X-Google-Smtp-Source: APXvYqwNcYa9xod3s3yvCVwuY94CZylAfjlmZR5cEbuoptvwBNEIYYExlKc/T806cKlXI3BZ6vnwXBhTkvXfPQqnbXo= X-Received: by 2002:ac2:5467:: with SMTP id e7mr4448166lfn.74.1579789821634; Thu, 23 Jan 2020 06:30:21 -0800 (PST) MIME-Version: 1.0 References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> In-Reply-To: From: Dave Cridland Date: Thu, 23 Jan 2020 14:30:10 +0000 Message-ID: To: Cas Cremers Cc: "nalini.elkins@insidethestack.com" , "jon@callas.org" , "raphael=40wire.com@dmarc.ietf.org" , "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000237e7c059ccf7bc8" Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 14:30:26 -0000 --000000000000237e7c059ccf7bc8 Content-Type: text/plain; charset="UTF-8" On Thu, 23 Jan 2020 at 13:59, Cas Cremers wrote: > We're aiming for security first, I think. If we mandate deniability and mandate PFS, then the risk is that the threat model ends up less applicable. We can work around the PFS by (in effect) using MLS as a groupwise key exchange protocol and exporting a longer term key for message encryption, but if we destroy cryptographic integrity post-facto, as I assume we mean by deniability, then that makes life increasingly unpleasant for the cases where people actually want different properties. In short, preventing various groups making use of MLS is not security first. Dave. --000000000000237e7c059ccf7bc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 23 Jan 2020 at 13:59, Cas Cre= mers <cas.cremers@gmail.com= > wrote:
We're aiming for security first, I think.

If we mandate deniability and mandate PFS, then the risk is that the thr= eat model ends up less applicable.

We can work aro= und the PFS by (in effect) using MLS as a groupwise key exchange protocol a= nd exporting a longer term key for message encryption, but if we destroy cr= yptographic integrity post-facto, as I assume we mean by deniability, then = that makes life increasingly unpleasant for the cases where people actually= want different properties.

In short, preventing v= arious groups making use of MLS is not security first.

=
Dave.
--000000000000237e7c059ccf7bc8-- From nobody Thu Jan 23 06:33:32 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 11A8F12080C for ; Thu, 23 Jan 2020 06:33:31 -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, 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=yahoo.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 itXcHTIei9IX for ; Thu, 23 Jan 2020 06:33:29 -0800 (PST) Received: from sonic303-27.consmr.mail.ne1.yahoo.com (sonic303-27.consmr.mail.ne1.yahoo.com [66.163.188.153]) (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 CC156120813 for ; Thu, 23 Jan 2020 06:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579790006; bh=DwH+jlbJaZGIp4SCBqer6D5Mz+rTbi01240Bu/8Cadg=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=KzakiegFM2ZLzL10dwhFKmpht6AuZNU/cYDXyZtrqa711HLtMFZ5lXKyVRaKdufFpi1DZdqI98LVWe6A++WVRe/JECuN4KQNyinwFnYNzDlm8t3sFLBbS74fMkQWUgk/JecqM/yCJM/w3ryt6z5jObxcOfIXJ6jl62XnAFqWh0PTJQ9GVt1srzeU9FGEUl884n4xSn1tFDZIQcUOIWDf66wpcrKrAP9UF0ynxbZSAUZvRccyA2haB4Q0Zn5FKogqB5oECdZ7hQd5cP+EcZmlHrm07AGzRg1E393sUG5cvYJo32HwGN/4b3PxrYfaiPlHaw9WU0a2p+enAtOwIAHzWA== X-YMail-OSG: Lpn1m9cVM1niIfcE9AZudEAB9SxuU1PCT1yRiHL.f6iLZm77QD0mO06srE.vfY. 1GNBRg4uRn60TBJhoJeWpq8TsFgqcUNvxR8Eh7Mo341ekjnGcciZEP0IZqIwRTikP2P48NoLlJie MdLIObPbg4tdeAOa1vr.JJHz.jj8n7gkIbxGmOsJECF8xC95zDpkFHID.ZFHWzLJWCAw0RE2qt4Z ixHXQ7vMAYAPbUGHNbtaDcC4Sa.mS6R_6NUBhbdsxzySlkb5De2v04bq3BFB.1euz_CsLbDP2NDi Akg3Trc9ZmhlXADggRdjGS4hGOPtj9A0VAIS8b.DoOVNZd5O3nopLkLLnLbV_v4eo3bnajXzwaLe pCw.L03uWC4bujA1WLqDhSv9OJpjRQkS2JwRFuejYhphpLoZgkMSjEjOIa2WGCLT4qvKCdV02tna rN6ZmNAPiTaqZiAXTc9DL1HcJG.To5P4blKYYtFyn8W7BB869Xf9dnvRbDHE8nyytdsF0sR1eo2Y 0OUE59kUso36bJvOhlprJ6Zcl7hko.6ksIenC1xqS3cqv7.cSt4SBx3gVa9SYAxT2XRnyxfCMVBj 0aRYhYdHNMDz4P5sqHzRU20eBCR3Y4xXpXzGvVt56bcLVTZY5aPODvFThIjC4kcaC7kQ4ux_yXuE HAD.0Eflb72aFSRSesBdTYGOpvZDmcNuSkeLSB8edUtBaUzr_HPwvqMgk5fI6fK5tcs31W1jwrp6 hqrwsqne.2gGBHcxVHmY4Tr0ZslYWTjJyK4E3_6NQGmkww8fdN_i1T9MW.RUZIL0s9hSW0QM44gO UG1vsaQw.KCMF5YNlTVhjKiY1ajYTb9EsjxXdJrPviVnSVwlaVw.4p6d653LUucnRCFeELvLIBEQ Cp5gK.9Ly6xams4Syv4RD7STPYXDZ8iuKxx7S5IJ_NSDhveEnlDiBHKVWqHrc9hM5WTJ71Qtpo6t yhPpfb7lYPnkk1raHU3NC2URaeD0MDXAbwmJjCdyOlYdPXOfpOSVuFwdqO8BDORHK4nkkW5.ARIo jE1LXkNS7kT64GB9l_ej0eF_oxAX.x7TscDTX6tnvxe13fhClLB5eqt8Dadqvoegj887TzQF8NhM 707iRF8FKzOPWXIOPUCS2w8WAQqOAIQujU2e3P2wvuWdS_teBgA8oS9Ce4PHJGBQSV6bgmNlsZIc rx46AjF_BUBT7MKvZyCw9pb52Lr7drWTrEJbX4Z1LVQEBX_5NQcrS0OnNlJJ.fKaYCBcZVriMtwY IU3YJX1ygN6coZG1KkJUoUyHzgP3wGCgDbNd.Zn9rPpQ0lMOy7f0xY0JBGIUaWUOYJA9dIdFQfH2 lOesOzGTdpUXvEV4hpO6PHIMGqctvYnGARfTH.76fOpw_pWjmHh6zlb16mIkyK2o1ZnZdrF4wVr7 9J.SCh2Rloqyh50MR Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 14:33:26 +0000 Date: Thu, 23 Jan 2020 14:33:23 +0000 (UTC) From: "nalini.elkins@insidethestack.com" To: "jon@callas.org" , "raphael=40wire.com@dmarc.ietf.org" , "mls@ietf.org" , Cas Cremers Message-ID: <2061064987.251760.1579790003975@mail.yahoo.com> In-Reply-To: References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_251759_14686739.1579790003972" X-Mailer: WebService/1.1.14873 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36 Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 14:33:31 -0000 ------=_Part_251759_14686739.1579790003972 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cas, =20 On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers wrote: =20 =20 >Hi, >The "recording" / "non-deniable" properties you are suggesting are not >part of the desired properties described in the charter, so I think it >is best to first try to meet the intended MLS goals -- it's complex >enough as it is. Maybe we have a misunderstanding.=C2=A0 From the charter: o Message Confidentiality - Messages can only be read=C2=A0by members of th= e group o Message Integrity and Authentication - Each message=C2=A0has been sent by= an authenticated sender, and has=C2=A0not been tampered with o Membership Authentication - Each participant can verify=C2=A0the set of m= embers in the group I just want to make sure that a group member cannot say after the fact that= they were not a member of the group.=C2=A0 =C2=A0Let's leave the "recordin= g" participant out of the discussion.=C2=A0 It is taken care of by complyin= g with the Authentication statement above. Nalini On 1/23/20 2:45 PM, nalini.elkins@insidethestack.com wrote: > All, >=20 >>> On 22 Jan 2020, at 20:59, Jon Callas > wrote: >>> >>> >>> >>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert > > wrote: >>>>> >>>>> For general context: Deniability is something that is being > discussed right now and we should send some update to the list as soon > as we have sorted things a bit better. >>>>> >>> >>> Please do. I have some tart opinions about deniability, and don't > want to waste anyone's time before we know what we're really talking abou= t. >>> >>> It's also probably best not to talk about things like courts and so on. >>> >>> There are a number of reasons, starting with jurisdictional issues. > Inevitably, each of us will talk about legal issues through the lens of > our own native jurisdiction and that lens is cracked with our own > misunderstandings of law and procedure, not to mention that these things > do change over time. A procedural stage setting of today may not be the > setting of a decade from now. >>> >>> Lots of protocols talk about "deniability" and it's often a weird > concept that is a term of art and doesn't mean at all what a reasonable > person might think. I've had some discussions with people about the > "deniability" of OTR and others, where it doesn't mean what any > non-expert would think it does. >>> >>> There are other deniability issues that are peculiar. A way that I've > characterized this issue is that deniability assumes that your adversary > is either stupid or good. By "stupid" I mean that they understand what > deniability is, and might not even look for it. (e.g. hidden volumes in > Truecrypt). By "good" I mean that you're going to give some mathematical > explanation and they'll accept it. If the adversary is smart and evil, > deniability can be a weakness, not a strength. >>> >>> Here's an example, again with Truecrypt hidden volumes. I once talked > to some customs officials in a country that's not mine, and I asked them > about hidden volumes. They said, "Oh, yeah, we know about hidden volumes > and if we see Truecrypt, we *assume* there's a hidden volume. Why would > anyone use Truecrypt and not have a hidden volume?" That might not be > precisely evil, but it shows a basic issue. True evil would be that > after getting to the hidden volume, they ask you to open up the hidden > volume in the hidden volume. You reply that there's only one level of > hidden volume and they reply (knowing that you're right, but because > they're evil), "That's your story. This is open source software. Open up > the other hidden volume." >>> >>> Another form of assumption as either smartness or evil is that if you > have a ring signature that could have been made by Alice, Bob, or > Charlie, they just assume that Alice made it and let Alice know that's > they're working hypothesis since she's their suspect. (I don't want to > go too far down this rathole, but it might be the smart way to bet. > Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is > the only European in that set -- it's a reasonable hypothesis that Alice > made it.) >>> >>> Thus, when we talk about deniability, let's talk about the specific > security property and not an aspirational thing like "deniable" that > might not work out the way we think. If the property is that a signature > could be made by any element of a set, that's a nice property, even if > there are externalities that can winnow that set down, even to a single > member. >>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Jon >>> >=20 >>I agree with the above. Ideally we would like to combine academic > precision with common sense definitions and be clear about ?>the threat > model too. I also agree that we should leave aside legal considerations > for all the reasons you mentioned and focus on >the social aspect of the > facets of deniability. >=20 >>We=E2=80=99ll chew through the existing material to see what could make s= ense > in terms of properties and how we could achieve them in >practical > terms. Obviously not all aspects of deniability are straight forward in > a group messaging protocol, all the more so since >MLS has strong > authentication guarantees that 1:1 protocols might not have. >=20 > Without getting into any solutions, I just wanted to put forth some > common sense requirements.=C2=A0 I hope that I am understanding=C2=A0 how > deniability might work.=C2=A0 =C2=A0Please correct me if I have any misco= nceptions. >=20 > Companies doing financial transactions and wishing to use MLS might have > a hard time if there were some aspects of deniability.=C2=A0 For example,= if > you do a stock trade, it is required to be recorded.=C2=A0 If the stock > trading company cannot prove that it was indeed you that did the trade, > then it becomes quite problematic.=C2=A0 >=20 > Also, for example, if you are getting advice from a medical professional > and they wish to know that it is indeed you that they are talking to.=C2= =A0 > This is important for privacy and other issues.=C2=A0 One does not wish t= o > give health information to just anyone. >=20 > I believe I had stated in this group before that the "recording" would > be done by a completely transparent group member known to all parties.=C2= =A0 > For example, when you call a business and you receive the message "You > are on a recorded line."=C2=A0 =C2=A0There are quite a few use cases for = such a > scenario in the business and medical worlds.=C2=A0 >=20 > I would support a common sense explanation of the various aspects of > deniability along with what cryptographic schemes would do and not do, > if I am am making any sense!=C2=A0 =C2=A0I would be happy to work in a te= am > dedicated to this effort. >=20 > Thanks, >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=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 ------=_Part_251759_14686739.1579790003972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Cas,
=20
=20

On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cre= mers <cas.cremers@gmail.com> wrote:


>Hi,


>The "recording" / "non-deniable" properties you are suggest= ing are not
>part of the desired properties described = in the charter, so I think it
>is best to first try to= meet the intended MLS goals -- it's complex
>enough a= s it is.


Maybe we have a misunderstanding.  Fro= m the charter:


o Message Confidentiality - Messages can only be re= ad by members of the group

o Message Integrity and Authentication - Each message has been sent by an authenticated sender, an= d has not been tampered with<= /span>

o Membership Authentication - Each participant can verify the set of members in the group=


I just want to make sure that a gr= oup member cannot say after the fact that they were not a member of the gro= up.   Let's leave the "recording" participant out of the discussi= on.  It is taken care of by complying with the Authentication statemen= t above.


Nalini


On 1/23/20 2:45 PM, nalini.elkins@insidethestack.com wrote:
= > All,
>
>>> On 22 Jan = 2020, at 20:59, Jon Callas <jon@callas.org>> wrote:>>>
>>>
>>>
>>>>> On Jan 22, 2020, at= 7:54 AM, Raphael Robert
> <raphael=3D40wire.com@dmarc.ietf.org>> wrote:
>&= gt;>>>
>>>>> For general context:= Deniability is something that is being
> discussed ri= ght now and we should send some update to the list as soon
> as we have sorted things a bit better.
>>>= ;>>
>>>
>>> Ple= ase do. I have some tart opinions about deniability, and don't
> want to waste anyone's time before we know what we're really tal= king about.
>>>
>>> I= t's also probably best not to talk about things like courts and so on.
>>>
>>> There are a numbe= r of reasons, starting with jurisdictional issues.
> I= nevitably, each of us will talk about legal issues through the lens of
> our own native jurisdiction and that lens is cracked wit= h our own
> misunderstandings of law and procedure, no= t to mention that these things
> do change over time. = A procedural stage setting of today may not be the
> s= etting of a decade from now.
>>>
>>> Lots of protocols talk about "deniability" and it's often a= weird
> concept that is a term of art and doesn't mea= n at all what a reasonable
> person might think. I've = had some discussions with people about the
> "deniabil= ity" of OTR and others, where it doesn't mean what any
&g= t; non-expert would think it does.
>>>
>>> There are other deniability issues that are peculiar= . A way that I've
> characterized this issue is that d= eniability assumes that your adversary
> is either stu= pid or good. By "stupid" I mean that they understand what
> deniability is, and might not even look for it. (e.g. hidden volumes = in
> Truecrypt). By "good" I mean that you're going to= give some mathematical
> explanation and they'll acce= pt it. If the adversary is smart and evil,
> deniabili= ty can be a weakness, not a strength.
>>>
>>> Here's an example, again with Truecrypt hidden vol= umes. I once talked
> to some customs officials in a c= ountry that's not mine, and I asked them
> about hidde= n volumes. They said, "Oh, yeah, we know about hidden volumes
> and if we see Truecrypt, we *assume* there's a hidden volume. Why= would
> anyone use Truecrypt and not have a hidden vo= lume?" That might not be
> precisely evil, but it show= s a basic issue. True evil would be that
> after getti= ng to the hidden volume, they ask you to open up the hidden
> volume in the hidden volume. You reply that there's only one level = of
> hidden volume and they reply (knowing that you're= right, but because
> they're evil), "That's your stor= y. This is open source software. Open up
> the other h= idden volume."
>>>
>>>= ; Another form of assumption as either smartness or evil is that if you
> have a ring signature that could have been made by Alic= e, Bob, or
> Charlie, they just assume that Alice made= it and let Alice know that's
> they're working hypoth= esis since she's their suspect. (I don't want to
> go = too far down this rathole, but it might be the smart way to bet.
> Suppose the signature was made at 4am Pacific or 12pm GMT an= d Alice is
> the only European in that set -- it's a r= easonable hypothesis that Alice
> made it.)
>>>
>>> Thus, when we talk ab= out deniability, let's talk about the specific
> secur= ity property and not an aspirational thing like "deniable" that
> might not work out the way we think. If the property is that a = signature
> could be made by any element of a set, tha= t's a nice property, even if
> there are externalities= that can winnow that set down, even to a single
> mem= ber.
>>>
>>>  &n= bsp;    Jon
>>>
>=
>>I agree with the above. Ideally we would like t= o combine academic
> precision with common sense defin= itions and be clear about ?>the threat
> model too.= I also agree that we should leave aside legal considerations
> for all the reasons you mentioned and focus on >the social asp= ect of the
> facets of deniability.
= >
>>We=E2=80=99ll chew through the existing mat= erial to see what could make sense
> in terms of prope= rties and how we could achieve them in >practical
>= terms. Obviously not all aspects of deniability are straight forward in> a group messaging protocol, all the more so since >= MLS has strong
> authentication guarantees that 1:1 pr= otocols might not have.
>
> With= out getting into any solutions, I just wanted to put forth some
> common sense requirements.  I hope that I am understanding=   how
> deniability might work.   Pleas= e correct me if I have any misconceptions.
>
> Companies doing financial transactions and wishing to use ML= S might have
> a hard time if there were some aspects = of deniability.  For example, if
> you do a stock= trade, it is required to be recorded.  If the stock
> trading company cannot prove that it was indeed you that did the trad= e,
> then it becomes quite problematic. 
>
> Also, for example, if you are gettin= g advice from a medical professional
> and they wish t= o know that it is indeed you that they are talking to. 
> This is important for privacy and other issues.  One does not= wish to
> give health information to just anyone.
>
> I believe I had stated in this = group before that the "recording" would
> be done by a= completely transparent group member known to all parties. 
> For example, when you call a business and you receive the me= ssage "You
> are on a recorded line."   Ther= e are quite a few use cases for such a
> scenario in t= he business and medical worlds. 
>
> I would support a common sense explanation of the various aspects= of
> deniability along with what cryptographic scheme= s would do and not do,
> if I am am making any sense!&= nbsp;  I would be happy to work in a team
> dedic= ated to this effort.
>
> Thanks,=
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-= 8360

>
> _________________= ______________________________
> 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

------=_Part_251759_14686739.1579790003972-- From nobody Thu Jan 23 06:45:39 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 D65E81200C5 for ; Thu, 23 Jan 2020 06:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADW83Y8rrBxx for ; Thu, 23 Jan 2020 06:45:35 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCE312004D for ; Thu, 23 Jan 2020 06:45:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,354,1574118000"; d="scan'208";a="432733524" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 15:45:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Benjamin Beurdouche In-Reply-To: Date: Thu, 23 Jan 2020 15:45:21 +0100 Cc: Cas Cremers , ML Messaging Layer Security , "raphael=40wire.com@dmarc.ietf.org" , "jon@callas.org" , "nalini.elkins@insidethestack.com" Content-Transfer-Encoding: quoted-printable Message-Id: <05F0D548-5F29-4AE2-BD49-E2E559CF6E95@inria.fr> References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> To: Dave Cridland X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 14:45:37 -0000 > We can work around the PFS by (in effect) using MLS as a groupwise key = exchange protocol and exporting a longer term key for message = encryption, but if we destroy cryptographic integrity post-facto, as I = assume we mean by deniability, then that makes life increasingly = unpleasant for the cases where people actually want different = properties. >=20 > In short, preventing various groups making use of MLS is not security = first. In general, I don=E2=80=99t see deniability and authentication as such a = strong opposition. But anyway, MLS is currently at a sweet spot in terms of design: As a default, because we have such a variety of use cases for the = protocol, the authentication service is responsible for the biding between an identity and the = signature key which is used by the protocol to authenticate members whether it is in a deniable way = or not. The authors and collaborators of the working group are gonna carefully = document each security tradeoffs in the architecture document, but ultimately, = since each provider has the ability to tune the exact way to provide and verify these = signing keys, I think there is no concern to have overall. We will remain careful to allow all these = use cases... B. From nobody Thu Jan 23 06:55:30 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 12F2D12020A for ; Thu, 23 Jan 2020 06:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 qeQWcrEF6utr for ; Thu, 23 Jan 2020 06:55:26 -0800 (PST) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (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 A791B12013B for ; Thu, 23 Jan 2020 06:55:26 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 483QLN4prqzQlJk for ; Thu, 23 Jan 2020 15:55:24 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id 4eL6Vm_EomCv for ; Thu, 23 Jan 2020 15:55:19 +0100 (CET) To: mls@ietf.org References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> From: Konrad Kohbrok Message-ID: Date: Thu, 23 Jan 2020 15:55:18 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 14:55:29 -0000 Hi Dave, I'm not sure, I understand your use-case here. Regarding FS: Any participant is free to just keep a log of the plaintexts, thus circumventing any FS guarantee. If you want to log the keys, any party can do that as well. If I'm not mistaken could also simply opt not to use an RTreeKEM ciphersuite and never update the recording party's leaf key. Regarding deniability: Similarly, any member of a group can simply sign their messages using their static identity key at the application layer. This would effectively destroy deniability, but it is up to the application to make that decision. I guess my point is that destroying deniability (and FS) at the application layer is easier then getting it if it is not built into the protocol in the first place. Cheers, Konrad On 23.01.20 15:30, Dave Cridland wrote: > > > On Thu, 23 Jan 2020 at 13:59, Cas Cremers > wrote: > > We're aiming for security first, I think. > > > If we mandate deniability and mandate PFS, then the risk is that the threat > model ends up less applicable. > > We can work around the PFS by (in effect) using MLS as a groupwise key exchange > protocol and exporting a longer term key for message encryption, but if we > destroy cryptographic integrity post-facto, as I assume we mean by deniability, > then that makes life increasingly unpleasant for the cases where people actually > want different properties. > > In short, preventing various groups making use of MLS is not security first. > > Dave. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Thu Jan 23 07:36:10 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 84CB212083E for ; Thu, 23 Jan 2020 07:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=cridland.net 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 38UHt1fEb3a0 for ; Thu, 23 Jan 2020 07:36:01 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 2D13512083D for ; Thu, 23 Jan 2020 07:36:01 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l18so2642699lfc.1 for ; Thu, 23 Jan 2020 07:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/57Yi9akjFf+EQYQ1nSASh9G+DmfbjUabxMvbb7Bdk4=; b=NGFvizWRu1S/jQwOo6VMKpI4fBxjASaw1rPEITpymrbdDwujp5nTztqW2bAyql77PL eEAdorHWfIlR7dRD49Az7ZS9O4VfFDYnI30FuOXovskDFUhk8vcwfvwSXKWZZNBZODF+ ZRt0mPM/lvHZhLgmqOlKl5LseEeGZolT444a0= 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=/57Yi9akjFf+EQYQ1nSASh9G+DmfbjUabxMvbb7Bdk4=; b=ffa0rM6B5NKjwlx9Osbvi0em5XB+5uJRRGs44JK/wGsvMN8WYU1pKIsyBJBgCGxL7/ BCy2QUXQhFWcOhjJi6kSRQYgvCOe+2g7oMNhkPy8mCAL3EMu8C6O7P06bVSE9knoBSFf k36/lRtWnWu2/4CYbRtwghd8Ko5zd7tzLnDRnHGfbUxjVhIGpo8jR03hyBnSXVmycDKF 2equ2KXgDlOYPcSLCIbg/eHwO56cQg59RE9vEI7pbTVQ1e5AS32KS/L4IV7JIy/h/Unc +doPq4ASOaxUwDdJTZAtQRH5t64SzM8hl0fWrwMsGGoDk0wSHEhIwaeB4CIHir9VrewR +Urw== X-Gm-Message-State: APjAAAVnmAKLPeP8WeK/PEOMvVWz+f7BatqSDsPBsJ/KxrtNypGk7etD Ksef5EaH/Fa5uyzRXT1LmEE8+T2+yLu9GFgPXHHAKf9Q+JU= X-Google-Smtp-Source: APXvYqzVAeU9CSiwuHP385duVvbfiRPVNGbvxoE7/JyL/OQitPJjG0xQKwzCMfPoNh1O5JSPqX5L7rMghL9VruHyTfQ= X-Received: by 2002:ac2:5549:: with SMTP id l9mr5006349lfk.53.1579793759278; Thu, 23 Jan 2020 07:35:59 -0800 (PST) MIME-Version: 1.0 References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> In-Reply-To: From: Dave Cridland Date: Thu, 23 Jan 2020 15:35:48 +0000 Message-ID: To: Konrad Kohbrok Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d738e3059cd06523" Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 15:36:03 -0000 --000000000000d738e3059cd06523 Content-Type: text/plain; charset="UTF-8" On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok wrote: > Hi Dave, > > I'm not sure, I understand your use-case here. > > I work for Pando, doing clinical messaging within the NHS in the UK, and elsewhere. Quite happy for the NHS to read doctors' and nurses' messages about patients, less happy for us to be exposed or for anyone who picks up a nurse's phone. > Regarding FS: Any participant is free to just keep a log of the > plaintexts, thus > circumventing any FS guarantee. If you want to log the keys, any party can > do > that as well. If I'm not mistaken could also simply opt not to use an > RTreeKEM > ciphersuite and never update the recording party's leaf key. > > We can't, actually, but as I say we can export a stable key for message encryption at each epoch so we're covered. (We cannot keep a log of the plaintexts since that would place persistent plaintext data on the user devices which would be problematic for us, since it's patient data). > Regarding deniability: Similarly, any member of a group can simply sign > their > messages using their static identity key at the application layer. This > would > effectively destroy deniability, but it is up to the application to make > that > decision. > Yes, that would probably work. I guess my point is that destroying deniability (and FS) at the application > layer is easier then getting it if it is not built into the protocol in the > first place. > Almost certainly; though this is an ever-increasing number of hoops to jump through. My concern is that baking in a very particular definition of "security" runs the risk that it either outright prevents the use in some cases, or simply prices people out of the market in technical knowledge terms. I am already going to end up writing much more cryptographic code than I'd like to use MLS. Writing more doesn't fill me with confidence. > > Cheers, > Konrad > > On 23.01.20 15:30, Dave Cridland wrote: > > > > > > On Thu, 23 Jan 2020 at 13:59, Cas Cremers > > wrote: > > > > We're aiming for security first, I think. > > > > > > If we mandate deniability and mandate PFS, then the risk is that the > threat > > model ends up less applicable. > > > > We can work around the PFS by (in effect) using MLS as a groupwise key > exchange > > protocol and exporting a longer term key for message encryption, but if > we > > destroy cryptographic integrity post-facto, as I assume we mean by > deniability, > > then that makes life increasingly unpleasant for the cases where people > actually > > want different properties. > > > > In short, preventing various groups making use of MLS is not security > first. > > > > Dave. > > > > _______________________________________________ > > 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 > --000000000000d738e3059cd06523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 23 Jan 2020 at 14:55, Konrad = Kohbrok <konrad.kohbrok@= datashrine.de> wrote:
Hi Dave,

I'm not sure, I understand your use-case here.


I work for Pando, doing clinical messa= ging within the NHS in the UK, and elsewhere. Quite happy for the NHS to re= ad doctors' and nurses' messages about patients, less happy for us = to be exposed or for anyone who picks up a nurse's phone.
=C2= =A0
Regarding FS: Any participant is free to just keep a log of the plaintexts,= thus
circumventing any FS guarantee. If you want to log the keys, any party can = do
that as well. If I'm not mistaken could also simply opt not to use an R= TreeKEM
ciphersuite and never update the recording party's leaf key.


We can't, actually, but as I say w= e can export a stable key for message encryption at each epoch so we're= covered.

(We cannot keep a log of the plaintexts = since that would place persistent plaintext data on the user devices which = would be problematic for us, since it's patient data).
=C2=A0=
Regarding deniability: Similarly, any member of a group can simply sign the= ir
messages using their static identity key at the application layer. This wou= ld
effectively destroy deniability, but it is up to the application to make th= at
decision.

Yes, that would probably work= .

I guess my point is that destroying deniability (and FS) at the application=
layer is easier then getting it if it is not built into the protocol in the=
first place.

Almost certainly; though t= his is an ever-increasing number of hoops to jump through. My concern is th= at baking in a very particular definition of "security" runs the = risk that it either outright prevents the use in some cases, or simply pric= es people out of the market in technical knowledge terms.

I am already going to end up writing much more cryptographic code t= han I'd like to use MLS. Writing more doesn't fill me with confiden= ce.
=C2=A0

Cheers,
Konrad

On 23.01.20 15:30, Dave Cridland wrote:
>
>
> On Thu, 23 Jan 2020 at 13:59, Cas Cremers <cas.cremers@gmail.com
> <mailto:= cas.cremers@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0We're aiming for security first, I think.
>
>
> If we mandate deniability and mandate PFS, then the risk is that the t= hreat
> model ends up less applicable.
>
> We can work around the PFS by (in effect) using MLS as a groupwise key= exchange
> protocol and exporting a longer term key for message encryption, but i= f we
> destroy cryptographic integrity post-facto, as I assume we mean by den= iability,
> then that makes life increasingly unpleasant for the cases where peopl= e actually
> want different properties.
>
> In short, preventing various groups making use of MLS is not security = first.
>
> Dave.
>
> _______________________________________________
> 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
--000000000000d738e3059cd06523-- From nobody Thu Jan 23 07:47:37 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 4ABEC120852 for ; Thu, 23 Jan 2020 07:47:35 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 5SJlU9SZPpCz for ; Thu, 23 Jan 2020 07:47:29 -0800 (PST) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) (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 8E63A120845 for ; Thu, 23 Jan 2020 07:47:27 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 483RVP5HVKzKmmJ; Thu, 23 Jan 2020 16:47:25 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id e5QferuEJKjF; Thu, 23 Jan 2020 16:47:22 +0100 (CET) Date: Thu, 23 Jan 2020 16:47:16 +0100 In-Reply-To: References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RLS4RAOYPOEYA7EJ2Z7P6OHP0023I0" Content-Transfer-Encoding: 7bit To: Dave Cridland CC: mls@ietf.org From: Konrad Kohbrok Message-ID: Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 15:47:35 -0000 ------RLS4RAOYPOEYA7EJ2Z7P6OHP0023I0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The record keeping doesn't have to be in the nurse's phone=2E You can simpl= y mandate that by default a recording service is added to every conversatio= n=2E That service can run on a well-secured server=2E Implementing or even deploying MLS is certainly not going to be a trivial = task=2E However, I would argue that running your own message encryption on = top of MLS (which I can't imagine why you would want that, see above) is mo= re hassle than simply signing messages on top of MLS=2E Konrad Am 23=2E Januar 2020 16:35:48 MEZ schrieb Dave Cridland : >On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok > >wrote: > >> Hi Dave, >> >> I'm not sure, I understand your use-case here=2E >> >> >I work for Pando, doing clinical messaging within the NHS in the UK, >and >elsewhere=2E Quite happy for the NHS to read doctors' and nurses' >messages >about patients, less happy for us to be exposed or for anyone who picks >up >a nurse's phone=2E > > >> Regarding FS: Any participant is free to just keep a log of the >> plaintexts, thus >> circumventing any FS guarantee=2E If you want to log the keys, any >party can >> do >> that as well=2E If I'm not mistaken could also simply opt not to use an >> RTreeKEM >> ciphersuite and never update the recording party's leaf key=2E >> >> >We can't, actually, but as I say we can export a stable key for message >encryption at each epoch so we're covered=2E > >(We cannot keep a log of the plaintexts since that would place >persistent >plaintext data on the user devices which would be problematic for us, >since >it's patient data)=2E > > >> Regarding deniability: Similarly, any member of a group can simply >sign >> their >> messages using their static identity key at the application layer=2E >This >> would >> effectively destroy deniability, but it is up to the application to >make >> that >> decision=2E >> > >Yes, that would probably work=2E > >I guess my point is that destroying deniability (and FS) at the >application >> layer is easier then getting it if it is not built into the protocol >in the >> first place=2E >> > >Almost certainly; though this is an ever-increasing number of hoops to >jump >through=2E My concern is that baking in a very particular definition of >"security" runs the risk that it either outright prevents the use in >some >cases, or simply prices people out of the market in technical knowledge >terms=2E > >I am already going to end up writing much more cryptographic code than >I'd >like to use MLS=2E Writing more doesn't fill me with confidence=2E > > >> >> Cheers, >> Konrad >> >> On 23=2E01=2E20 15:30, Dave Cridland wrote: >> > >> > >> > On Thu, 23 Jan 2020 at 13:59, Cas Cremers > > > wrote: >> > >> > We're aiming for security first, I think=2E >> > >> > >> > If we mandate deniability and mandate PFS, then the risk is that >the >> threat >> > model ends up less applicable=2E >> > >> > We can work around the PFS by (in effect) using MLS as a groupwise >key >> exchange >> > protocol and exporting a longer term key for message encryption, >but if >> we >> > destroy cryptographic integrity post-facto, as I assume we mean by >> deniability, >> > then that makes life increasingly unpleasant for the cases where >people >> actually >> > want different properties=2E >> > >> > In short, preventing various groups making use of MLS is not >security >> first=2E >> > >> > Dave=2E >> > >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf=2Eorg >> > https://www=2Eietf=2Eorg/mailman/listinfo/mls >> > >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/mls >> ------RLS4RAOYPOEYA7EJ2Z7P6OHP0023I0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The record keeping doesn't have to be in the nurse= 's phone=2E You can simply mandate that by default a recording service is a= dded to every conversation=2E That service can run on a well-secured server= =2E

Implementing or even deploying MLS is certainly not going to be = a trivial task=2E However, I would argue that running your own message encr= yption on top of MLS (which I can't imagine why you would want that, see ab= ove) is more hassle than simply signing messages on top of MLS=2E

Ko= nrad

Am 23=2E Januar 2020 16:35:48 MEZ sc= hrieb Dave Cridland <dave@cridland=2Enet>:


On Thu, 23 Jan 2020 at 14:55, Konrad= Kohbrok <konrad=2Ek= ohbrok@datashrine=2Ede> wrote:
Hi Dave,

I'm not sure, I understand your use-case here=2E


I work for Pando, doing clinical mess= aging within the NHS in the UK, and elsewhere=2E Quite happy for the NHS to= read doctors' and nurses' messages about patients, less happy for us to be= exposed or for anyone who picks up a nurse's phone=2E
 
Regarding FS: Any participant is free to just keep a log of the plaintexts= , thus
circumventing any FS guarantee=2E If you want to log the keys, any party c= an do
that as well=2E If I'm not mistaken could also simply opt not to use an RT= reeKEM
ciphersuite and never update the recording party's leaf key=2E


We can't, actually, but as I say we c= an export a stable key for message encryption at each epoch so we're covere= d=2E

(We cannot keep a log of the plaintexts since= that would place persistent plaintext data on the user devices which would= be problematic for us, since it's patient data)=2E
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"> Regarding deniability: Similarly, any member of a group can simply sign th= eir
messages using their static identity key at the application layer=2E This = would
effectively destroy deniability, but it is up to the application to make t= hat
decision=2E

Yes, that would probably w= ork=2E

I guess my point is that destroying deniability (and FS) at the applicatio= n
layer is easier then getting it if it is not built into the protocol in th= e
first place=2E

Almost certainly; thoug= h this is an ever-increasing number of hoops to jump through=2E My concern = is that baking in a very particular definition of "security" runs the risk = that it either outright prevents the use in some cases, or simply prices pe= ople out of the market in technical knowledge terms=2E

=
I am already going to end up writing much more cryptographic code than= I'd like to use MLS=2E Writing more doesn't fill me with confidence=2E
 

Cheers,
Konrad

On 23=2E01=2E20 15:30, Dave Cridland wrote:
>
>
> On Thu, 23 Jan 2020 at 13:59, Cas Cremers <cas=2Ecremers@gmail=2Ecom
> <mailto:cas=2Ecremers@gmail=2Ecom>> wrote:
>
>     We're aiming for security first, I think=2E
>
>
> If we mandate deniability and mandate PFS, then the risk is that the = threat
> model ends up less applicable=2E
>
> We can work around the PFS by (in effect) using MLS as a groupwise ke= y exchange
> protocol and exporting a longer term key for message encryption, but = if we
> destroy cryptographic integrity post-facto, as I assume we mean by de= niability,
> then that makes life increasingly unpleasant for the cases where peop= le actually
> want different properties=2E
>
> In short, preventing various groups making use of MLS is not security= first=2E
>
> Dave=2E
>
> _______________________________________________
> MLS mailing list
> MLS@ietf=2Eorg
> https://www=2Eietf=2Eorg/mailman/listinfo/mls=
>

_______________________________________________
MLS mailing list
MLS@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/mls
------RLS4RAOYPOEYA7EJ2Z7P6OHP0023I0-- From nobody Thu Jan 23 08:31:37 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 578181208DC for ; Thu, 23 Jan 2020 08:31:34 -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, HTML_MESSAGE=0.001, 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 vMCmq8vN4FK7 for ; Thu, 23 Jan 2020 08:31:32 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 DDE631208DB for ; Thu, 23 Jan 2020 08:31:31 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id w15so3814533wru.4 for ; Thu, 23 Jan 2020 08:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ntrIWDiTrLxgjJ+dSxRAK8jLN65VujpGIaUNIyv3/08=; b=I/ZMG2nb+fGhytuUi5J9FuvRDkoX3bUM2lqEi8zZDFr9w2w+pcUyTh7MvQu0Tc3PfI h+iq4tRmRGaQj/zK766AHanU1XpyUA2qYqEpIe4bfjw1lkxeiX5tlyWWejGcWS2XNkgA CzSicYxEvzJA6Ylk1Wo1whfiOhKYJTL3uyDqBIxdzI6+jfFJ4ULDjD5bODkRrnFSHBRY myqYm5qkutPYyKZLySSQGGSbr0YEComOdeqj5UT1iI/GpnRXmv1E8ujvS/k5Rnrr9BXa Tbwsi03GaP4z+R1mPWGnNLx7WG9mGJm5ItmnBUPc6Spnhxx3PRPpZXxO49XhvByHi1NY UVIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ntrIWDiTrLxgjJ+dSxRAK8jLN65VujpGIaUNIyv3/08=; b=GGcEZg7M6xEKkv6eYVnk06UBClm3G46+XznMFubJibjvJPMtUYUZ6cF/kQqRBQvh8Q X4kCi3QkqkTddX9A2WpYZYPCyjQqQ0mG4xvQsg7p/BVUZHIPLa/YD3v6mEdlhaIq8nKN hJLUmY2vyLvV+I55202EZ03afFi+q9+nh6ThDgBtQ7rvLQCLkjghsi5SyxcvGCPVQjsm vjdm3lrPWEXzMEDx5Q6g7EPjcMbIxelJRCHVlI0KDCLVUTHPIMLRg8gwdI1Ghd6Waw8V MoWOPLUUUt6619tapfp2a3Kq48aje7i7EcAh/zX77fmqnIxFBGxLfe6OEjx/ATZK4hHQ 8vSA== X-Gm-Message-State: APjAAAWtsEtIfcWB1Rz71wH95K4KJyjLywbVrDd0icZeW55f/0rfRZlI wszrExf5s7CHful3rzZ+o9ip7A== X-Google-Smtp-Source: APXvYqyh/8lgQgVry6maN0C/X9w6NbTP+5PAtgE9jn7HtbyDGpqAFQzFBkFkGVNc3FYarBVheTbniQ== X-Received: by 2002:adf:e5cf:: with SMTP id a15mr17919894wrn.140.1579797090198; Thu, 23 Jan 2020 08:31:30 -0800 (PST) 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 t8sm3727153wrp.69.2020.01.23.08.31.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 08:31:29 -0800 (PST) From: Raphael Robert Message-Id: <6B91E4EE-3768-40AF-A783-D6443BD7360C@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F21B58F-344E-491F-8D4D-5E94F9782B72" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 23 Jan 2020 17:31:28 +0100 In-Reply-To: Cc: Dave Cridland , mls@ietf.org To: Konrad Kohbrok References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 16:31:34 -0000 --Apple-Mail=_5F21B58F-344E-491F-8D4D-5E94F9782B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It seems there is some confusion around the properties. Deniability has = always been considered as an optional property, this is clearly stated = in the architecture document: "As described in {{client-compromise}}, MLS provides strong = authentication within a group, such that a group member cannot send a = message that appears to be from another group member. Additionally, some = services require that a recipient be able to prove to the messaging = service that a message was sent by a given client, in order to report = abuse. MLS supports both of these use cases. In some deployments, these = services are provided by mechanisms which allow the receiver to prove a = message's origin to a third party (this if often called = "non-repudiation"), but it should also be possible to operate MLS in a = "deniable" mode where such proof is not possible.=E2=80=9D This means that for use cases where deniability is not required or even = allowed (perhaps because of compliance rules in certain industries) = vendors can simply chose to not use the deniable mode of MLS. As Konrad mentioned, FS is not optional and at the core of MLS. For use = cases where FS is not desired for actual application messages and = instead you want a long term symmetric key, MLS can be used to = distribute this key securely among members. These use cases would = require a (rather thin) layer on top of MLS that handles symmetric = encryption/decryption. Raphael > On 23 Jan 2020, at 16:47, Konrad Kohbrok = wrote: >=20 > The record keeping doesn't have to be in the nurse's phone. You can = simply mandate that by default a recording service is added to every = conversation. That service can run on a well-secured server. >=20 > Implementing or even deploying MLS is certainly not going to be a = trivial task. However, I would argue that running your own message = encryption on top of MLS (which I can't imagine why you would want that, = see above) is more hassle than simply signing messages on top of MLS. >=20 > Konrad >=20 > Am 23. Januar 2020 16:35:48 MEZ schrieb Dave Cridland = : >=20 >=20 > On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok = > = wrote: > Hi Dave, >=20 > I'm not sure, I understand your use-case here. >=20 >=20 > I work for Pando, doing clinical messaging within the NHS in the UK, = and elsewhere. Quite happy for the NHS to read doctors' and nurses' = messages about patients, less happy for us to be exposed or for anyone = who picks up a nurse's phone. > =20 > Regarding FS: Any participant is free to just keep a log of the = plaintexts, thus > circumventing any FS guarantee. If you want to log the keys, any party = can do > that as well. If I'm not mistaken could also simply opt not to use an = RTreeKEM > ciphersuite and never update the recording party's leaf key. >=20 >=20 > We can't, actually, but as I say we can export a stable key for = message encryption at each epoch so we're covered. >=20 > (We cannot keep a log of the plaintexts since that would place = persistent plaintext data on the user devices which would be problematic = for us, since it's patient data). > =20 > Regarding deniability: Similarly, any member of a group can simply = sign their > messages using their static identity key at the application layer. = This would > effectively destroy deniability, but it is up to the application to = make that > decision. >=20 > Yes, that would probably work. >=20 > I guess my point is that destroying deniability (and FS) at the = application > layer is easier then getting it if it is not built into the protocol = in the > first place. >=20 > Almost certainly; though this is an ever-increasing number of hoops to = jump through. My concern is that baking in a very particular definition = of "security" runs the risk that it either outright prevents the use in = some cases, or simply prices people out of the market in technical = knowledge terms. >=20 > I am already going to end up writing much more cryptographic code than = I'd like to use MLS. Writing more doesn't fill me with confidence. > =20 >=20 > Cheers, > Konrad >=20 > On 23.01.20 15:30, Dave Cridland wrote: > >=20 > >=20 > > On Thu, 23 Jan 2020 at 13:59, Cas Cremers > > >> = wrote: > >=20 > > We're aiming for security first, I think. > >=20 > >=20 > > If we mandate deniability and mandate PFS, then the risk is that the = threat > > model ends up less applicable. > >=20 > > We can work around the PFS by (in effect) using MLS as a groupwise = key exchange > > protocol and exporting a longer term key for message encryption, but = if we > > destroy cryptographic integrity post-facto, as I assume we mean by = deniability, > > then that makes life increasingly unpleasant for the cases where = people actually > > want different properties. > >=20 > > In short, preventing various groups making use of MLS is not = security first. > >=20 > > Dave. > >=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 = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_5F21B58F-344E-491F-8D4D-5E94F9782B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = seems there is some confusion around the properties. Deniability has = always been considered as an optional property, this is clearly stated = in the architecture document:

"As described in {{client-compromise}}, MLS provides = strong authentication within a group, such that a group member = cannot send a message that appears to be from another group member. = Additionally, some services require that a recipient be able to = prove to the messaging service that a message was sent by a given = client, in order to report abuse. MLS supports both of these use = cases. In some deployments, these services are provided by = mechanisms which allow the receiver to prove a message's origin to = a third party (this if often called "non-repudiation"), but it = should also be possible to operate MLS in a "deniable" mode where = such proof is not possible.=E2=80=9D

This means that for use cases where = deniability is not required or even allowed (perhaps because of = compliance rules in certain industries) vendors can simply chose to not = use the deniable mode of MLS.

As Konrad mentioned, FS is not optional = and at the core of MLS. For use cases where FS is not desired for actual = application messages and instead you want a long term symmetric key, MLS = can be used to distribute this key securely among members. These use = cases would require a (rather thin) layer on top of MLS that handles = symmetric encryption/decryption.

Raphael

On 23 = Jan 2020, at 16:47, Konrad Kohbrok <Konrad.kohbrok@datashrine.de> wrote:

The = record keeping doesn't have to be in the nurse's phone. You can simply = mandate that by default a recording service is added to every = conversation. That service can run on a well-secured server.

Implementing or even deploying MLS is = certainly not going to be a trivial task. However, I would argue that = running your own message encryption on top of MLS (which I can't imagine = why you would want that, see above) is more hassle than simply signing = messages on top of MLS.

Konrad

Am 23. Januar 2020 = 16:35:48 MEZ schrieb Dave Cridland <dave@cridland.net>:


On Thu, 23 Jan 2020 at 14:55, Konrad = Kohbrok <konrad.kohbrok@datashrine.de> wrote:
Hi Dave,

I'm not sure, I understand your use-case here.


I work for Pando, doing clinical messaging within the NHS in = the UK, and elsewhere. Quite happy for the NHS to read doctors' and = nurses' messages about patients, less happy for us to be exposed or for = anyone who picks up a nurse's phone.
 
Regarding FS: Any participant is free to just keep a log of the = plaintexts, thus
circumventing any FS guarantee. If you want to log the keys, any party = can do
that as well. If I'm not mistaken could also simply opt not to use an = RTreeKEM
ciphersuite and never update the recording party's leaf key.


We can't, actually, but as I say we can export a stable key = for message encryption at each epoch so we're covered.

(We cannot keep a log of = the plaintexts since that would place persistent plaintext data on the = user devices which would be problematic for us, since it's patient = data).
 
Regarding deniability: Similarly, any member of a group can simply sign = their
messages using their static identity key at the application layer. This = would
effectively destroy deniability, but it is up to the application to make = that
decision.

Yes, that would probably = work.

I guess my point is that destroying deniability (and FS) at the = application
layer is easier then getting it if it is not built into the protocol in = the
first place.

Almost certainly; though this is an = ever-increasing number of hoops to jump through. My concern is that = baking in a very particular definition of "security" runs the risk that = it either outright prevents the use in some cases, or simply prices = people out of the market in technical knowledge terms.

I am already going to = end up writing much more cryptographic code than I'd like to use MLS. = Writing more doesn't fill me with confidence.
 

Cheers,
Konrad

On 23.01.20 15:30, Dave Cridland wrote:
>
>
> On Thu, 23 Jan 2020 at 13:59, Cas Cremers <cas.cremers@gmail.com
> <mailto:cas.cremers@gmail.com>> wrote:
>
>     We're aiming for security first, I think.
>
>
> If we mandate deniability and mandate PFS, then the risk is that = the threat
> model ends up less applicable.
>
> We can work around the PFS by (in effect) using MLS as a groupwise = key exchange
> protocol and exporting a longer term key for message encryption, = but if we
> destroy cryptographic integrity post-facto, as I assume we mean by = deniability,
> then that makes life increasingly unpleasant for the cases where = people actually
> want different properties.
>
> In short, preventing various groups making use of MLS is not = security first.
>
> Dave.
>
> _______________________________________________
> 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

= --Apple-Mail=_5F21B58F-344E-491F-8D4D-5E94F9782B72-- From nobody Thu Jan 23 08:51:01 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 F175F120121 for ; Thu, 23 Jan 2020 08:50:59 -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, HTML_MESSAGE=0.001, 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 i22Mz2uIn8Ev for ; Thu, 23 Jan 2020 08:50:57 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 A0D3D1200F7 for ; Thu, 23 Jan 2020 08:50:56 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id t23so3296097wmi.1 for ; Thu, 23 Jan 2020 08:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+pYnQM5SPakBXTVXfKTlAohixRn41yUQ9LVMZq0jZdM=; b=fYhCFhSFKrRaz0a5EwSvfbqFqtG7FsjYbXECmrjwXxRgLDWTgQHgZL7pzet5xdcnFT SQ1ro3xASpsIna9/BOuZ4Ut/d3w0/owE1AtBDrrfo9UKtowAQ1N59NOsfFh/s3hBAQqA VM98c50sULKaL/mYmySlyxcJsz2zFNQ9Zoos6Yysd6jbexU+hNm/7N0HEk+6PLdZJWfr 39B/x1WNNERdHFTyIvxVefb4cCMBD1zuiVwEHQdeMaoNo9KBfKpSL2KnaA2TsqhZqizB eLtB8BkMauQCTd4hBv8EM86nekzN/EL3oashrPFV9ZOutvAPjQn/6F7W4mLSSRh2avsN tKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+pYnQM5SPakBXTVXfKTlAohixRn41yUQ9LVMZq0jZdM=; b=S6ZY9lV+fvRroSqEzc7TeV+dnlsnWetDeBtU5+TJVtdWT/mquB3ASkshk8PlsnSE74 kk3xrHRBwJJuc21FKZGTVeAuUu/mhlJSPkZsypYkzjVpn9hGrHsvTO4FuSeSEUyLHLc3 vL9lZhFG3rZ5+1B4Pns7yRN+aSTTYO8dUhhow0dv8LDNo+/1cQgzkUmoLRDg30swPOKE FHNUxQargCGu4RGB4Vwqe1XZ2VKM6TmDai4yOtMbS4rfNfcRk+nwyn6u2XIymsMm/ZOX zQRNbbUjoOA341Ayh5TvWrlC1G8SowJY+4LyTlxgvg0qoq1Yo5ZSf50SDpU//7jDqYx3 yvEA== X-Gm-Message-State: APjAAAWxMCunKKuKX/fbVB1cWBywgU3rSVgQiGWQUVKt3z18dqCV43mP 9jj4MB1YtIVB6WFjaKSIABg0hw== X-Google-Smtp-Source: APXvYqwl4q3Rl2JNr3nAGICpAQhvB2FhvQSW95rNBjvya7iqz9ghv2v5ygW8uL9O3Hne5io6Z6BG6Q== X-Received: by 2002:a1c:3c89:: with SMTP id j131mr5195784wma.34.1579798255032; Thu, 23 Jan 2020 08:50:55 -0800 (PST) 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 a184sm3362954wmf.29.2020.01.23.08.50.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 08:50:53 -0800 (PST) From: Raphael Robert Message-Id: <3E30B070-68DB-4A56-A02C-E450B2033F54@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_79C168DD-2F86-4371-8732-39CB600631C1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 23 Jan 2020 17:50:53 +0100 In-Reply-To: <2061064987.251760.1579790003975@mail.yahoo.com> Cc: "jon@callas.org" , "mls@ietf.org" , Cas Cremers To: nalini.elkins@insidethestack.com References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> <2061064987.251760.1579790003975@mail.yahoo.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 16:51:00 -0000 --Apple-Mail=_79C168DD-2F86-4371-8732-39CB600631C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to rule out any misunderstanding: the deniable mode of MLS we are = exploring is optional (as per the architecture document). Furthermore deniability should not invalidate the properties stated in = the charter (in particular authentication). Deniable authentication = simply means that members fully authenticate to each other within the = group, but members cannot deliver a proof of this authentication to = third parties outside of the group. Depending on the flavour of = deniability this means that a member cannot prove to an outsider whether = a specific message was sent in the group (message deniability), or = whether a certain member was part of the group (membership deniability), = etc=E2=80=A6 I hope this clarifies things a bit. Raphael > On 23 Jan 2020, at 15:33, nalini.elkins@insidethestack.com wrote: >=20 >=20 >=20 > Cas, >=20 > On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers = > wrote: >=20 >=20 > >Hi, >=20 >=20 > >The "recording" / "non-deniable" properties you are suggesting are = not > >part of the desired properties described in the charter, so I think = it > >is best to first try to meet the intended MLS goals -- it's complex > >enough as it is. >=20 >=20 > Maybe we have a misunderstanding. =46rom the charter: >=20 >=20 > o Message Confidentiality - Messages can only be read by members of = the group >=20 > o Message Integrity and Authentication - Each message has been sent by = an authenticated sender, and has not been tampered with >=20 > o Membership Authentication - Each participant can verify the set of = members in the group >=20 >=20 > I just want to make sure that a group member cannot say after the fact = that they were not a member of the group. Let's leave the "recording" = participant out of the discussion. It is taken care of by complying = with the Authentication statement above. >=20 >=20 > Nalini >=20 >=20 > On 1/23/20 2:45 PM, nalini.elkins@insidethestack.com = wrote: > > All, > >=20 > >>> On 22 Jan 2020, at 20:59, Jon Callas >> wrote: > >>> > >>> > >>> > >>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert > > >> wrote: > >>>>> > >>>>> For general context: Deniability is something that is being > > discussed right now and we should send some update to the list as = soon > > as we have sorted things a bit better. > >>>>> > >>> > >>> Please do. I have some tart opinions about deniability, and don't > > want to waste anyone's time before we know what we're really talking = about. > >>> > >>> It's also probably best not to talk about things like courts and = so on. > >>> > >>> There are a number of reasons, starting with jurisdictional = issues. > > Inevitably, each of us will talk about legal issues through the lens = of > > our own native jurisdiction and that lens is cracked with our own > > misunderstandings of law and procedure, not to mention that these = things > > do change over time. A procedural stage setting of today may not be = the > > setting of a decade from now. > >>> > >>> Lots of protocols talk about "deniability" and it's often a weird > > concept that is a term of art and doesn't mean at all what a = reasonable > > person might think. I've had some discussions with people about the > > "deniability" of OTR and others, where it doesn't mean what any > > non-expert would think it does. > >>> > >>> There are other deniability issues that are peculiar.. A way that = I've > > characterized this issue is that deniability assumes that your = adversary > > is either stupid or good. By "stupid" I mean that they understand = what > > deniability is, and might not even look for it. (e.g. hidden volumes = in > > Truecrypt). By "good" I mean that you're going to give some = mathematical > > explanation and they'll accept it. If the adversary is smart and = evil, > > deniability can be a weakness, not a strength. > >>> > >>> Here's an example, again with Truecrypt hidden volumes. I once = talked > > to some customs officials in a country that's not mine, and I asked = them > > about hidden volumes. They said, "Oh, yeah, we know about hidden = volumes > > and if we see Truecrypt, we *assume* there's a hidden volume. Why = would > > anyone use Truecrypt and not have a hidden volume?" That might not = be > > precisely evil, but it shows a basic issue. True evil would be that > > after getting to the hidden volume, they ask you to open up the = hidden > > volume in the hidden volume. You reply that there's only one level = of > > hidden volume and they reply (knowing that you're right, but because > > they're evil), "That's your story. This is open source software. = Open up > > the other hidden volume." > >>> > >>> Another form of assumption as either smartness or evil is that if = you > > have a ring signature that could have been made by Alice, Bob, or > > Charlie, they just assume that Alice made it and let Alice know = that's > > they're working hypothesis since she's their suspect. (I don't want = to > > go too far down this rathole, but it might be the smart way to bet. > > Suppose the signature was made at 4am Pacific or 12pm GMT and Alice = is > > the only European in that set -- it's a reasonable hypothesis that = Alice > > made it.) > >>> > >>> Thus, when we talk about deniability, let's talk about the = specific > > security property and not an aspirational thing like "deniable" that > > might not work out the way we think. If the property is that a = signature > > could be made by any element of a set, that's a nice property, even = if > > there are externalities that can winnow that set down, even to a = single > > member. > >>> > >>> Jon > >>> > >=20 > >>I agree with the above. Ideally we would like to combine academic > > precision with common sense definitions and be clear about ?>the = threat > > model too. I also agree that we should leave aside legal = considerations > > for all the reasons you mentioned and focus on >the social aspect of = the > > facets of deniability. > >=20 > >>We=E2=80=99ll chew through the existing material to see what could = make sense > > in terms of properties and how we could achieve them in >practical > > terms. Obviously not all aspects of deniability are straight forward = in > > a group messaging protocol, all the more so since >MLS has strong > > authentication guarantees that 1:1 protocols might not have. > >=20 > > Without getting into any solutions, I just wanted to put forth some > > common sense requirements. I hope that I am understanding how > > deniability might work. Please correct me if I have any = misconceptions. > >=20 > > Companies doing financial transactions and wishing to use MLS might = have > > a hard time if there were some aspects of deniability. For example, = if > > you do a stock trade, it is required to be recorded. If the stock > > trading company cannot prove that it was indeed you that did the = trade, > > then it becomes quite problematic.=20 > >=20 > > Also, for example, if you are getting advice from a medical = professional > > and they wish to know that it is indeed you that they are talking = to.=20 > > This is important for privacy and other issues. One does not wish = to > > give health information to just anyone. > >=20 > > I believe I had stated in this group before that the "recording" = would > > be done by a completely transparent group member known to all = parties.=20 > > For example, when you call a business and you receive the message = "You > > are on a recorded line." There are quite a few use cases for such = a > > scenario in the business and medical worlds.=20 > >=20 > > I would support a common sense explanation of the various aspects of > > deniability along with what cryptographic schemes would do and not = do, > > if I am am making any sense! I would be happy to work in a team > > dedicated to this effort. > >=20 > > Thanks, > >=20 > > Nalini Elkins > > CEO and Founder > > Inside Products, Inc. > > www.insidethestack.com > > (831) 659-8360 >=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 = --Apple-Mail=_79C168DD-2F86-4371-8732-39CB600631C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = to rule out any misunderstanding: the deniable mode of MLS we are = exploring is optional (as per the architecture document).

Furthermore deniability = should not invalidate the properties stated in the charter (in = particular authentication). Deniable authentication simply means that = members fully authenticate to each other within the group, but members = cannot deliver a proof of this authentication to third parties outside = of the group. Depending on the flavour of deniability this means that a = member cannot prove to an outsider whether a specific message was sent = in the group (message deniability), or whether a certain member was part = of the group (membership deniability), etc=E2=80=A6

I hope this clarifies = things a bit.

Raphael

On 23 Jan 2020, at 15:33, nalini.elkins@insidethestack.com wrote:



Cas,

On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers = <cas.cremers@gmail.com> wrote:


>Hi,


>The "recording" / = "non-deniable" properties you are suggesting are not
>part of the desired properties described in the charter, = so I think it
>is best to first try to = meet the intended MLS goals -- it's complex
>enough as it is.


Maybe we have a = misunderstanding.  =46rom the charter:


o Message Confidentiality - Messages = can only be read by members of the = group

o Message Integrity and = Authentication - Each message has been sent by an = authenticated sender, and has not been tampered = with

o Membership = Authentication - Each participant can verify the = set of members in the group


I just want to make sure that a group member cannot say after = the fact that they were not a member of the group.   Let's = leave the "recording" participant out of the discussion.  It is = taken care of by complying with the Authentication statement = above.


Nalini


On 1/23/20 2:45 PM, nalini.elkins@insidethestack.com wrote:
> All,
> 
>>> On 22 Jan 2020, at 20:59, Jon Callas <jon@callas.org>> wrote:
>>>
>>>
>>>
>>>>> On Jan 22, 2020, at 7:54 = AM, Raphael Robert
> <raphael=3D40wire.com@dmarc.ietf.org>> = wrote:
>>>>>
>>>>> For general context: Deniability is = something that is being
> discussed = right now and we should send some update to the list as soon
> as we have sorted things a bit better.
>>>>>
>>>
>>> Please = do. I have some tart opinions about deniability, and don't
> want to waste anyone's time before we = know what we're really talking about.
>>>
>>> It's = also probably best not to talk about things like courts and so on.
>>>
>>> There are a number of reasons, starting with = jurisdictional issues.
> Inevitably, = each of us will talk about legal issues through the lens of
> our own native jurisdiction and that lens = is cracked with our own
> = misunderstandings of law and procedure, not to mention that these = things
> do change over time. A = procedural stage setting of today may not be the
> setting of a decade from now.
>>>
>>> Lots = of protocols talk about "deniability" and it's often a weird
> concept that is a term of art and doesn't = mean at all what a reasonable
> person = might think. I've had some discussions with people about the
> "deniability" of OTR and others, where it = doesn't mean what any
> non-expert would = think it does.
>>>
>>> There are other deniability issues that are = peculiar.. A way that I've
> = characterized this issue is that deniability assumes that your = adversary
> is either stupid or good. By = "stupid" I mean that they understand what
> deniability is, and might not even look for it. (e.g. = hidden volumes in
> Truecrypt). By = "good" I mean that you're going to give some mathematical
> explanation and they'll accept it. If the = adversary is smart and evil,
> = deniability can be a weakness, not a strength.
>>>
>>> Here's = an example, again with Truecrypt hidden volumes. I once talked
> to some customs officials in a country = that's not mine, and I asked them
> = about hidden volumes. They said, "Oh, yeah, we know about hidden = volumes
> and if we see Truecrypt, we = *assume* there's a hidden volume. Why would
> anyone use Truecrypt and not have a hidden volume?" That = might not be
> precisely evil, but it = shows a basic issue. True evil would be that
> after getting to the hidden volume, they ask you to open = up the hidden
> volume in the hidden = volume. You reply that there's only one level of
> hidden volume and they reply (knowing that you're right, = but because
> they're evil), "That's = your story. This is open source software. Open up
> the other hidden volume."
>>>
>>> = Another form of assumption as either smartness or evil is that if you
> have a ring signature that could have = been made by Alice, Bob, or
> Charlie, = they just assume that Alice made it and let Alice know that's
> they're working hypothesis since she's = their suspect. (I don't want to
> go too = far down this rathole, but it might be the smart way to bet.
> Suppose the signature was made at 4am = Pacific or 12pm GMT and Alice is
> the = only European in that set -- it's a reasonable hypothesis that Alice
> made it.)
>>>
>>> Thus, = when we talk about deniability, let's talk about the specific
> security property and not an aspirational = thing like "deniable" that
> might not = work out the way we think. If the property is that a signature
> could be made by any element of a set, = that's a nice property, even if
> there = are externalities that can winnow that set down, even to a single
> member.
>>>
>>>  =      Jon
>>>
> 
>>I agree with the above. Ideally we would like to = combine academic
> precision with common = sense definitions and be clear about ?>the threat
> model too. I also agree that we should leave aside legal = considerations
> for all the reasons you = mentioned and focus on >the social aspect of the
> facets of deniability.
> 
>>We=E2=80=99ll chew through the = existing material to see what could make sense
> in terms of properties and how we could achieve them in = >practical
> terms. Obviously not all = aspects of deniability are straight forward in
> a group messaging protocol, all the more so since = >MLS has strong
> authentication = guarantees that 1:1 protocols might not have.
> 
> Without getting into any solutions, I = just wanted to put forth some
> common = sense requirements.  I hope that I am understanding  how
> deniability might work.  =  Please correct me if I have any misconceptions.
> 
> Companies doing financial transactions = and wishing to use MLS might have
> a = hard time if there were some aspects of deniability.  For example, = if
> you do a stock trade, it is = required to be recorded.  If the stock
> trading company cannot prove that it was indeed you that = did the trade,
> then it becomes quite = problematic. 
> 
> Also, for example, if you are getting advice from a = medical professional
> and they wish to = know that it is indeed you that they are talking to. 
> This is important for privacy and other = issues.  One does not wish to
> = give health information to just anyone.
> 
> I believe I had stated in this group = before that the "recording" would
> be = done by a completely transparent group member known to all = parties. 
> For example, when you = call a business and you receive the message "You
> are on a recorded line."   There are quite a = few use cases for such a
> scenario in = the business and medical worlds. 
> 
> I would support a common sense = explanation of the various aspects of
> = deniability along with what cryptographic schemes would do and not = do,
> if I am am making any sense!  =  I would be happy to work in a team
>= dedicated to this effort.
> 
> Thanks,
> 
> Nalini Elkins
> CEO and = Founder
> Inside Products, Inc.
> www.insidethestack.com
> = (831) 659-8360

> 
> _______________________________________________
> 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
=

= --Apple-Mail=_79C168DD-2F86-4371-8732-39CB600631C1-- From nobody Thu Jan 23 09:20:01 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 013C312084C for ; Thu, 23 Jan 2020 09:19:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=yahoo.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 51K64EbDzt7n for ; Thu, 23 Jan 2020 09:19:55 -0800 (PST) Received: from sonic305-27.consmr.mail.ne1.yahoo.com (sonic305-27.consmr.mail.ne1.yahoo.com [66.163.185.153]) (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 B38A1120145 for ; Thu, 23 Jan 2020 09:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579799993; bh=r9Xwp8oijNnDDmeW8L3jDzbVgdPzXJBEkymhzp3HLLA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=AqGtD0asmsdpuTdmCKmieLUbBo01LWCw+b3GkywArQXJPhDFuzcUgsgaT77yrtbeCOo+dtWGg6EgpdLqFk7MgX+A6UkSm5I/eUt28wTwqS0EnpfU/jjNPl392vXS55dowTxTT5Y1FopRSjdWfqfaFrdDXpEUzoFS30k5M47nBIqp7liDmUMxcv1VCZLkZoP4NIFSY/F9Q/QGfqlLldFdQroOEngv9TrLFUbZlckBVgJVcU8vM8vEXE1OuVNKbDiJOiYHiI6ss+Em0jQ6tVenc3OQR5jLi3Mh6+EBMPr0k9VWcxlfRb+T2egX30IjNlgO61NX0Wo4RYF1pfOhB/NTfQ== X-YMail-OSG: IRW_.rcVM1k3v3HJBvpXlYGFN2ck.7oiCF8zDtdwmQ.lD9jY_rxj46BkrWEEPZL lN8ynOsSiyDkUyhDRqRHLmZxO9tVPW7VAAMx2Hpo4TP77EUnlVtmp99XXX35kdhC4aWjWIO7sUSB 1ewxkdhqQ2RbNYzLV9ZDbeiYVCBnaQM_TArMrB5AxK6CzI6lIoCyu8UZFxQAYuYDaQ7fGrFX0w7n JFK3JG0WEBS9ZS3xRrc8uttQJP7qVc7Ss1iaSgRKom.HqSJsrrRVJAaCZilwPM3nMMcmMcpodMh. 28ko7lLLlSKIrRtNxPcHbgIS3i0Y2getEJ7r7piun2lUs9m0GSvS8n8BjTETjs1IvyoprUpk6M5y 1AT4okWn420vbI8Yj8_fGt6gRyUxnqiVSE3qlgvZTXAyBhjzLcNI7Vy.VDf9kMyRQGVExGyl4IG1 JgacM.BmnwDKnBWRzLLdVoVYsN.e91.APJ3fbFQn4M.TJmtT6viIVhwae9Ob4j9pQmwNdNu2Zozc oiN1s5Oyozhy8_Id3ZlIuOzLApYspDAeqcwFwWrdpEKLuYvpVD9IEhcA7mM9HCX8y26rtY7cnWfU PwRsdOBjF_LhqXypvNbuA7GrfytPX_oqYC703G_FeoricaFRdbrfbw0K4kwf3wVqx0sRFofseMRE LS3f7xfS7TioGHQHpatdsHWXmrCCRu5N5M2wB4Oq35aDVRAphdg6_mv5JAAIIUsxJyrtj3o2XRa4 6yZYSDnrpdNKWPrc5xEoNqwaqD3iQAwj.A2dwge.UlpMbsudRbzzXgUuodIKv4p_uNY4Kx1Mx8wK eesfzbEKNH6i4sBNomjOTHtS2PaZ8bcgmYYF4KyHRBQasS0_7378elzP7uz4gpNAmP.wx.eg3dTG iIVL35iEw9JO8xcKpf6m.WrSSW2u8XS_C.JoG1Z9TZLgqRQMGs_mhkCl7DsslpAY7UmUNVE84KA5 3DpCnWYPPRErlcMNjmy9eHDAEDxbB__ekaT2.IJvqaguVjZFi3frhkvJkoEnOirJgiPmk2.f3SsW Ov7xkHnzvDwcCRo7uzRIAcnaQZcXhH5fgS0ewE.hvTAJbHSgVLpPBIxO4lwDDePxt6celp38YfsG quYh_CeqXXcColzCPFUbsZH9Wda4Qf5So8UP3gRHlZ.RW.F6p7gp8o6C2tfKRhQ55sPuLfgqtNco sQFVMqWA6ODQwmX16j0XQBqcUpLDhL96ozm1.ePSrnUj9Wjg3NMa_DNiXKyYm2v30y8aLkq563Mu dL3SbdfL_8ZGustM0zGLNwHrJDqDWZ3GDzqnHV46Kq9J_oS.rB4Y88trVMLPs42a7xDayz43T6Ze O_GszAnazegUr.bAK4hQRd1JhvVLqFq_oINndnaGo3NvfVPQgPsjl9H_lsaJl4mm5oWpc4Mm1eL_ UGv3DOn48R7VcUVgAktb_Y8ZctVUu_h3Br5ODLrl8OPYQYXmFOTwh29Cqr.4cIXCEeMtoV9zYEQ- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 17:19:53 +0000 Date: Thu, 23 Jan 2020 17:19:43 +0000 (UTC) From: Nalini J Elkins To: Raphael Robert , Cc: "mls@ietf.org" , Cas Cremers , "jon@callas.org" Message-ID: <903411086.321286.1579799983593@mail.yahoo.com> In-Reply-To: <3E30B070-68DB-4A56-A02C-E450B2033F54@wire.com> References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> <2061064987.251760.1579790003975@mail.yahoo.com> <3E30B070-68DB-4A56-A02C-E450B2033F54@wire.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_321285_1946005536.1579799983590" X-Mailer: WebService/1.1.14873 YahooMailIosMobile Yahoo%20Mail/48275 CFNetwork/1121.2.2 Darwin/19.2.0 Archived-At: Subject: Re: [MLS] Deniability -> "recording"? 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, 23 Jan 2020 17:19:59 -0000 ------=_Part_321285_1946005536.1579799983590 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Raphael, Sorry for the top post. =C2=A0On my phone. Great! thanks for the clarification. Nalini=C2=A0 Sent from Yahoo Mail for iPhone On Thursday, January 23, 2020, 11:50 AM, Raphael Robert wrote: Just to rule out any misunderstanding: the deniable mode of MLS we are expl= oring is optional (as per the architecture document). Furthermore deniability should not invalidate the properties stated in the = charter (in particular authentication). Deniable authentication simply mean= s that members fully authenticate to each other within the group, but membe= rs cannot deliver a proof of this authentication to third parties outside o= f the group. Depending on the flavour of deniability this means that a memb= er cannot prove to an outsider whether a specific message was sent in the g= roup (message deniability), or whether a certain member was part of the gro= up (membership deniability), etc=E2=80=A6 I hope this clarifies things a bit. Raphael On 23 Jan 2020, at 15:33, nalini.elkins@insidethestack.com wrote: Cas, On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers wrote: >Hi, >The "recording" / "non-deniable" properties you are suggesting are not >part of the desired properties described in the charter, so I think it >is best to first try to meet the intended MLS goals -- it's complex >enough as it is. Maybe we have a misunderstanding.=C2=A0 From the charter: o Message Confidentiality - Messages can only be read=C2=A0by members of th= e group o Message Integrity and Authentication - Each message=C2=A0has been sent by= an authenticated sender, and has=C2=A0not been tampered with o Membership Authentication - Each participant can verify=C2=A0the set of m= embers in the group I just want to make sure that a group member cannot say after the fact that= they were not a member of the group.=C2=A0 =C2=A0Let's leave the "recordin= g" participant out of the discussion.=C2=A0 It is taken care of by complyin= g with the Authentication statement above. Nalini On 1/23/20 2:45 PM,=C2=A0nalini.elkins@insidethestack.com=C2=A0wrote: > All, >=C2=A0 >>> On 22 Jan 2020, at 20:59, Jon Callas > wrote: >>> >>> >>> >>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert > > wrote: >>>>> >>>>> For general context: Deniability is something that is being > discussed right now and we should send some update to the list as soon > as we have sorted things a bit better. >>>>> >>> >>> Please do. I have some tart opinions about deniability, and don't > want to waste anyone's time before we know what we're really talking abou= t. >>> >>> It's also probably best not to talk about things like courts and so on. >>> >>> There are a number of reasons, starting with jurisdictional issues. > Inevitably, each of us will talk about legal issues through the lens of > our own native jurisdiction and that lens is cracked with our own > misunderstandings of law and procedure, not to mention that these things > do change over time. A procedural stage setting of today may not be the > setting of a decade from now. >>> >>> Lots of protocols talk about "deniability" and it's often a weird > concept that is a term of art and doesn't mean at all what a reasonable > person might think. I've had some discussions with people about the > "deniability" of OTR and others, where it doesn't mean what any > non-expert would think it does. >>> >>> There are other deniability issues that are peculiar.. A way that I've > characterized this issue is that deniability assumes that your adversary > is either stupid or good. By "stupid" I mean that they understand what > deniability is, and might not even look for it. (e.g. hidden volumes in > Truecrypt). By "good" I mean that you're going to give some mathematical > explanation and they'll accept it. If the adversary is smart and evil, > deniability can be a weakness, not a strength. >>> >>> Here's an example, again with Truecrypt hidden volumes. I once talked > to some customs officials in a country that's not mine, and I asked them > about hidden volumes. They said, "Oh, yeah, we know about hidden volumes > and if we see Truecrypt, we *assume* there's a hidden volume. Why would > anyone use Truecrypt and not have a hidden volume?" That might not be > precisely evil, but it shows a basic issue. True evil would be that > after getting to the hidden volume, they ask you to open up the hidden > volume in the hidden volume. You reply that there's only one level of > hidden volume and they reply (knowing that you're right, but because > they're evil), "That's your story. This is open source software. Open up > the other hidden volume." >>> >>> Another form of assumption as either smartness or evil is that if you > have a ring signature that could have been made by Alice, Bob, or > Charlie, they just assume that Alice made it and let Alice know that's > they're working hypothesis since she's their suspect. (I don't want to > go too far down this rathole, but it might be the smart way to bet. > Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is > the only European in that set -- it's a reasonable hypothesis that Alice > made it.) >>> >>> Thus, when we talk about deniability, let's talk about the specific > security property and not an aspirational thing like "deniable" that > might not work out the way we think. If the property is that a signature > could be made by any element of a set, that's a nice property, even if > there are externalities that can winnow that set down, even to a single > member. >>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Jon >>> >=C2=A0 >>I agree with the above. Ideally we would like to combine academic > precision with common sense definitions and be clear about ?>the threat > model too. I also agree that we should leave aside legal considerations > for all the reasons you mentioned and focus on >the social aspect of the > facets of deniability. >=C2=A0 >>We=E2=80=99ll chew through the existing material to see what could make s= ense > in terms of properties and how we could achieve them in >practical > terms. Obviously not all aspects of deniability are straight forward in > a group messaging protocol, all the more so since >MLS has strong > authentication guarantees that 1:1 protocols might not have. >=C2=A0 > Without getting into any solutions, I just wanted to put forth some > common sense requirements.=C2=A0 I hope that I am understanding=C2=A0 how > deniability might work.=C2=A0 =C2=A0Please correct me if I have any misco= nceptions. >=C2=A0 > Companies doing financial transactions and wishing to use MLS might have > a hard time if there were some aspects of deniability.=C2=A0 For example,= if > you do a stock trade, it is required to be recorded.=C2=A0 If the stock > trading company cannot prove that it was indeed you that did the trade, > then it becomes quite problematic.=C2=A0 >=C2=A0 > Also, for example, if you are getting advice from a medical professional > and they wish to know that it is indeed you that they are talking to.=C2= =A0 > This is important for privacy and other issues.=C2=A0 One does not wish t= o > give health information to just anyone. >=C2=A0 > I believe I had stated in this group before that the "recording" would > be done by a completely transparent group member known to all parties.=C2= =A0 > For example, when you call a business and you receive the message "You > are on a recorded line."=C2=A0 =C2=A0There are quite a few use cases for = such a > scenario in the business and medical worlds.=C2=A0 >=C2=A0 > I would support a common sense explanation of the various aspects of > deniability along with what cryptographic schemes would do and not do, > if I am am making any sense!=C2=A0 =C2=A0I would be happy to work in a te= am > dedicated to this effort. >=C2=A0 > Thanks, >=C2=A0 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=C2=A0 > _______________________________________________ > MLS mailing list >=C2=A0MLS@ietf.org >=C2=A0https://www.ietf.org/mailman/listinfo/mls >=C2=A0 _______________________________________________ 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 ------=_Part_321285_1946005536.1579799983590 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Raphael,

Sorry for the top post.  On my phone.
<= div>
Great!

thanks for the clarifica= tion.

Nalini 


Sent from Yahoo Mail for iPhone
=

On Thursday, January 23, 2020, 11:50 A= M, Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:

Just to rule out= any misunderstanding: the deniable mode of MLS we are exploring is optiona= l (as per the architecture document).

Furthe= rmore deniability should not invalidate the properties stated in the charte= r (in particular authentication). Deniable authentication simply means that= members fully authenticate to each other within the group, but members can= not deliver a proof of this authentication to third parties outside of the = group. Depending on the flavour of deniability this means that a member can= not prove to an outsider whether a specific message was sent in the group (= message deniability), or whether a certain member was part of the group (me= mbership deniability), etc=E2=80=A6

I = hope this clarifies things a bit.

Raph= ael

On 23 Jan 2020, at 15:33, na= lini.elkins@insidethestack.com wrote:



Cas,

On Thursday, January 23, 2020, 05:59:49 AM PST, = Cas Cremers <cas.cremers@gmail.com> wrote:


>Hi,

>The "recording" / "= non-deniable" properties you are suggesting are not
>part of the desired properties described in the char= ter, so I think it
>is best to= first try to meet the intended MLS goals -- it's complex
>enough as it is.


=
Maybe we have a misunderstan= ding.  From the charter:


o Message Confidentiality -= Messages can only be read by members of the group

o Message Integrity and Authentication - Each message <= span class=3D"yiv4791309707" style=3D"color:rgb(34, 34, 34);">has been sent= by an authenticated sender, and has not been tampered with

o Membership Authentication - Each participant can verify&n= bsp;t= he set of members in the group


I just = want to make sure that a group member cannot say after the fact that they w= ere not a member of the group.   Let's leave the "recording" part= icipant out of the discussion.  It is taken care of by complying with = the Authentication statement above.

Nalini


On 1/23/20 2:45 PM, nali= ni.elkins@insidethestack.com wrote:
> = All,
> 
>>> On 22 Jan 2020, at 20:59, Jon Callas <jon@callas.org>= ;> wrote:
>>>
>>>
>>>
>&= gt;>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert
> <raphael=3D40wire.com@dmar= c.ietf.org>> wrote:
>= ;>>>>
>>>>= ;> For general context: Deniability is something that is being
> discussed right now and we should se= nd some update to the list as soon
> as we have sorted things a bit better.
>>>>>
>>>
>>> Please= do. I have some tart opinions about deniability, and don't
> want to waste anyone's time before we know = what we're really talking about.
= >>>
>>> It's al= so probably best not to talk about things like courts and so on.
>>>
>>> There are a number of reasons, starting with jur= isdictional issues.
> Inevitab= ly, each of us will talk about legal issues through the lens of
> our own native jurisdiction and that le= ns is cracked with our own
> m= isunderstandings of law and procedure, not to mention that these things
> do change over time. A procedur= al stage setting of today may not be the
> setting of a decade from now.
>>>
>>&g= t; Lots of protocols talk about "deniability" and it's often a weird
> concept that is a term of art and = doesn't mean at all what a reasonable
> person might think. I've had some discussions with people about t= he
> "deniability" of OTR and = others, where it doesn't mean what any
> non-expert would think it does.
>>>
>>&g= t; There are other deniability issues that are peculiar.. A way that I've> characterized this issue is t= hat deniability assumes that your adversary
> is either stupid or good. By "stupid" I mean that they unde= rstand what
> deniability is, = and might not even look for it. (e.g. hidden volumes in
> Truecrypt). By "good" I mean that you're going = to give some mathematical
> ex= planation and they'll accept it. If the adversary is smart and evil,
> deniability can be a weakness, not= a strength.
>>>
>>> Here's an example, again wi= th Truecrypt hidden volumes. I once talked
> to some customs officials in a country that's not mine, and = I asked them
> about hidden vo= lumes. They said, "Oh, yeah, we know about hidden volumes
> and if we see Truecrypt, we *assume* there's = a hidden volume. Why would
> a= nyone use Truecrypt and not have a hidden volume?" That might not be
> precisely evil, but it shows a bas= ic issue. True evil would be that
> after getting to the hidden volume, they ask you to open up the hidde= n
> volume in the hidden volum= e. You reply that there's only one level of
> hidden volume and they reply (knowing that you're right, bu= t because
> they're evil), "Th= at's your story. This is open source software. Open up
> the other hidden volume."
>>>
= >>> Another form of assumption as either smartness or evil is that= if you
> have a ring signatur= e that could have been made by Alice, Bob, or
> Charlie, they just assume that Alice made it and let Alic= e know that's
> they're workin= g hypothesis since she's their suspect. (I don't want to
> go too far down this rathole, but it might be = the smart way to bet.
> Suppos= e the signature was made at 4am Pacific or 12pm GMT and Alice is
> the only European in that set -- it'= s a reasonable hypothesis that Alice
> made it.)
>>>>>> Thus, when we talk ab= out deniability, let's talk about the specific
> security property and not an aspirational thing like "de= niable" that
> might not work = out the way we think. If the property is that a signature
> could be made by any element of a set, that's= a nice property, even if
> th= ere are externalities that can winnow that set down, even to a single
> member.
>>>
&= gt;>>       Jon
>>>
> 
>>I agree with the above. Ideally we would l= ike to combine academic
> prec= ision with common sense definitions and be clear about ?>the threat
> model too. I also agree that we = should leave aside legal considerations
> for all the reasons you mentioned and focus on >the social a= spect of the
> facets of denia= bility.
> 
>>We=E2=80=99ll chew through the existing material to see = what could make sense
> in ter= ms of properties and how we could achieve them in >practical
> terms. Obviously not all aspects of den= iability are straight forward in
= > a group messaging protocol, all the more so since >MLS has strong> authentication guarantees tha= t 1:1 protocols might not have.
&= gt; 
> Without getting into any solutions,= I just wanted to put forth some
= > common sense requirements.  I hope that I am understanding  = how
> deniability might work.&= nbsp;  Please correct me if I have any misconceptions.
> 
> Compani= es doing financial transactions and wishing to use MLS might have
> a hard time if there were some aspec= ts of deniability.  For example, if
> you do a stock trade, it is required to be recorded.  If = the stock
> trading company ca= nnot prove that it was indeed you that did the trade,
> then it becomes quite problematic. 
> 
> = Also, for example, if you are getting advice from a medical professional> and they wish to know that it = is indeed you that they are talking to. 
> This is important for privacy and other issues.  One= does not wish to
> give healt= h information to just anyone.
>= ; 
> I believe I had stated in this group= before that the "recording" would
> be done by a completely transparent group member known to all partie= s. 
> For example, when y= ou call a business and you receive the message "You
> are on a recorded line."   There are quit= e a few use cases for such a
>= scenario in the business and medical worlds. 
>&= nbsp;
> I would support= a common sense explanation of the various aspects of
> deniability along with what cryptographic schemes= would do and not do,
> if I a= m am making any sense!   I would be happy to work in a team
> dedicated to this effort.
> 
>= Thanks,
> 
> Nalini Elkins
&g= t; CEO and Founder
> Inside Pr= oducts, Inc.
> www.insidethestack.com
> (831) 659-8360

> <= /span>
> _____________________= __________________________
> M= LS mailing list
> MLS@ietf.org
> http= s://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
------=_Part_321285_1946005536.1579799983590-- From nobody Thu Jan 23 17:42: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 A9AC71200CD for ; Thu, 23 Jan 2020 17:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=riseup.net 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 mF5W67l_IXFU for ; Thu, 23 Jan 2020 17:42:31 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34C7120019 for ; Thu, 23 Jan 2020 17:42:30 -0800 (PST) Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 483hj24HcgzDrq7 for ; Thu, 23 Jan 2020 17:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1579830150; bh=RLO56fI4AQ5b+4zAvxv+qKnYsYpcAowyvILYEMIVVYk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=IqIGZUcgR77eTxHeph5McLXz9fGs5Hx41Nzqqqn1bnAub1DVVvZAAXLF8kWuU89nD nn6CoeGkz7GlOhnFswDByJog3iYAqHUPHK3ExfdIK0KKOCvAH18i4QP0tcXawJ3LY7 we89U2pZUBDpY5MmeWDW1tiXZqoALADBTtqQD9/A= X-Riseup-User-ID: 342C9800FAFCEA45100FAA79559876A137BCD12D5B1348C6DF4D6C3775D8B419 Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 483hj15qHyzJr1R for ; Thu, 23 Jan 2020 17:42:29 -0800 (PST) To: mls@ietf.org References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> From: =?UTF-8?Q?Sof=c3=ada_Celi?= Autocrypt: addr=cherenkov@riseup.net; keydata= mQINBF2PpxoBEADAIhbOpA23OBsXzg/aQakv88vaLv8Dxt2oR92Rz9cfxca736HKDeO19IFC F1Anu6ylQsJfoT4UUgbGIjJpHtQB3OVIcgvsMagfZ0lEHd1eG8H8K9wqSjwSphUJl9ra+tMW MEbSDVmeV6qvHeO63vrazXrgUKBf0jDae0HcK++AYiSeSpbTmN+zTsY3ZXy9H1sdNhMUlkGt jcpROrna2NaSL3YG8YNJHsN+zGPoaBbPo9gQALUvuxtg0yS/ecly2xomWIeH6qJ4yJonO/Ys WqAAC96n423BeC1cAyYjij8ydygnR3csTibUI/iPkoH8xstnTyrv3djyiunVuw1BQUNqmtLV v7meRZfIFbfnNatuuPYp7S5NnL58vUwY/BwlMb5OhyzdCckRcITAXiz8sp4LANx1lxIdbaQA 9NsYv32vem9Pd0wtdN5JTW3dajgJtPAC1yfR86rw9u/+BSW9KhRqNF0/a+hX/+Njdni9fkl9 EheZiFHNO+nXeGLy0kikhUXr5iLg8626fG9I8QYuNj05WIEntegvAW65YjGTYSCdVgLx2bvv oGwC/4/jWxNm8MTzv38f/9YAZ5u5DSG3dFKYAjwOhf1IgEMTEWj+bKDFvgpv5fdTFumLxNey M/v3viwuNjS1hscRbi6IO36v4sFce4K1C5GU93YIgao2j01M8QARAQABtB1yaXNldXAgPGNo ZXJlbmtvdkByaXNldXAubmV0PokCVAQTAQgAPhYhBPq5Ptx83RGY3P1FWJG7a0VvRC0CBQJd j6caAhsDBQkHhh+ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJG7a0VvRC0CEV0P/2UN rjx8LYmz/ydk2XO/uNWyobCtj/y9XBhZG9dpB8R43VC8OS5gv4Nw2ZLDrrpLQmaQ2dXjAeLL +9eCM++QT//VP2j2QS3YKbIcRreXSnl7DI6bMpD+Pu3JwiYHSyBs1zZT+VGm4nTS6QH588XJ VrslKyDYJFfzaHgkIGtxAWgqaHWAZHtjqh6PNEWMe2t571YYcVlk29cWsJ5ITsSPb+0Y0xJn u5HKQOc4TOdraedpLSFb5CZRlusNgWvhqmL4VyIcfjSEY0B8JVOgVpUeNTy0sZcDflYJ6uSN 9B1m79kb8STnVOtFS9gjnWbVwjAunqkkb/joRZhYfjeANVyYC4skh0uqJLFtqJw4r8s9+MrE p4lBy30lQ7mYYyqvRcwyEgoRRLHUvzV6cIHau/HV1pw0lwcbiXk3jP+TMf6OKOzg6lGJ/zX0 ZD+s0OAvHh8GM+5TDlgEM4Dwp6Q+9Jr1m9sp1QDQVbU7xrXXndXDd8RLEkiMDLovyyDtN6Jn HsW9PVMtu6sXvmbn0AHeHzHU/+bwB1LF4sx8O82tWKCgZlm270p+Bk6mjYmrlO4eQ11/AOF6 3ZlVoeXSaM4X0yoKa3ltdWaRoy9L0a4p7JuQYhBYIzjARbVjp9CmxctuQqW2qNSCJfagsUl8 mpcrs7xdhzfhzZHf8kQYWQcPYPPWLWqIuQINBF2PpxoBEACow9T4wPaQvKNG2LBnXeuLkDxf VGrZ/fDk0yfhG0174SjWXvDMIAgdNmfn2F4CM4F2FfPI32NZT34Td89fyWEWvP5/2I9HywyI QI/ubQvbqvm0l+DyzsdZNj4MBmNLy34Rg3K8uScgG7YbakzUplalbQKuzHrSW5OL5aBeKOG2 NGKJK7VZ4MzbdxhCLnXYvQwgnSkJ6B3AoBGv0LsLYzGUixzlMbNmYEhlQcK2scqprmFoX9rQ ymStV8b4Z37gkVmYeWGG2D9zl8gLj0u5Xw/KlF45JNxtMFBSL+Px7E1c+GJTWJxIENBhxRAu fxvbvduyJdXTObI51bqgV57510RjoLdzvVVqUpevmIdaMnavyUnDZOb8sBg3JG6NozZVzlXf S3FAvvK82zRShpd06ZNUbxPtNkruH/dT+6QV8gW3jX15gKGp2CtvhxLbi8ysV6zwtqxPkba2 03J0RAq2lVzxE/CSAP2qGPttElzHOPqhdmL6XjdmTw/WpF+qT8acB6Te8HZF+DriR/xG6EA1 MSdIK0vX4r5+U5bd0r7sh1ysSaYk/RI8hqxZZ4VGdPbVhFCOdT8AVcEXRoLsv+oN4x5WYJ9g 8G8Xw9+DvCNjFLxaGcL0ATHc8u8TyeegGRF3ZQNsRCqfVOLEYclYX+DqIly4ebCawAoIeWg2 GvN9cJAnFwARAQABiQI8BBgBCAAmFiEE+rk+3HzdEZjc/UVYkbtrRW9ELQIFAl2PpxoCGwwF CQeGH4AACgkQkbtrRW9ELQJX3g/8DAxtZTUJAlbKkluY30zITfcUwH4h9Rppxx/RvibZ1R4k 960OlvwyoRZ5rv2XiQA5VxOaVlh1tJErZnAyqgYwHr5CGQBjPEgkmRWBzme4W62uvCXOahxJ 4lNpr0TrVGRNOu223zYQcaN5S4Q5H2U9XNUFx8UF5leZIL6/Z6/bSGEW27vSuCxY6v8MkhQC 6l8T5RJqDsJmhwcVg9KDm8eGLkiu+kXS8iKl/Bw4o9257BI8hswBVRhN8kpHsecP2MGzKwn9 ccXWnOfM75qiq566UI26MY5priaGz5i+eCo26Rc0edm0IXxNs6rUZKVQUoxfMb/A/buJknYZ lUYXAgG2eDHEjlXvqNxQWHgfhIGqKFXDWuMt0sKP7Ta/lvGVPx9IHCTvkRZn9mtIN2/F9Lt5 sK3kezAlFw3BK6AIbD2v+g8TZnvKWSBidJHyhh7OEmKg3gXA3DxBpb7TU6iVUfG5e10RJUvQ qQNTSxv6mxJOgE3mEXizzj+tC6aEG/BzBwDsQpKquzUIKGCF2EGX9C7CZBhlsng/zmL3TFH6 EnY1tqV/lEg2/+gCLy/OE2dlE+EDZEtAiV183lzZNBs5Bg9NIz0Gq6a4ZkA8zDOFuxL2BFH2 EqrT33ladX2AIyKPMF50IwY4TMxGRlKhAjb4++pb55vBwVBLaTC09mvA+CuupPU= Message-ID: <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net> Date: Thu, 23 Jan 2020 20:42:28 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 24 Jan 2020 01:42:34 -0000 Hello! Very interesting insight! > What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place. The "sign & reveal" mechanism is something that can be considered coming from OTR, because in it you reveal the MAC keys. But the idea, since the first paper of OTR[1] was to use the revelation of keys as an additional measure to expand the set of possible message forgers. Message unlinkability and deniability was provided in some previous version of OTR by using MAC keys instead of long-term keys for signing messages. OTR even provides a stronger notion for it by also using malleable encryption so anyone can forge a message. So only revealing keys is not enough to achieve strong offline deniability. OTR also used an authenticated key exchange where conversation partners are able to reuse ephemeral keys signed by the other party in forged transcripts, thereby providing partial participation repudiation. This insight by Trevor Perrin is nice to read[2] It depends on what kind of notions of deniability want to be provided. > There might be another problem, regarding synchronicity: since MLS is completely asynchronous no one should publish a secret key too early (i.e. before others have consumed the encrypted messages) otherwise we might not be able to trust the authentication any longer. This is super interesting and it is problem ;), see section '3.4 Message Integrity' of this paper[3]. I think the notions of deniability in a cryptographic sense have evolved and new ways of achieving it have been studied. So many things can be done ;) 1. https://otr.cypherpunks.ca/otr-wpes.pdf 2. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html -- Sofía Celi @claucece Cryptographic research and implementation at many places FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02 From nobody Thu Jan 23 17:47:52 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 656CA1200CD for ; Thu, 23 Jan 2020 17:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=riseup.net 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 LFYtfpgEeTW7 for ; Thu, 23 Jan 2020 17:47:47 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C573120019 for ; Thu, 23 Jan 2020 17:47:47 -0800 (PST) Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 483hq70pmBzDsSX for ; Thu, 23 Jan 2020 17:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1579830467; bh=tPzSaAt7wTJYfbWSUeuMHJe4dbbWy3IHr+tbDLUSUhE=; h=Subject:From:To:References:Date:In-Reply-To:From; b=DWpjGh0ATtO5HobMGzjfHvDiCgZsEmT3s8SKq8Nnh+WJ4bOOSsMcKaKOo7vzzYn51 +EDuKq3gee4Fd2gLUoQ0ns5uIZAP0nVw22pCeldC4aaScVlj2ETxo3FSQ5bjFOHDcA fFPLYB0YznIQKF0Q3pXOlfoXJdgqS/aPhgBz9eb4= X-Riseup-User-ID: 805EFDED5B25050C636FB375009CE75815C1E1403161F0DD52579936B01CA881 Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 483hq63MmfzJnWd for ; Thu, 23 Jan 2020 17:47:46 -0800 (PST) From: =?UTF-8?Q?Sof=c3=ada_Celi?= To: mls@ietf.org References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net> Autocrypt: addr=cherenkov@riseup.net; keydata= mQINBF2PpxoBEADAIhbOpA23OBsXzg/aQakv88vaLv8Dxt2oR92Rz9cfxca736HKDeO19IFC F1Anu6ylQsJfoT4UUgbGIjJpHtQB3OVIcgvsMagfZ0lEHd1eG8H8K9wqSjwSphUJl9ra+tMW MEbSDVmeV6qvHeO63vrazXrgUKBf0jDae0HcK++AYiSeSpbTmN+zTsY3ZXy9H1sdNhMUlkGt jcpROrna2NaSL3YG8YNJHsN+zGPoaBbPo9gQALUvuxtg0yS/ecly2xomWIeH6qJ4yJonO/Ys WqAAC96n423BeC1cAyYjij8ydygnR3csTibUI/iPkoH8xstnTyrv3djyiunVuw1BQUNqmtLV v7meRZfIFbfnNatuuPYp7S5NnL58vUwY/BwlMb5OhyzdCckRcITAXiz8sp4LANx1lxIdbaQA 9NsYv32vem9Pd0wtdN5JTW3dajgJtPAC1yfR86rw9u/+BSW9KhRqNF0/a+hX/+Njdni9fkl9 EheZiFHNO+nXeGLy0kikhUXr5iLg8626fG9I8QYuNj05WIEntegvAW65YjGTYSCdVgLx2bvv oGwC/4/jWxNm8MTzv38f/9YAZ5u5DSG3dFKYAjwOhf1IgEMTEWj+bKDFvgpv5fdTFumLxNey M/v3viwuNjS1hscRbi6IO36v4sFce4K1C5GU93YIgao2j01M8QARAQABtB1yaXNldXAgPGNo ZXJlbmtvdkByaXNldXAubmV0PokCVAQTAQgAPhYhBPq5Ptx83RGY3P1FWJG7a0VvRC0CBQJd j6caAhsDBQkHhh+ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJG7a0VvRC0CEV0P/2UN rjx8LYmz/ydk2XO/uNWyobCtj/y9XBhZG9dpB8R43VC8OS5gv4Nw2ZLDrrpLQmaQ2dXjAeLL +9eCM++QT//VP2j2QS3YKbIcRreXSnl7DI6bMpD+Pu3JwiYHSyBs1zZT+VGm4nTS6QH588XJ VrslKyDYJFfzaHgkIGtxAWgqaHWAZHtjqh6PNEWMe2t571YYcVlk29cWsJ5ITsSPb+0Y0xJn u5HKQOc4TOdraedpLSFb5CZRlusNgWvhqmL4VyIcfjSEY0B8JVOgVpUeNTy0sZcDflYJ6uSN 9B1m79kb8STnVOtFS9gjnWbVwjAunqkkb/joRZhYfjeANVyYC4skh0uqJLFtqJw4r8s9+MrE p4lBy30lQ7mYYyqvRcwyEgoRRLHUvzV6cIHau/HV1pw0lwcbiXk3jP+TMf6OKOzg6lGJ/zX0 ZD+s0OAvHh8GM+5TDlgEM4Dwp6Q+9Jr1m9sp1QDQVbU7xrXXndXDd8RLEkiMDLovyyDtN6Jn HsW9PVMtu6sXvmbn0AHeHzHU/+bwB1LF4sx8O82tWKCgZlm270p+Bk6mjYmrlO4eQ11/AOF6 3ZlVoeXSaM4X0yoKa3ltdWaRoy9L0a4p7JuQYhBYIzjARbVjp9CmxctuQqW2qNSCJfagsUl8 mpcrs7xdhzfhzZHf8kQYWQcPYPPWLWqIuQINBF2PpxoBEACow9T4wPaQvKNG2LBnXeuLkDxf VGrZ/fDk0yfhG0174SjWXvDMIAgdNmfn2F4CM4F2FfPI32NZT34Td89fyWEWvP5/2I9HywyI QI/ubQvbqvm0l+DyzsdZNj4MBmNLy34Rg3K8uScgG7YbakzUplalbQKuzHrSW5OL5aBeKOG2 NGKJK7VZ4MzbdxhCLnXYvQwgnSkJ6B3AoBGv0LsLYzGUixzlMbNmYEhlQcK2scqprmFoX9rQ ymStV8b4Z37gkVmYeWGG2D9zl8gLj0u5Xw/KlF45JNxtMFBSL+Px7E1c+GJTWJxIENBhxRAu fxvbvduyJdXTObI51bqgV57510RjoLdzvVVqUpevmIdaMnavyUnDZOb8sBg3JG6NozZVzlXf S3FAvvK82zRShpd06ZNUbxPtNkruH/dT+6QV8gW3jX15gKGp2CtvhxLbi8ysV6zwtqxPkba2 03J0RAq2lVzxE/CSAP2qGPttElzHOPqhdmL6XjdmTw/WpF+qT8acB6Te8HZF+DriR/xG6EA1 MSdIK0vX4r5+U5bd0r7sh1ysSaYk/RI8hqxZZ4VGdPbVhFCOdT8AVcEXRoLsv+oN4x5WYJ9g 8G8Xw9+DvCNjFLxaGcL0ATHc8u8TyeegGRF3ZQNsRCqfVOLEYclYX+DqIly4ebCawAoIeWg2 GvN9cJAnFwARAQABiQI8BBgBCAAmFiEE+rk+3HzdEZjc/UVYkbtrRW9ELQIFAl2PpxoCGwwF CQeGH4AACgkQkbtrRW9ELQJX3g/8DAxtZTUJAlbKkluY30zITfcUwH4h9Rppxx/RvibZ1R4k 960OlvwyoRZ5rv2XiQA5VxOaVlh1tJErZnAyqgYwHr5CGQBjPEgkmRWBzme4W62uvCXOahxJ 4lNpr0TrVGRNOu223zYQcaN5S4Q5H2U9XNUFx8UF5leZIL6/Z6/bSGEW27vSuCxY6v8MkhQC 6l8T5RJqDsJmhwcVg9KDm8eGLkiu+kXS8iKl/Bw4o9257BI8hswBVRhN8kpHsecP2MGzKwn9 ccXWnOfM75qiq566UI26MY5priaGz5i+eCo26Rc0edm0IXxNs6rUZKVQUoxfMb/A/buJknYZ lUYXAgG2eDHEjlXvqNxQWHgfhIGqKFXDWuMt0sKP7Ta/lvGVPx9IHCTvkRZn9mtIN2/F9Lt5 sK3kezAlFw3BK6AIbD2v+g8TZnvKWSBidJHyhh7OEmKg3gXA3DxBpb7TU6iVUfG5e10RJUvQ qQNTSxv6mxJOgE3mEXizzj+tC6aEG/BzBwDsQpKquzUIKGCF2EGX9C7CZBhlsng/zmL3TFH6 EnY1tqV/lEg2/+gCLy/OE2dlE+EDZEtAiV183lzZNBs5Bg9NIz0Gq6a4ZkA8zDOFuxL2BFH2 EqrT33ladX2AIyKPMF50IwY4TMxGRlKhAjb4++pb55vBwVBLaTC09mvA+CuupPU= Message-ID: Date: Thu, 23 Jan 2020 20:47:45 -0500 MIME-Version: 1.0 In-Reply-To: <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 24 Jan 2020 01:47:50 -0000 I forgot to include paper [3] 3. http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf Thanks! On 1/23/20 8:42 PM, Sofía Celi wrote: > Hello! > > Very interesting insight! > >> What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place. > > The "sign & reveal" mechanism is something that can be considered coming > from OTR, because in it you reveal the MAC keys. But the idea, since the > first paper of OTR[1] was to use the revelation of keys as an additional > measure to expand the set of possible message forgers. Message > unlinkability and deniability was provided in some previous version of > OTR by using MAC keys instead of long-term keys for signing messages. > OTR even provides a stronger notion for it by also using malleable > encryption so anyone can forge a message. So only revealing keys is not > enough to achieve strong offline deniability. OTR also used an > authenticated key exchange where conversation partners are able to reuse > ephemeral keys signed by the other party in forged transcripts, thereby > providing partial participation repudiation. This insight by Trevor > Perrin is nice to read[2] > > > It depends on what kind of notions of deniability want to be provided. > >> There might be another problem, regarding synchronicity: since MLS is > completely asynchronous no one should publish a secret key too early > (i.e. before others have consumed the encrypted messages) otherwise we > might not be able to trust the authentication any longer. > > This is super interesting and it is problem ;), see section '3.4 Message > Integrity' of this paper[3]. > > > I think the notions of deniability in a cryptographic sense have evolved > and new ways of achieving it have been studied. So many things can be > done ;) > > > 1. https://otr.cypherpunks.ca/otr-wpes.pdf > 2. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html > > > -- Sofía Celi @claucece Cryptographic research and implementation at many places FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02 From nobody Thu Jan 23 23:12:26 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 D9689120041 for ; Thu, 23 Jan 2020 23:12:23 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 nkd5rFm6EQDA for ; Thu, 23 Jan 2020 23:12:21 -0800 (PST) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (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 6BCE812004F for ; Thu, 23 Jan 2020 23:12:21 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 483r1Z33PlzQl99 for ; Fri, 24 Jan 2020 08:12:18 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id CnOyfQOy2MSI for ; Fri, 24 Jan 2020 08:12:14 +0100 (CET) From: Konrad Kohbrok To: mls@ietf.org References: <2D478053-DBB9-440C-BF19-35BD489D7814@sn3rd.com> Message-ID: Date: Fri, 24 Jan 2020 08:12:14 +0100 MIME-Version: 1.0 In-Reply-To: <2D478053-DBB9-440C-BF19-35BD489D7814@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit 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: Fri, 24 Jan 2020 07:12:24 -0000 Hi everyone, for anyone planning on attending EuroCrypt, note that there are workshops on the 9th and 10th of May. (See here: https://eurocrypt.iacr.org/2020/affiliatedevents.html) (I'm mostly reminding all of you, because I'll have to be there at the 9th myself ;-)) Cheers, Konrad On 13.01.20 17:57, Sean Turner wrote: > All, > > 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: > > https://doodle.com/poll/cd5zr7aeax3dx4e7 > > Cheers, > > Nick & Sean > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Fri Jan 24 08:57:55 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 F37C7120A9C; Fri, 24 Jan 2020 08:57:52 -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@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157988507279.22081.1223592772840045402@ietfa.amsl.com> Date: Fri, 24 Jan 2020 08:57:52 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-01-29 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, 24 Jan 2020 16:57:53 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-01-29 from 14:00 to 15:00 GMT. Agenda: https://github.com/mlswg/mls-protocol/pulls Information about remote participation: https://github.com/mlswg/wg-materials From nobody Sat Jan 25 23:41:03 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 9FDF712008F for ; Sat, 25 Jan 2020 23:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=lsshYzh1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZRwprS8X 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 08lMAhPboDKX for ; Sat, 25 Jan 2020 23:40:55 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2BF120090 for ; Sat, 25 Jan 2020 23:40:55 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6883C4D6 for ; Sun, 26 Jan 2020 02:32:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 26 Jan 2020 02:32:39 -0500 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= fm1; bh=9zcuUyHyeq0BEEhwI53olAJ1ethU9x54cE9/+/YQKaU=; b=lsshYzh1 wZox743Doxok++uwTOmccoqCaIAlztWVx1n+AH9pm0UjBXW1cYeNsLnRrYG5gBPR HMg3HcYQYx1/Khp8n9zJDd75ZQKyXCE4egKMul7+h9tNKIDUptYlyBYZWhE3fEpL YdTAiSj2kyqp8/fopepJGT2ICs5iwS6H38Jde5wBcdavjMkso4E/fBGjmgOOHk1R kDIeyj8a5O/enfbdYRp02V+AUDfejH5h8XrMa+9w3d9lAUk3PY2YyxABKSp+j1RJ fZ3al8hayGZW9vQUQXpsrBK3sL4b8XySj1WwS137bGo/CWo0/USHSVM5+O1BORMr FSGgNXfxbNAJcQ== 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=fm1; bh=9zcuUyHyeq0BEEhwI53olAJ1ethU9 x54cE9/+/YQKaU=; b=ZRwprS8XjUhbGHsFpoFpzvIxSfzQKA67I0FiaGnJnZToO 2wMQ1yihMwpWbZaJt8m799DjLeCSeUTfntWTcS/F/n3R6t1c/3hCMOTRIqqPzmmu I6fWkFRj4YLfvGYHv+oROrKNLy8rJEeZ/9EDeMc7rFM2ByrXagR6B4bLfPN4OUzC Dea1sVz/xTPzxat4s55rf89dhUiIfZF17MJKTDSnqz/Jtb6pUBdXIIDSBFZuKTwl w6bt+Rlibd9BNjNumI67/Q/Ts9S/pZUErXhmpfXoo4nUFht5mExDsZ4rq9LjElsL jN3DJiZHNslosQSdgsYDNk8C4fb1y4q535n9XcKfg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdelgdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehvddrudekgedrudeljedrgeenucevlhhushhtvghr ufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.184.197.4]) by mail.messagingengine.com (Postfix) with ESMTPA id D68AD328005A for ; Sun, 26 Jan 2020 02:32:38 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0813943752321702661==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200126073238.D68AD328005A@mailuser.nyi.internal> Date: Sun, 26 Jan 2020 02:32:38 -0500 (EST) 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, 26 Jan 2020 07:40:58 -0000 --===============0813943752321702661== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Spelling fixes in various sections. (by GaPhil) https://github.com/mlswg/mls-architecture/pull/59=20 1 pull requests received 1 new comments: - #59 Spelling fixes in various sections. (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/59=20 1 pull requests merged: - Spelling fixes in various sections. https://github.com/mlswg/mls-architecture/pull/59=20 * mlswg/mls-federation (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - Spelling fixes in various sections. (by GaPhil) https://github.com/mlswg/mls-federation/pull/3=20 1 pull requests received 2 new comments: - #3 Spelling fixes in various sections. (2 by GaPhil, raphaelrobert) https://github.com/mlswg/mls-federation/pull/3=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============0813943752321702661== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 26, 2020

Pull requests

mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

mlswg/mls-federation (+1/-0/=F0=9F=92=AC2)

1 pull requests submitted:

1 pull requests received 2 new comments:

Repositories tracked by this digest:

--===============0813943752321702661==-- From nobody Sun Jan 26 07:09:31 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 8E360120096 for ; Sun, 26 Jan 2020 07:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 (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 f8XCb5oQqjrd for ; Sun, 26 Jan 2020 07:09:27 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 E0C48120091 for ; Sun, 26 Jan 2020 07:09:26 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id a12so2575820uan.0 for ; Sun, 26 Jan 2020 07:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p8ML645983zrHpAcCJ//ql99uj1MFqmycIIXh8mDISA=; b=tWnlgLCb6/auz+3R1PklavdxFnpE6Yf8Bx9MMKeFZLhKsNTCotvC5VBWPKDlK99cQC M6up+fW9VODL/Ymsxzj0ZhC1pXqYrZT0git1E5KzwnXuE9q/CEyGHD9b5Skw08wZbp63 Snh0DhOBIdhei0GWDPbyUElp+0I5tE/cKJD07P1AOC8VP57kZiorZm9eg/GPWvGbC+F8 eZT9lsjVWFBqB6XJXqNO0Rm8LPaEAwHbjjusUj4/8Ny3SyDBcxfPqH11VXwLqpknPdC5 w78mEUuNPa/Jv+mLX7Gu0yK3+EoxQ/KtH+LV31Ck+nv2aZhJp0rBQwsisfxAZV+yTIaO KGsw== 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=p8ML645983zrHpAcCJ//ql99uj1MFqmycIIXh8mDISA=; b=n69NkFX+MOGz265BdtjHIP0dhTtadZ7M+Mw+i5HpMszMmOyBXcaccAX59nDpMCRtVD JDVLfnjND+2zFgH//EN8CHuF3mt6cSGnotOsqQo47NBRdAjWcTxWEwLHyi/K0mdXO43k tm2H47SzXXYbG6m3+xQNUouB3iJUqJ8Nz+erVl/BXBRcjKWgerMcY2e9bnAyaH/OJRwB NI3ZjVNS1qJ/AX0BKr4jmgWgnOU7GXIOw86+pZYf4y4yL3k4ZMETKSjnfEtD80kQHh5p HZNL1FP8nJRuJ2yEwC5fZr6TE0kTla+hcBjVozUUjRUZa9wrCQdx5N0UlRQ99CanI0uH 77Fg== X-Gm-Message-State: APjAAAXoy/91i0E/r5QDCV17tJOd31zG6reGxMW4UEy7Ioc6a3NXZQYu tvuO0EJ9N44Apwq7JRD0LC62JO2S0pnQHFojBmc= X-Google-Smtp-Source: APXvYqwtE+Ov6QW6cBNzEdbml7BCFugJ/CS9AxU34mlskbKMVnymViVxRVtvNowtXj2Sx/i4JGCgar/wEYTK/h59bmw= X-Received: by 2002:ab0:74ce:: with SMTP id f14mr7210133uaq.118.1580051365768; Sun, 26 Jan 2020 07:09:25 -0800 (PST) MIME-Version: 1.0 References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net> In-Reply-To: From: Natanael Date: Sun, 26 Jan 2020 16:09:09 +0100 Message-ID: To: =?UTF-8?Q?Sof=C3=ADa_Celi?= Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000623163059d0c6049" Archived-At: Subject: Re: [MLS] Deniability without pairwise channels. 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, 26 Jan 2020 15:09:30 -0000 --000000000000623163059d0c6049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have previously suggested a method for deniable authentication using a VDF (verifiable delay function); This variant of deniable authentication would use a VDF construction with a private key based shortcut function (like a PKE / VDF hybrid function), implementing a challenge-response protocol where the verifier uses the prover's public key to construct a challenge which only the prover can immediately respond correctly to, but where the correct response value will also automatically become public later on (since anybody can solve the VDF, but not fast enough). See more here: https://www.reddit.com/r/crypto/comments/bt7cq4 This construction provides authentication trough latency / provenance / time asymmetry - as the verifier you know that you just constructed the challenge with fresh randomness, and you know that only the private key holder can respond before the timeout, while anybody else will be unable to reply before the timeout / expiration of the challenge. For example, a correct reply within a second when the VDF takes at minimum an hour to solve is a certain proof of authentication. This also means a genuine live session is indistinguishable from a forged live session, since you can trivially pre-compute inauthentic replies to your own arbitary challenges. For example, Alice and Bob can authenticate to each other in a live genuine session while Carol and Dave can simultaneously conspire together to pretend to be Alice and Bob in their own separate inauthentic session. Eve can not distinguish between these two sessions even when watching the traffic live, because Eve don't know how the respective challenges were chosen (fresh or pre-computed). This should at minimum be an improvement over ring signatures (there's no longer a limited group of possible provers), and many similar constructions. The inherent automatic disclosure via the VDF is also an improvement over manual MAC disclosure, and the prover does not otherwise need to actively take action to disassociate themselves from the session contents. It would also be KCI attack resistant, since since disclosure of your private key does not impact your ability to securely verify other's responses to your challenges. Note 1: I have not currently worked out how to best solve session binding, this may vary between different protocols and VDF primitive. You need to bind to session ID:s / session keys in some way. Perhaps by introducing them as variables in the VDF construction. Note 2: I don't currently know of a specific VDF primitive that would be suitable for this. If there's no VDF construction that can do this stand-alone, then this can still be done in a less elegant manner by constructing the challenge message as a trio of VDF encrypted challenge, public key encrypted challenge, and a Zero-knowledge proof that show the two are equivalent. The prover verifies equivalence first and then decrypt and returns the challenge value, while the VDF still serves as a way to ensure the transcript proves nothing after the fact. Den fre 24 jan. 2020 02:47Sof=C3=ADa Celi skrev: > I forgot to include paper [3] > > 3. http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf > > Thanks! > > On 1/23/20 8:42 PM, Sof=C3=ADa Celi wrote: > > Hello! > > > > Very interesting insight! > > > >> What has become clearer in some of the discussion is that a =E2=80=9Cs= ign & > reveal=E2=80=9D scheme puts the burden of proof on the victim to some (la= rge) > extent. The attacker can publish a signature chain that starts with the > public identity of the victim and ends with the signature of a specific > message. This signature chain will most likely look valid to a third part= y > at first sight. It then becomes the duty of the victim to prove that they > indeed published secret keys and that therefore anyone could have signed > the last part in the signature chain. For the victim, this is painful at > best and impossible at worst. It would be much nicer if the attacker > couldn=E2=80=99t publish such a signature chain in the first place. > > > > The "sign & reveal" mechanism is something that can be considered comin= g > > from OTR, because in it you reveal the MAC keys. But the idea, since th= e > > first paper of OTR[1] was to use the revelation of keys as an additiona= l > > measure to expand the set of possible message forgers. Message > > unlinkability and deniability was provided in some previous version of > > OTR by using MAC keys instead of long-term keys for signing messages. > > OTR even provides a stronger notion for it by also using malleable > > encryption so anyone can forge a message. So only revealing keys is not > > enough to achieve strong offline deniability. OTR also used an > > authenticated key exchange where conversation partners are able to reus= e > > ephemeral keys signed by the other party in forged transcripts, thereby > > providing partial participation repudiation. This insight by Trevor > > Perrin is nice to read[2] > > > > > > It depends on what kind of notions of deniability want to be provided. > > > >> There might be another problem, regarding synchronicity: since MLS is > > completely asynchronous no one should publish a secret key too early > > (i.e. before others have consumed the encrypted messages) otherwise we > > might not be able to trust the authentication any longer. > > > > This is super interesting and it is problem ;), see section '3.4 Messag= e > > Integrity' of this paper[3]. > > > > > > I think the notions of deniability in a cryptographic sense have evolve= d > > and new ways of achieving it have been studied. So many things can be > > done ;) > > > > > > 1. https://otr.cypherpunks.ca/otr-wpes.pdf > > 2. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html > > > > > > > > -- > Sof=C3=ADa Celi > @claucece > Cryptographic research and implementation at many places > FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000623163059d0c6049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have previously suggested a method for deniable authent= ication using a VDF (verifiable delay function);

This variant of deniable authentication would use a VDF = construction with a private key based shortcut function (like a PKE / VDF h= ybrid function), implementing a challenge-response protocol where the verif= ier uses the prover's public key to construct a challenge which only th= e prover can immediately respond correctly to, but where the correct respon= se value will also automatically become public later on (since anybody can = solve the VDF, but not fast enough).=C2=A0


This construction p= rovides authentication trough latency / provenance / time asymmetry - as th= e verifier you know that you just constructed the challenge with fresh rand= omness, and you know that only the private key holder can respond before th= e timeout, while anybody else will be unable to reply before the timeout / = expiration of the challenge.=C2=A0

For example, a correct reply within a second when the VDF takes = at minimum an hour to solve is a certain proof of authentication.=C2=A0

This also means a genuine l= ive session is indistinguishable from a forged live session, since you can = trivially pre-compute inauthentic replies to your own arbitary challenges.= =C2=A0

For example, Alic= e and Bob can authenticate to each other in a live genuine session while Ca= rol and Dave can simultaneously conspire together to pretend to be Alice an= d Bob in their own separate inauthentic session. Eve can not distinguish be= tween these two sessions even when watching the traffic live, because Eve d= on't know how the respective challenges were chosen (fresh or pre-compu= ted).=C2=A0

This should = at minimum be an improvement over ring signatures (there's no longer a = limited group of possible provers), and many similar constructions. The inh= erent automatic disclosure via the VDF is also an improvement over manual M= AC disclosure, and the prover does not otherwise need to actively take acti= on to disassociate themselves from the session contents.=C2=A0

It would also be KCI attack resistan= t, since since disclosure of your private key does not impact your ability = to securely verify other's responses to your challenges.=C2=A0

Note 1: I have not currently worked out how to best solve session bi= nding, this may vary between different protocols and VDF primitive. You nee= d to bind to session ID:s / session keys in some way. Perhaps by introducin= g them as variables in the VDF construction.=C2=A0

Note 2: I don't currently know of a specific VDF primitive that would= be suitable for this. If there's no VDF construction that can do this = stand-alone, then this can still be done in a less elegant manner by constr= ucting the challenge message as a trio of VDF encrypted challenge, public k= ey encrypted challenge, and a Zero-knowledge proof that show the two are eq= uivalent.=C2=A0

The prover verifies equivalence first and then decrypt and returns= the challenge value, while the VDF still serves as a way to ensure the tra= nscript proves nothing after the fact.=C2=A0

Den fre 24 jan. 2020 02:47Sof=C3=ADa Celi <cherenkov@riseup.net> skrev:
I forgot to include paper [3]

3. http://www.jbonneau.com/doc/BM06-O= TR_v2_analysis.pdf

Thanks!

On 1/23/20 8:42 PM, Sof=C3=ADa Celi wrote:
> Hello!
>
> Very interesting insight!
>
>> What has become clearer in some of the discussion is that a =E2=80= =9Csign & reveal=E2=80=9D scheme puts the burden of proof on the victim= to some (large) extent. The attacker can publish a signature chain that st= arts with the public identity of the victim and ends with the signature of = a specific message. This signature chain will most likely look valid to a t= hird party at first sight. It then becomes the duty of the victim to prove = that they indeed published secret keys and that therefore anyone could have= signed the last part in the signature chain. For the victim, this is painf= ul at best and impossible at worst. It would be much nicer if the attacker = couldn=E2=80=99t publish such a signature chain in the first place.
>
> The "sign & reveal" mechanism is something that can be c= onsidered coming
> from OTR, because in it you reveal the MAC keys. But the idea, since t= he
> first paper of OTR[1] was to use the revelation of keys as an addition= al
> measure to expand the set of possible message forgers. Message
> unlinkability and deniability was provided in some previous version of=
> OTR by using MAC keys instead of long-term keys for signing messages.<= br> > OTR even provides a stronger notion for it by also using malleable
> encryption so anyone can forge a message. So only revealing keys is no= t
> enough to achieve strong offline deniability. OTR also used an
> authenticated key exchange where conversation partners are able to reu= se
> ephemeral keys signed by the other party in forged transcripts, thereb= y
> providing partial participation repudiation. This insight by Trevor > Perrin is nice to read[2]
>
>
> It depends on what kind of notions of deniability want to be provided.=
>
>> There might be another problem, regarding synchronicity: since MLS= is
> completely asynchronous no one should publish a secret key too early > (i.e. before others have consumed the encrypted messages) otherwise we=
> might not be able to trust the authentication any longer.
>
> This is super interesting and it is problem ;), see section '3.4 M= essage
> Integrity' of this paper[3].
>
>
> I think the notions of deniability in a cryptographic sense have evolv= ed
> and new ways of achieving it have been studied. So many things can be<= br> > done ;)
>
>
> 1. https://otr.cypherpunks.ca/otr-wpes.pdf
> 2. https://lists= .cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html
>
>
>

--
Sof=C3=ADa Celi
@claucece
Cryptographic research and implementation at many places
FAB9=C2=A03EDC=C2=A07CDD=C2=A01198=C2=A0DCFD=C2=A0=C2=A04558=C2=A091BB=C2= =A06B45=C2=A06F44=C2=A02D02

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000623163059d0c6049-- From nobody Sun Jan 26 07:39:36 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 C6B1C120046; Sun, 26 Jan 2020 07:39:33 -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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <158005317350.30533.9373360075135640508@ietfa.amsl.com> Date: Sun, 26 Jan 2020 07:39:33 -0800 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-04.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: Sun, 26 Jan 2020 15:39:34 -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) Architecture Authors : Emad Omara Benjamin Beurdouche Eric Rescorla Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-04.txt Pages : 18 Date : 2020-01-26 Abstract: This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications with from two to a large number of clients. It is meant to protect against eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-architecture-04 https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-04 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 Sun Jan 26 07:43:14 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 911F3120046 for ; Sun, 26 Jan 2020 07:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJZNwEv4Tz2w for ; Sun, 26 Jan 2020 07:43:09 -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 0429012006B for ; Sun, 26 Jan 2020 07:43:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,366,1574118000"; d="scan'208";a="337046289" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2020 16:43:07 +0100 From: Benjamin Beurdouche Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sun, 26 Jan 2020 16:43:04 +0100 References: <158005317350.30533.9373360075135640508@ietfa.amsl.com> To: ML Messaging Layer Security In-Reply-To: <158005317350.30533.9373360075135640508@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] I-D Action: draft-ietf-mls-architecture-04.txt 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, 26 Jan 2020 15:43:12 -0000 Dear all, I just published a new draft of the MLS Architecture document. It mainly contains editorial changes and clarifications over the = previous draft. B. > On Jan 26, 2020, at 4:39 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : The Messaging Layer Security (MLS) = Architecture > Authors : Emad Omara > Benjamin Beurdouche > Eric Rescorla > Srinivas Inguva > Albert Kwon > Alan Duric > Filename : draft-ietf-mls-architecture-04.txt > Pages : 18 > Date : 2020-01-26 >=20 > Abstract: > This document describes the reference architecture, functional and > security requirements for the Messaging Layer Security (MLS) > protocol. MLS provides a security layer for group messaging > applications with from two to a large number of clients. It is = meant > to protect against eavesdropping, tampering, and message forgery. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mls-architecture-04 > https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mls-architecture-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Jan 28 14:53:14 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 69BE01200F4 for ; Tue, 28 Jan 2020 14:53:12 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 jeHEt1KKp_nR for ; Tue, 28 Jan 2020 14:53:10 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 816DD12006D for ; Tue, 28 Jan 2020 14:53:10 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id a12so5496071uan.0 for ; Tue, 28 Jan 2020 14:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=owhWe0ngQ0GjHtaWCrt7yxF9BKQv8zTn0sKQQpZU0m4=; b=QLRtJdeFOLkzluZIOT4ZdEis0I/T67qpMAAd6pBGAzq0Df2AeelwOXZuiXXlI6fy3H qNOVcYbT5pvGJSSdhj9YigM1ioJVKlq/6I33Da8LHqRZIK9n/FDMlojYhye1C3Kvx3s8 yrVjDHvLuk8bb2eGmXjWelq0i5RuAbd/7ZSFI= 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=owhWe0ngQ0GjHtaWCrt7yxF9BKQv8zTn0sKQQpZU0m4=; b=NzXkOcK8klD/0S2sVzd6w8C3+NL3YxFLXKyW9yNtepr/EDgjrJfPLBD3s1/5SlAK9I Mj7ZSd5Dz6ZVNmlu14DNT00FHzD0RxGVHgr/DBGmxkOUG2sPD2SxCXh9xSpGK/8g3ZyV Iqir3OfJU3O6hX8ukHBE6wbjrs9V+Xhj8s9aUeL+s8ur4XogU7h85oaFpBbSgAQhL4IL XeMOKMra/WCInHrr9BT1RsBdokV8yCg0YhxegzFjdkjaG/su0VFfygAcJD3m/SFcVSEa Uw8qeFdqPGmIjKnlzwsQsTXYoqEOlcVDY3chTYm44A2nuPQrVE4/HjY+ao5IbA/sVMJC QDiw== X-Gm-Message-State: APjAAAVw9luI+5a84gniMDmcYSgT9oPFIIGo6mXXKgCQCtGwOOTAqdW8 08SIfqlJsAR4il4x2Ncv/qUcYlzwcp0U3bG9tx9YpQ== X-Google-Smtp-Source: APXvYqzTZ6l51mqBZpbpWfyqDs0//Mkou2eJeMuGTRbz+8csaXivfXj/jlE6at7301+A2BdatX4gx8NDXT7r8/jc9Y8= X-Received: by 2002:ab0:1051:: with SMTP id g17mr15429486uab.52.1580251989455; Tue, 28 Jan 2020 14:53:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 28 Jan 2020 14:52:22 -0800 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG , Benjamin Kaduk , Roman Danyliw Content-Type: multipart/alternative; boundary="0000000000007cedc6059d3b16b2" 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: Tue, 28 Jan 2020 22:53:12 -0000 --0000000000007cedc6059d3b16b2 Content-Type: text/plain; charset="UTF-8" As a reminder, the recurring virtual interim is tomorrow. Here's the meeting information: Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m2e0d1a76482036fdb38c7d1f5fdd3cc6 Meeting number: 647 391 156 Password: ve2i8niw https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurring Nick & Sean 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. > > 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. > > 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 ). > > Links to the conference calls are forthcoming. > > Nick & Sean > > 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. >> >> 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: >>> >>> https://doodle.com/poll/bg2q65phrvfip5zb >>> >>> 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. >>> >>> --Richard >>> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --0000000000007cedc6059d3b16b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a reminder, the recurring virtual interim is tomor= row. Here's the meeting information:

Meeting l= ink: https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fd= b38c7d1f5fdd3cc6
Meeting number: 647 391 156
Password: ve2i8niw

https://github.com/mlswg/wg-materials/t= ree/master/virtual-interim-recurring

Nick & = Sean

On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan <nick@cloudflare.com> wrote:
It looks like Wednesday at 1400-1500 GMT is the least bad time.

These calls will be recurring vi= rtual interims, and as such are covered by the note well.=C2=A0As a reminde= r, decisions made at interim meetings are not final and must be confirmed o= n the list.

Here's the proposed schedule (subj= ect to AD approval):
Time: 1400-1500 GMT on Wednesdays
Agenda: the set of active PRs for the active documents on Git= hub (https://github.com/mlswg).

Li= nks to the conference calls are forthcoming.

Nick & Sean

On Mon, Jan 13, 2020 at 8:51= AM Richard Barnes <rlb@ipv.sx> wrote:
Also: Note that despite this = poll listing specific dates, the intent is to set up a weekly recurring mee= ting.=C2=A0 In fact, these dates will definitely not be the dates when the = calls happen, because IETF requires one week notice.

On Sun, Jan 12, 202= 0 at 6:05 PM Richard Barnes <rlb@ipv.sx> wrote:
I would like to= have some weekly calls to make faster progress on our outstanding PRs.=C2= =A0 Here's a Doodle to find a good time:


I believe thes= e will need to be official Virtual Interims per IETF process.=C2=A0 Chairs,= I assume you can do whatever announcements are necessary once we pick a ti= me.

--Richard
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000007cedc6059d3b16b2-- From nobody Tue Jan 28 15:56: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 03CC11200FF for ; Tue, 28 Jan 2020 15:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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] 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 vsYgzZKaNU1u for ; Tue, 28 Jan 2020 15:56:00 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 A1F69120020 for ; Tue, 28 Jan 2020 15:56:00 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id c24so11808138qtp.5 for ; Tue, 28 Jan 2020 15:56:00 -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=Xg7nR2SL6Ud8QCVKjCbaS4KVw7WQPnBoT/rgsiaLSck=; b=a1roP91aRrGMy1zFTPjz6sXKdPkFWnSgKjFWrh385HV6sr+yXRiHS6TLU8h9Fmn8O9 kims6RNXO3ZBMZ4SGbruJJOsEsCyZKkltjtIK5Iz76b5ARGZzFK2r6xbXMY9cMOiTGbQ h5KRWnKUD818z1ECympG+0kg14PddlbsHmL0UPg3nlgLcOiDknraTOs6bmqEoSqIKbZK QvdJ8Ub2ZEz7JESBiMLNwwHupkMHaZl2ibBqLY3uxSnQrSlq5vVD17mKKlGDgR/VE456 /q5xh6IcWhC2tYcZ1t2adImu4t8B5ZS4nRAgcvP+iOBiECQWVuH95KyaH0Pu7maRXzKC 2qfg== 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=Xg7nR2SL6Ud8QCVKjCbaS4KVw7WQPnBoT/rgsiaLSck=; b=tEcTHv5ej12i5vsi9bdva3J8m1jTiyATbYR1UMeyWiWbasth6Bjst6cuP4Y4kFZWwH mFMkKBCWxK6gAXGdRT+V0h2VFW1QrcbygZ/ZCM2NeD6atC7pOAb42T7sGbj7ztIynv0F 6MQKcNzdInw/R36IVYmJi+ykfpivDDejHrZPig3vPHgdpk9lZ30Ri3JGxrE8LJjhcyfV K/zwwMHG6HTZQmmZsEp/KTMnYnQchxPGacIcdakp1Kzm22AxFmoLg5DNoxgqIU/Fijub pQ9ZtCx5E38QzpVQAeCPWW3Npw0ugI+pB4EnD7c6URAunx4pL69VDNS+ff2m3wIIlApl pKQw== X-Gm-Message-State: APjAAAUzewP6Nt8/eSGe9xoa9AQ/0cbsbhFiPAesxel6h8JcJevCQgB9 YQq6lBpMfS+VgzlU9xHZvAr24U1U1TEFozQcdb2n0A== X-Google-Smtp-Source: APXvYqwwsiIx37/98ygQb8h5V3hmnpbAKSayueMI8tAmSuBodhdkaS6FRrvdE1RGvmeEDBVNQn28ajj8PnWpyihFDo8= X-Received: by 2002:ac8:47c1:: with SMTP id d1mr23361530qtr.84.1580255759513; Tue, 28 Jan 2020 15:55:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 28 Jan 2020 18:55:35 -0500 Message-ID: To: Nick Sullivan Cc: Messaging Layer Security WG , Benjamin Kaduk , Roman Danyliw Content-Type: multipart/alternative; boundary="000000000000335033059d3bf721" 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: Tue, 28 Jan 2020 23:56:03 -0000 --000000000000335033059d3bf721 Content-Type: text/plain; charset="UTF-8" I flagged four issues as "today! (?)" if people want to read ahead: https://github.com/mlswg/mls-protocol/pulls?q=is%3Aopen+is%3Apr+label%3A%22today%21+%28%3F%29%22 On Tue, Jan 28, 2020 at 5:53 PM Nick Sullivan wrote: > As a reminder, the recurring virtual interim is tomorrow. Here's the > meeting information: > > Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=m2e0d1a76482036fdb38c7d1f5fdd3cc6 > Meeting number: 647 391 156 > Password: ve2i8niw > > https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurring > > Nick & Sean > > 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. >> >> 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. >> >> 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 ). >> >> Links to the conference calls are forthcoming. >> >> Nick & Sean >> >> 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. >>> >>> 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: >>>> >>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>> >>>> 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. >>>> >>>> --Richard >>>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --000000000000335033059d3bf721 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I flagged four issues as "today! (?)" if pe= ople want to read ahead:


On Tue, Jan 28, 2020 at 5:53 PM= Nick Sullivan <nick@cloudflare.c= om> wrote:
As a reminder, the recurring virtual interim is tom= orrow. Here's the meeting information:

Meeting= link: https://ietf.webex.com/ietf/j.php?MTID= =3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6
Meeting number: 647 391 156
= Password: ve2i8niw

h= ttps://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurring<= /a>

Nick & Sean

On Wed, Jan 22, 2020 at 11:= 04 AM Nick Sullivan <nick@cloudflare.com> wrote:
It looks l= ike Wednesday at 1400-1500 GMT is the least bad time.

These calls will be recurring virtual interims, an= d as such are covered by the note well.=C2=A0As a reminder, decisions made = at interim meetings are not final and must be confirmed on the list.
<= div>
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).

Links to the confere= nce calls are forthcoming.

Nick & Sean

On Mon, Jan 13, 2020 at 8:51 AM Richard Barne= s <rlb@ipv.sx> wrote:
Also: Note that despite this poll listing spec= ific dates, the intent is to set up a weekly recurring meeting.=C2=A0 In fa= ct, these dates will definitely not be the dates when the calls happen, bec= ause IETF requires one week notice.

On Sun, Jan 12, 2020 at 6:05 PM Rich= ard Barnes <rlb@ipv.sx> wrote:
I would like to have some weekly= calls to make faster progress on our outstanding PRs.=C2=A0 Here's a D= oodle to find a good time:


I believe these will need to be = official Virtual Interims per IETF process.=C2=A0 Chairs, I assume you can = do whatever announcements are necessary once we pick a time.

=
--Richard
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000335033059d3bf721-- From nobody Wed Jan 29 13:39:36 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 2EA9612004E for ; Wed, 29 Jan 2020 13:39:34 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 xko_dVqtAPED for ; Wed, 29 Jan 2020 13:39:31 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 C3A5D120045 for ; Wed, 29 Jan 2020 13:39:30 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id n27so821389vsa.0 for ; Wed, 29 Jan 2020 13:39:30 -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=X4LC42jE6h1Blf38WhwfPkrNywJLRygzhuE/NTic+qI=; b=dVRzN00oQ2B/q2UCHELlmG2Li5YajmV32oHzbS+sdV8ExyEohKsnR6oZPlnJkaSUSB RBjT6fKi3uEuFImgUgy4ctlTpxLejuaX5KONaf24UGGwdNKb1NPc5u88PM2aSdcUU15X 6eHdYHJx2WAxsYEXflvIML4tzddpLc9qxQqPI= 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=X4LC42jE6h1Blf38WhwfPkrNywJLRygzhuE/NTic+qI=; b=J2USVHskoHngRHFw6Q3NKVLlqWRcKwMAcY09klYg5j/LKjN5+digwm3SrWtGCjfp7t oRQUqkucu+Uek36/umxWePIJ6YmywiBIrmRcmAx1mpBpWXm0VXt44a9MmG5fMVUDHULN 8IFFe1tgdx5rtaOClxqPWc0M8uM2rNgkEDMba/TlMioV2GrYZIKAhtixgsF7r96hqFUc sh6CG8TMbvAKT8tjA/+vJmvsiMVdek7HX8O0vg82++2ASQAp2PKqxkQd2mtqxMkTJM1q Ki2NawR5gx3/d4f6r+701Zl8MZILJTUGyEXTw2oSH8r66gKLrFn2Yul8cSdiFTHVnNc4 IEXA== X-Gm-Message-State: APjAAAVdp7wdMt+FHoSjrxjwZ2/jyFwkdJsLHLpQPKVcq/xncDi1WQsO 2ikfpdMTfTL9mPYz+ngpf6J2DgJtYbZp/apvqgdLrLepjatn5g== X-Google-Smtp-Source: APXvYqwJjAxJTObZNCa2QW1cghEViYTNatZK8HB9rGfQGGtMIC0cb885HOPNQr3rhuG/vpCjipoAYQN/ZLO3jZHCU/I= X-Received: by 2002:a05:6102:30a7:: with SMTP id y7mr1090498vsd.212.1580333968645; Wed, 29 Jan 2020 13:39:28 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Wed, 29 Jan 2020 13:38:34 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d411a6059d4e2c58" Archived-At: Subject: [MLS] Virtual Interim minutes 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, 29 Jan 2020 21:39:34 -0000 --000000000000d411a6059d4e2c58 Content-Type: text/plain; charset="UTF-8" MLSWG, Draft minutes from the productive first virtual interim posted below. If you find an issue, submit a PR to Github: https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurring/01-29-2020.md Nick & Sean >>> Attendees: Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan McMillion, Nick Sullivan #247 - Welcome confirmation and key derivation * Fixes bugs RLB found in the last draft while implementing * OK to merge after rebase / conflict resolution #246 - Bugfixes in ClientInitKey, Commit, and Welcome * Derives the Welcome encryption key instead of generating fresh * ... under the general theory about not requiring freshness when not necessary * OK to merge after rebase / conflict resolution #283 - Use the same ratchet for Handshake and Application keys * There's no point to FS for Proposals because clients have to cache the plaintext anyway * Given that, the "flat derivation" approach should be fine * We should have separate keys per sender to it easier to avoid nonce collisions * RLB and RR to decide whether we should derive nonces on a hash ratchet or just use a counter #287 - Switch to signing strategy using one signature per leaf. * There was agreement among those on the call to proceed with this strategy (tree-hash-covers-parent-hash) * ... given the deniability concerns and unclear benefit of the alternative (parent-hash-covers-tree-hash) * If further considerations come to light from analysis, we can revisit later --000000000000d411a6059d4e2c58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
MLSWG,

Draft minutes from th= e productive first virtual interim posted below. If you find an issue, subm= it a PR to Github:

Nick & Sean

>&= gt;>
Attendees:
Joel Alwen, Richard Barnes, Raphael = Robert, Britta Hale, Brendan McMillion, Nick Sullivan

#= 247 - Welcome confirmation and key derivation
* Fixes bugs RLB found in = the last draft while implementing
* OK to merge after rebase / conflict = resolution

#246 - Bugfixes in ClientInitKey, Commit, and Welcome
= * Derives the Welcome encryption key instead of generating fresh
* ... u= nder the general theory about not requiring freshness when not necessary* OK to merge after rebase / conflict resolution

#283 - Use the sam= e ratchet for Handshake and Application keys
* There's no point to F= S for Proposals because clients have to cache the plaintext anyway
* Giv= en that, the "flat derivation" approach should be fine
* We sh= ould have separate keys per sender to it easier to avoid nonce collisions* RLB and RR to decide whether we should derive nonces on a hash ratchet = or just use a counter

#287 - Switch to signing strategy using one si= gnature per leaf.
* There was agreement among those on the call to proce= ed with this strategy (tree-hash-covers-parent-hash)
* ... given the den= iability concerns and unclear benefit of the alternative (parent-hash-cover= s-tree-hash)
* If further considerations come to light from analysis, we= can revisit later
--000000000000d411a6059d4e2c58-- From nobody Wed Jan 29 15:36:14 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 8530512004E for ; Wed, 29 Jan 2020 15:36:12 -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, 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 DaMtfRus_Ca1 for ; Wed, 29 Jan 2020 15:36:09 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 F2D7F12003F for ; Wed, 29 Jan 2020 15:36:08 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id k6so1168206qki.5 for ; Wed, 29 Jan 2020 15:36:08 -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=ke9vbW6DGIqqIpaC2DT/q/6CLy10vdw+6yHk+7Z5X7E=; b=TE3uUeHmHtTQZrXrkkOeyYBAx59l9j9aYNIyU0cGAXceBi/O1fDFympglV8fnS7S/Z xn1/tmQGLPWH522BYaOW78PB4Hpk7fsqlbHI5oZnRiSaJXeelpSsMJVedOThyaZ7BqDM g1ex2YEfGEtcrmVL33bnb9Kao0aRGSayeCqSY3NqZgK/3Lvm3gZNm5quAB6x8XR/ieb2 tvqZn0UTH5F8X52XhDlZs6Kgg8UO29I1ctR4042R9EngoXS1G/mJXBwEMVuFeBn56JFi pBKsFqEwsBa7Q40Cr5cXRTLGI9WtVYVbZfJAeY4H9LDp+AxVbl4SBBfRJPEdiT4FxDHV KP/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ke9vbW6DGIqqIpaC2DT/q/6CLy10vdw+6yHk+7Z5X7E=; b=SM92AUR2j9QthXG2JSPZA6rRrmtPuAcZWnuXPZTNwuWP8y4T2CDj0NX0b6JMq7CJZu KpX4gY1H+98EG+wuN4mSp2FzyLGCH7JyAaNpKr9xfX+V/LMzxUStOp0ruBKXfZFWVMO+ Yb7in9USSm3GZJ7SbHRG2CaVSpItr7YrBQuMtskCA44gDa+X01++6pCC/opwN/M135Km /inJNffUOUyzAyXclw3I3QjIYxgGFo6o1O0fHchAmOyIet55yYynDC5/HDMcHFoWSPko 4kj/TovZUNT93PuTUrZfcbRUMBu1nXX2pC/rG96JwTOJzKo87xHm0/8k1mwumbKfXkBq jYag== X-Gm-Message-State: APjAAAXeY1HPQ+PvVGgzmLZW8u4hbyhHjTCaAGZhVdW047zSjHcm/e4y MV/1wp+bXpqUyMRQlwlWcfiGws6NefPoPnS2X2Z8pL3rbVC4nQ== X-Google-Smtp-Source: APXvYqxKy/GADJxXEZoYHGrX+6VzWw9CL05TRUgz0FemJo47JMCDnH0Y4lzGvorwcqljZ1ndQRDGDZCGENI9+DKy9Yo= X-Received: by 2002:a05:620a:102e:: with SMTP id a14mr2398758qkk.159.1580340967849; Wed, 29 Jan 2020 15:36:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 29 Jan 2020 18:35:43 -0500 Message-ID: To: Nick Sullivan Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000000351b5059d4fce2c" Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 29 Jan 2020 23:36:13 -0000 --0000000000000351b5059d4fce2c Content-Type: text/plain; charset="UTF-8" Couple of additional notes: #247 - Welcome confirmation and key derivation This turned out to be obsolete, so I just closed it. #246 - Bugfixes in ClientInitKey, Commit, and Welcome This was mostly obsolete, so I refactored it to fix one typo and add an extension for an application-provided CIK ID. Then merged. #281 - Extend the epoch with a commit hash Thanks in part to some vigorous discussion at the interim, I've gotten over my ardor for forking and closed this PR :) I still think it will be desirable to be able to have nonlinear history, but I also think it requires some further analysis, and can be done as an extension. As Brendan noted on the call, #287 depends on #286 and #286, so we should probably merge those first... #285 - Get rid of ignored proposals. I had added "ignored" to the Commit message to allow the Committer to indicate Proposals that they had received, but was not committing. Brendan makes a plausible case in the PR that this distinction is not worthwhile, and this cleans it up. Please speak up now if you have a concern / objection to merging this PR. #286 - Editorial: Unclear that Commits always include an Update/refreshes the CIK for the committer. I think this is ready to merge, with one minor clarification. If I don't hear objections by Monday, I'll go ahead and commit #285, #286, and #287. --Richard On Wed, Jan 29, 2020 at 4:39 PM Nick Sullivan wrote: > MLSWG, > > Draft minutes from the productive first virtual interim posted below. If > you find an issue, submit a PR to Github: > > https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurring/01-29-2020.md > > Nick & Sean > > >>> > Attendees: > Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan > McMillion, Nick Sullivan > > #247 - Welcome confirmation and key derivation > * Fixes bugs RLB found in the last draft while implementing > * OK to merge after rebase / conflict resolution > > #246 - Bugfixes in ClientInitKey, Commit, and Welcome > * Derives the Welcome encryption key instead of generating fresh > * ... under the general theory about not requiring freshness when not > necessary > * OK to merge after rebase / conflict resolution > > #283 - Use the same ratchet for Handshake and Application keys > * There's no point to FS for Proposals because clients have to cache the > plaintext anyway > * Given that, the "flat derivation" approach should be fine > * We should have separate keys per sender to it easier to avoid nonce > collisions > * RLB and RR to decide whether we should derive nonces on a hash ratchet > or just use a counter > > #287 - Switch to signing strategy using one signature per leaf. > * There was agreement among those on the call to proceed with this > strategy (tree-hash-covers-parent-hash) > * ... given the deniability concerns and unclear benefit of the > alternative (parent-hash-covers-tree-hash) > * If further considerations come to light from analysis, we can revisit > later > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000000351b5059d4fce2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Couple of additional notes:

#247 - Welcome confirmation and key derivation
T= his turned out to be obsolete, so I just closed it.

#246 - Bugfixes in ClientInitKey, Commit, and Welcome
This was = mostly obsolete, so I refactored it to fix one typo and add an extension fo= r an application-provided CIK ID.=C2=A0 Then merged.

#281 - Extend the epoch with a commit hash
Thanks in part to s= ome vigorous discussion at the interim, I've gotten over my ardor for f= orking and closed this PR :)=C2=A0 I still think it will be desirable to be= able to have nonlinear history, but I also think it requires some further = analysis, and can be done as an extension.

As Bren= dan noted on the call, #287 depends on #286 and #286, so we should probably= merge those first...

#285 - Get rid of ignored pr= oposals.
I had added "ignored" to the Commit message to= allow the Committer to indicate Proposals that they had received, but was = not committing.=C2=A0 Brendan makes a plausible case in the PR that this di= stinction is not worthwhile, and this cleans it up.=C2=A0 Please speak up n= ow if you have a concern / objection to merging this PR.

#286 - Editorial: Unclear that Commits always include an Update/refr= eshes the CIK for the committer.
I think this is ready to merge, = with one minor clarification.

If I don't hear = objections by Monday, I'll go ahead and commit #285, #286, and #287.

--Richard


On Wed, Jan 29, 20= 20 at 4:39 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLSWG,<= /div>

Draft minutes from the productive first virtual in= terim posted below. If you find an issue, submit a PR to Github:

Nick & Sean

>>>
Attendees:
Joel Alwen, Richard Barnes, Raphael Robert, Bri= tta Hale, Brendan McMillion, Nick Sullivan

#247 - Welco= me confirmation and key derivation
* Fixes bugs RLB found in the last dr= aft while implementing
* OK to merge after rebase / conflict resolution<= br>
#246 - Bugfixes in ClientInitKey, Commit, and Welcome
* Derives t= he Welcome encryption key instead of generating fresh
* ... under the ge= neral theory about not requiring freshness when not necessary
* OK to me= rge after rebase / conflict resolution

#283 - Use the same ratchet f= or Handshake and Application keys
* There's no point to FS for Propo= sals because clients have to cache the plaintext anyway
* Given that, th= e "flat derivation" approach should be fine
* We should have s= eparate keys per sender to it easier to avoid nonce collisions
* RLB and= RR to decide whether we should derive nonces on a hash ratchet or just use= a counter

#287 - Switch to signing strategy using one signature per= leaf.
* There was agreement among those on the call to proceed with thi= s strategy (tree-hash-covers-parent-hash)
* ... given the deniability co= ncerns and unclear benefit of the alternative (parent-hash-covers-tree-hash= )
* If further considerations come to light from analysis, we can revisi= t later
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000000351b5059d4fce2c-- From nobody Wed Jan 29 15:49:01 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 6B34C12003F for ; Wed, 29 Jan 2020 15:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Si2uwmoOAzW for ; Wed, 29 Jan 2020 15:48:57 -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 6EF0512003E for ; Wed, 29 Jan 2020 15:48:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,379,1574118000"; d="scan'208";a="337455118" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.49]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 30 Jan 2020 00:48:45 +0100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Thu, 30 Jan 2020 00:48:44 +0100 Message-Id: <003BB7AB-2DA7-40DF-BD3B-D8E199BC49E9@inria.fr> References: Cc: Nick Sullivan , Messaging Layer Security WG In-Reply-To: To: Richard Barnes X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 29 Jan 2020 23:48:59 -0000 > #285 - Get rid of ignored proposals. > I had added "ignored" to the Commit message to allow the Committer to indi= cate Proposals that they had received, but was not committing. Brendan make= s a plausible case in the PR that this distinction is not worthwhile, and th= is cleans it up. Please speak up now if you have a concern / objection to m= erging this PR. I am obviously against allowing a network attacker to arbitrarily truncate t= he proposals from someone. The explicit acknowledgement of ignored proposals= lets the sender of the proposal know that the committer actually received, p= rocessed and discarded the proposal. This is obviously way better that not k= nowing if the proposal even reached the committer.= From nobody Thu Jan 30 06:44:10 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 A6B3D120120 for ; Thu, 30 Jan 2020 06:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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] 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 2797Gp0G22HB for ; Thu, 30 Jan 2020 06:44:06 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 932181200FE for ; Thu, 30 Jan 2020 06:44:06 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id d18so2599220qtj.10 for ; Thu, 30 Jan 2020 06:44:06 -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=bgtfqERGX5hp+fXUh1XHUxRpbbIKnrnL+3xZ0AA4VbM=; b=DOY1hr4lpat4MZZPzOtdDQiDVIp3okB/HrxgzJ9PN01a5x0APYzseeFG1uxneZTz+E RLHzrYpCMnv9tdFKu42kiOVeQJJCwDtrJzDekYAQh6d/IWk8w85QdS68M3zYk3Rcl4q2 0GzTGBFeXfgO0BZL5lOMzD3b99G3dHVZaaV8FhuTccIPOLhG7zUUrrMhbFJzoLftsPjv DdBUAdlOUsDocCnNV9E9G5vpPYOH3hN1LDrGnUc+HO0ydgmrTKWVhYo5L1+4AUhPPf+p OrOj2VeHLxZYPH7IokXSWAnrAhLv0J0oDTVWx3Lf+psBsEedDKVAuLJ1Pd73n7h9xtIV SRVA== 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=bgtfqERGX5hp+fXUh1XHUxRpbbIKnrnL+3xZ0AA4VbM=; b=l5BlvQ5P5GyDH/yuJirdEbde4BUvjEDT2H8nL077wsFS/B5MaAR0dI807whlj+85er CAGcQ8LMeu9L2c9HYf4Ozx0Xp6wynpX7z0ba0eZeEaVe9fJRBHc8OyZH06iTIAHu08+0 cI2btfG9ZZt0xoEs8u7CHUTmJHBrc282wkC7v2/HEj5w+8y68wKzkTX7TFkO+nwg0b2R YeoBWfcNO9y4XUx4efwp3I5+acX75MXMW+Plb8GU5YUs8mKA9w8NuyFfnsja7n7fn6hA swVt/dQo2hmCToe1efwk59ALqYaSsNGmxkaLUQ3s58iSHCx/hl/i1ZH/+JU95N6loQvw hORw== X-Gm-Message-State: APjAAAX0u8X53zOFkBdNt2Q+RuwFW23pgSN7T2Qvu1Znm+qutwcxGpXU +DxtkDdTWlBuZoKi99D0Lp6W2jdnKRuxorOQiu92gg== X-Google-Smtp-Source: APXvYqxx1fSlmTNdkVRVKFAF7kFhJBdGdWtwPVWnFgWZFLLIUfrT2ku5fTxvgusMMmui3YFJ1AS72oM6/jNeFfT123Q= X-Received: by 2002:ac8:4505:: with SMTP id q5mr2879884qtn.84.1580395445510; Thu, 30 Jan 2020 06:44:05 -0800 (PST) MIME-Version: 1.0 References: <003BB7AB-2DA7-40DF-BD3B-D8E199BC49E9@inria.fr> In-Reply-To: <003BB7AB-2DA7-40DF-BD3B-D8E199BC49E9@inria.fr> From: Richard Barnes Date: Thu, 30 Jan 2020 09:43:38 -0500 Message-ID: To: Benjamin Beurdouche Cc: Nick Sullivan , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000227777059d5c7ddd" Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 30 Jan 2020 14:44:08 -0000 --000000000000227777059d5c7ddd Content-Type: text/plain; charset="UTF-8" On Wed, Jan 29, 2020 at 6:48 PM Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > > > #285 - Get rid of ignored proposals. > > I had added "ignored" to the Commit message to allow the Committer to > indicate Proposals that they had received, but was not committing. Brendan > makes a plausible case in the PR that this distinction is not worthwhile, > and this cleans it up. Please speak up now if you have a concern / > objection to merging this PR. > > I am obviously against allowing a network attacker to arbitrarily truncate > the proposals from someone. The explicit acknowledgement of ignored > proposals lets the sender of the proposal know that the committer actually > received, processed and discarded the proposal. This is obviously way > better that not knowing if the proposal even reached the committer. > Note that the current proposal ACKs all "valid" proposals, since the Committer MUST include all valid proposals in the commit. The only thing that are omitted are proposals that would have no effect on the final group state. So the attacker cannot arbitrarily suppress proposals without being noticed. For example, an otherwise valid Add or Remove will never be omitted, so if an endpoint sent an Add/Remove and it didn't end up in the Commit, then he knows it was not received by the committer. AFAICT the only interesting ambiguity arises when there are two Updates, in which case the current spec doesn't specify which of the two should be selected and which invalidated. In such a situation, with the current proposal, if you send two Updates and see the earlier one in the Commit, you don't know if the later one didn't arrive or if the committer just didn't choose it. But this can be easily resolved by specifying that the committer always chooses the Update with the highest generation for the sender, so that if a Commit arrives that includes an update with a lower generation than the highest you sent, then you know the later ones weren't received. In other words, if we make that fix, the only cases where you don't get an ACK are the cases where the proposal wouldn't affect the protocol anyway. Namely, Updates that are overwritten by another Update or a Remove. So the protocol ACKs everything that is meaningful to the protocol. (Brendan also makes the practical point in the PR that it doesn't matter for client behavior whether a missing proposal was received or not -- either way, it needs to retransmit to get the job done.) The best argument I can imagine for keeping "ignored" is extensibility -- the analysis of whether something affects the protocol state might not be so simple with some future type of Proposal. But I'm having trouble thinking of any example where this would be the case. Could you live with something like the following? 1. Resolve the above-noted ambiguity about multiple Updates for the same leaf 2. State explicitly that the only Proposals that may be omitted from a Commit are: - Invalid proposals (e.g., because of a bad signature, parsing error, reference to a non-existent leaf) - Proposals whose effect on the tree is overwritten by another proposal, which at this point includes only: - Updates for a leaf prior to the latest Update received by the committer - Updates for a leaf for which there is a Remove in the epoch ISTM that that ensures that a Proposal is ACK'ed iff it matters to the protocol. --RLB --000000000000227777059d5c7ddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 29, 2020 at 6:48 PM Benjamin = Beurdouche <benjamin.beu= rdouche@inria.fr> wrote:

> #285 - Get rid of ignored proposals.
> I had added "ignored" to the Commit message to allow the Com= mitter to indicate Proposals that they had received, but was not committing= .=C2=A0 Brendan makes a plausible case in the PR that this distinction is n= ot worthwhile, and this cleans it up.=C2=A0 Please speak up now if you have= a concern / objection to merging this PR.

I am obviously against allowing a network attacker to arbitrarily truncate = the proposals from someone. The explicit acknowledgement of ignored proposa= ls lets the sender of the proposal know that the committer actually receive= d, processed and discarded the proposal. This is obviously way better that = not knowing if the proposal even reached the committer.

Note that the current proposal ACKs all "valid" = proposals, since the Committer MUST include all valid proposals in the comm= it.=C2=A0 The only thing that are omitted are proposals that would have no = effect on the final group state.=C2=A0 So the attacker cannot arbitrarily s= uppress proposals without being noticed.=C2=A0 For example, an otherwise va= lid Add or Remove will never be omitted, so if an endpoint sent an Add/Remo= ve and it didn't end up in the Commit, then he knows it was not receive= d by the committer.

AFAICT the only interestin= g ambiguity arises when there are two Updates, in which case the current sp= ec doesn't specify which of the two should be selected and which invali= dated.=C2=A0 In such a situation, with the current proposal, if you send tw= o Updates and see the earlier one in the Commit, you don't know if the = later one didn't arrive or if the committer just didn't choose it.= =C2=A0 But this can be easily resolved by specifying that the committer alw= ays chooses the Update with the highest generation for the sender, so that = if a Commit arrives that includes an update with a lower generation than th= e highest you sent, then you know the later ones weren't received.
<= /div>

In other words, if we make that fix, the only case= s where you don't get an ACK are the cases where the proposal wouldn= 9;t affect the protocol anyway.=C2=A0 Namely, Updates that are overwritten = by another Update or a Remove.=C2=A0 So the protocol ACKs everything that i= s meaningful to the protocol.

(Brendan also makes = the practical point in the PR that it doesn't matter for client behavio= r whether a missing proposal was received or not -- either way, it needs to= retransmit to get the job done.)

The best arg= ument I can imagine for keeping "ignored" is extensibility -- the= analysis of whether something affects the protocol state might not be so s= imple with some future type of Proposal.=C2=A0 But I'm having trouble t= hinking of any example where this would be the case.

Could you live with something like the following?

1. Resolve the above-noted ambiguity about multiple Updates for the same= leaf
2. State explicitly that the only Proposals that may be omi= tted from a Commit are:
=C2=A0 - Invalid proposals (e.g., bec= ause of a bad signature, parsing error, reference to a non-existent leaf)
=C2=A0 - Proposals whose effect on the tree is overwritten by = another proposal, which at this point includes only:
=C2=A0= =C2=A0=C2=A0 - Updates for a leaf prior to the latest Update received by th= e committer
=C2=A0=C2=A0=C2=A0 - Updates for a leaf for which= there is a Remove in the epoch

ISTM that that= ensures that a Proposal is ACK'ed iff it matters to the protocol.
<= /div>

--RLB
--000000000000227777059d5c7ddd-- From nobody Thu Jan 30 11:45:33 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 39D2D12013D for ; Thu, 30 Jan 2020 11:45:32 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 uLFNS4jd4Y-G for ; Thu, 30 Jan 2020 11:45:30 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 36DAD12008F for ; Thu, 30 Jan 2020 11:45:30 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id n8so2075414qvg.11 for ; Thu, 30 Jan 2020 11:45:30 -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=8Xw9VFVbkQudtz+8j1tZo3sGXs7JlJVVDFNoqgDfTBk=; b=XzqYfbaOk9s2UwzsO0GK9uuEZ2GTVzbWCxVge51pw3cnaTx7IkCe4TIi4i2KKfptL6 Z5W+rLKhr/F5dswSwuYIGY4Q/ulFf4HOE9N5AtrzI6M7MmgBYZcVZha/whQntc3Wo52I kcIiKSbMvu3IU3acsX57WS3i7iKMRxKDtqM5A= 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=8Xw9VFVbkQudtz+8j1tZo3sGXs7JlJVVDFNoqgDfTBk=; b=n5YbA6rfDGnk/uXl3ZF11USpVKX65PikTjLPLvRQ04nhP/yeas/5rkLRM/v9qxogbh GG/WpoNzau1OSg697YPwPRc8o5v4bNh8IBw4PnkiDkCXW9nupaUcNkm+dUDIqfOAvxW7 2Lgw2BfVVFkNfp4sCMOtF5WqH5GeAQ2zs4w7fjJHH2hV4tV/ihuh7CQCQyaNG+SedI4n 2QsexovTG2hKWLhtM5r3+nrbUcsA6qlQVppdDul1q/3YUgf6WzzJ0G6raK+1cuwAqDVq 7aZapkd8J8T7TBo3N/zIN6hoOwj2jrSiMYxFzokDGVzx/srlOq8nxKT4j18cF6GlTlP8 0Jvg== X-Gm-Message-State: APjAAAV0xHfHLx5Kcnd3M8/XrorWJUAeDGRKtGslU576YmbFRe0EgC0T SzyIEmahCK8Cby71q4nbB7c4KJ0RYdOjvGRF/ivUJhZIaEsASQ== X-Google-Smtp-Source: APXvYqwrCtn6xQPJ7DkONLHkW63wlWaEBCGJ4JHt7bf8pvItsjkD9aTb+17m7KIMjoua3FS4BHLswDmetNXaeWAZv/k= X-Received: by 2002:a0c:f513:: with SMTP id j19mr6398507qvm.206.1580413528882; Thu, 30 Jan 2020 11:45:28 -0800 (PST) MIME-Version: 1.0 From: Brendan McMillion Date: Thu, 30 Jan 2020 11:45:18 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000fcec9e059d60b29f" Archived-At: Subject: [MLS] Switch to signing strategy using one signature per leaf. 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, 30 Jan 2020 19:45:32 -0000 --000000000000fcec9e059d60b29f Content-Type: text/plain; charset="UTF-8" Hello mls@ As per the minutes from the last virtual interim, it looks like there's consensus around merging PR #287, "Switch to signing strategy using one signature per leaf." Before that happens, I wanted to write a message to the list formally introducing the change. A while ago, we started having the members of a group sign the nodes in the ratchet tree, along with a hash of the node's subtree, as the nodes were changed (through Update/Commit messages). The purpose of this was to authenticate the tree when it's sent in a Welcome message. Without authentication, the member that sends the Welcome message could falsify the tree and add themselves in subtrees they don't appear to be in. This attack makes it impossible for the new member to reasonably remove the welcomer from the group. The proposed change in my PR switches from a scheme where every node and a subtree hash is signed, to a scheme where each leaf and a "path hash" is signed. The path hash of a node is defined as the hash of all the node's ancestors. Path hashes work differently from the tree hashes we currently have in the spec, in that they go up instead of down. There are two main benefits of this scheme: 1. It reduces the number of signatures that need to be verified by a factor of 2. 2. It's compatible with approaches for deniability, since the information that each member is signing doesn't bind them to the other members of the group. --000000000000fcec9e059d60b29f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello mls@

As per the minute= s from the last virtual interim, it looks like there's consensus around= merging PR #287, "Switch to signing strategy using one signature per leaf."= ; Before that happens, I wanted to write a message to the list formally int= roducing the change.

A while ago, we started having the = members of a group sign the nodes in the ratchet tree, along with a hash of= the node's subtree, as the nodes were changed (through Update/Commit m= essages). The purpose of this was to authenticate the tree when it's se= nt in a Welcome message.

Without authentication, the mem= ber that sends the Welcome message could falsify the tree and add themselve= s in subtrees they don't appear to be in. This attack makes it impossib= le for the new member to reasonably remove the welcomer from the group.
=

The proposed change in my PR switches from= a scheme where every node and a subtree hash is signed, to a scheme where = each leaf and a "path hash" is signed. The path hash of a node is= defined as the hash of all the node's ancestors. Path hashes work diff= erently from the tree hashes we currently have in the spec, in that they go= up instead of down.

There are two main benefits o= f this scheme:

1. It reduces the number of signatu= res that need to be verified by a factor of 2.

2. = It's compatible with approaches for deniability, since the information = that each member is signing doesn't bind them to the other members of t= he group.
--000000000000fcec9e059d60b29f--