Subject: [MLS] Test framework

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Jul 2018 19:08:20 -0400

In our overrun A.O.B. section today we had a topic, "interop test
framework".  Since we didn't get to it in the meeting, here are some
thoughts in writing:

The idea of interop testing is a little challenging for MLS, since we're
only defining a part of the system -- we don't have a specified transport,
for instance.  Instead, we just have message formats.  Given that focus,
I'd propose we agree on a standard "API" for MLS implementation to
implement, focused mainly on producing and consuming messages in the
standard formats.  This would allow us to build some standard tooling that
can pull messages from one implementation and feed it into another
implementation.

I don't think this needs to be an I-D / RFC, but it should probably be
something we can all collaborate on.  As a start, I've dropped an initial
API into GitHub gist (we can make a repo laster), based on the common API
implemented by my JS ART and TreeKEM code:

https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b2928a

Folks who are considering implementing, does this look roughly sensible?
Are there things that are missing?  It probably needs an encrypt/decrypt
for message protection, and some more accessors.

--Richard

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Thu, 19 Jul 2018 21:02:50 -0400

The parallel with the TLS 1.3 handshake maybe useful.
Although it was designed to be used only with TLS and its applications, it has not become useful to design a Handshake API that can be used by QUIC as well.
We should similarly define an API for MLS that can be used within messaging applications and publish test-vectors for this API.

-Karthik

> On 19 juil. 2018, at 19:08, Richard Barnes <[email-masked]> wrote:
> 
> In our overrun A.O.B. section today we had a topic, "interop test framework".  Since we didn't get to it in the meeting, here are some thoughts in writing:
> 
> The idea of interop testing is a little challenging for MLS, since we're only defining a part of the system -- we don't have a specified transport, for instance.  Instead, we just have message formats.  Given that focus, I'd propose we agree on a standard "API" for MLS implementation to implement, focused mainly on producing and consuming messages in the standard formats.  This would allow us to build some standard tooling that can pull messages from one implementation and feed it into another implementation.  
> 
> I don't think this needs to be an I-D / RFC, but it should probably be something we can all collaborate on.  As a start, I've dropped an initial API into GitHub gist (we can make a repo laster), based on the common API implemented by my JS ART and TreeKEM code:
> 
> https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b2928a <https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b2928a>
> 
> Folks who are considering implementing, does this look roughly sensible?  Are there things that are missing?  It probably needs an encrypt/decrypt for message protection, and some more accessors.
> 
> --Richard
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls