Subject: [MLS] Contribute as OTRv4 to MLS

From: Sofia <[email-masked]>
Date: Thu, 8 Nov 2018 14:09:36 -0200

Dear contributors to MLS,

During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4
specification and implementation during the PEARG session
(https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-slides-01).
During the Q/A we had some nice words from some of you (some people said that
it will be nice if the OTRv4 team could contribute with MLS) and, so, we'd like
to contribute to MLS and see how to work together! We have been looking at some
of the material of MLS shared during IETF 103 and we will like to start
contributing from it!

Best,
The OTRv4 team
--
Sofía Celi (aka cherenkov)
@claucece / @cherenkov_d
Cryptographic research and implementation at CAD: https://autonomia.digital/
EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Nov 2018 09:32:22 -0700

That's great news!

On 11/8/18 9:09 AM, Sofia wrote:
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 9 Nov 2018 09:06:11 +0700

Fantastic, glad to have you guys here.  One productive way to get involved
would be to read the draft protocol document [1] and send email to this
mailing list with your thoughts.

For the most part, there shouldn't be anything too surprising here.  It's
just standard DH ratchet + hash ratchet, but with the DH arranged in a
tree.  The one thing that might be surprising to you is that we do not
account for deniability at all in the current draft.  If deniability is
something that's important to you, it would be helpful to think about how
you could fit it in as an optional feature.

Thanks,
--Richard

[1] https://tools.ietf.org/html/draft-ietf-mls-protocol

On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre <[email-masked]>
wrote:

> > (
> https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-slides-01
> ).

---

From: nalini elkins <[email-masked]>
Date: Fri, 9 Nov 2018 09:41:34 +0700

> If deniability is something that's important to you, it would be helpful
to think about how you could fit it in as an optional feature.

Just to comment, there is a potential human rights issue (right to life)
with deniability.   Although extremely beneficial in a number of
circumstances, it is my understanding that deniability can also be used by
people such as terrorists to fight lawful subpoenas.

I wonder if that is of interest to this group.   Please correct me if my
understanding is wrong.  I very much wish to be wrong.

Nalini

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: Ian Goldberg <[email-masked]>
Date: Thu, 8 Nov 2018 22:18:34 -0500

> understanding is wrong.  I very much wish to be wrong.

I can't figure out what you mean by that.  Deniability (well, one form
of it anyway) is the property that the transcript of the protocol
messages does not imply the plaintext messages that were exchanged.
Another form is that it does not imply the participation of any
particular party.  (There are other more complex forms involving online
informants.)  Plaintext logs are deniable in these senses, since anyone
could easily forge them to say anything they like.  If we're talking
subpeonas, note that courts accept plaintext as evidence all the time;
the role of a deniable protocol is to prevent the protocol transcript
from *mathematically* implying the message contents or participation.
(While at the same time the protocol strongly authenticates the
participants and the message contents to those *in* the conversation.)
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo

---

From: Raphael Robert <[email-masked]>
Date: Sat, 10 Nov 2018 08:27:53 +0700

This is great news indeed! Sharing ideas about subjects like deniability or other open issues sounds very promising!

Raphael

> On 9 Nov 2018, at 09:06, Richard Barnes <[email-masked]> wrote:
> 
> Fantastic, glad to have you guys here.  One productive way to get involved would be to read the draft protocol document [1] and send email to this mailing list with your thoughts.
> 
> For the most part, there shouldn't be anything too surprising here.  It's just standard DH ratchet + hash ratchet, but with the DH arranged in a tree.  The one thing that might be surprising to you is that we do not account for deniability at all in the current draft.  If deniability is something that's important to you, it would be helpful to think about how you could fit it in as an optional feature.
> 
> Thanks,
> --Richard
> 
> [1] https://tools.ietf.org/html/draft-ietf-mls-protocol <https://tools.ietf.org/html/draft-ietf-mls-protocol>
> 
> 
> 
> On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:
> That's great news!
> 
> > (https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-slides-01 <https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-slides-01>).
> > Cryptographic research and implementation at CAD: https://autonomia.digital/ <https://autonomia.digital/>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> > 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>