Re: [MLS] Stupidest possible message protection

On Mon, Dec 3, 2018 at 3:01 AM Karthikeyan Bhargavan <
karthik.bhargavan@gmail.com> wrote:

> > One way to try to split this baby would be to try to evaluate what
> information the server needs in order to provide its assistance, and leave
> that unencrypted.  This solution would of course require that we convince
> ourselves that the unencrypted bits are actually not sensitive, and would
> entail a fair bit of complexity in the encryption system.
>
> Let me poke a bit more at this option. What minimal information do you
> think the server needs in order to provide its assistance?
>

If you take a look at Raphael's slides from the Bangkok meeting, there are
a couple of different types of assistance the server might provide.  Most
of these revolve around the linear-size pieces of group state: The (public
keys in the) tree and the roster.  The server could cache a copy of the
tree so that clients could download slices of it as needed.  Clients would
have to either trust the server to do this or arrange the hash in the
GroupState so that the slices could be verified.  That's where a lot of the
complexity comes from.

Arguably, there's no harm in exposing the tree, since it should just be all
random key material.  (Except in the case where you put a DH key from a
UserInitKey at a leaf, in which case it can be used to correlate.)
Exposing the roster is obviously problematic.  Maybe Raphael has some ideas
here.

--Richard

[1]
https://datatracker.ietf.org/meeting/103/materials/slides-103-mls-sessa-efficiency-00

>
> -Karthik
>
> >
> > Another, simpler, approach we could take is to punt the decision to the
> application.  We would define in the document two options:
> >
> > 1. Send Handshake messages in the clear
> > 2. Send Handshake messages encrypted as Application messages
> >
> > (And specify details like how you do Welcome+Add, how you disambiguate
> Handshake from other Application messages.)  But we would not specify which
> of those paths a given application would do.
> >
> > What do folks think about that idea?  Personally, I find it kind of
> appealing in its simplicity, though I acknowledge it adds another variable
> for interop testing / interop failure.  And if you want to make an MLS API,
> it's another switch to support.
> >
> > Cheers,
> > --RIchard
> >
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
>
>