Re: [MLS] protections for MLS "handshake" messages

At IETF 103 we discussed the possibility of encrypting handshake messages and also the fact that this might hinder the caching of public keys of the tree (caching would alleviate the cost of adding new members/devices to a conversation).
I was wondering if we couldn't use a proxy re-encryption scheme to achieve both goals:
 - the proxy would be able to cache parts of the handshake messages, yet still not have access to the plaintext of handshake messages
 - the proxy would re-encrypt that data from epoch to epoch

The keys for the encryption would be derived through the key schedule (and therefore from the group secret). This means the keys inherit the FS and PCS guarantees of the group secret.
In typical proxy re-encryption schemes, Alice wants to share data with Bob and asks the proxy to re-encrypt the her ciphertext for Bob. In that scenario Alice only knows Bob's public key, but not his private key. This limitation is not applicable with handshake messages, as both private keys can be known and this might simplify things.

It would be interesting to hear from cryptographers about the feasibility of such a scheme as well as from folks who have successfully implemented similar schemes.

Raphael

> On 19 Jul 2018, at 18:45, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> In today's session, there seemed to be an open question that wasn't
> explicitly addressed, so i wanted to raise it on the list.
> 
> for lack of a better term, we're dividing MLS messages into
> "application" messages and "handshake" messages.  (i think we need
> a better term for "handshake", but i'll use it here for consistency with
> the current discussion)
> 
> I believe we should provide encrypted cover, and a mechanism for padding
> of handshake messages, not just for application messages.
> 
> We want encrypted cover because i'd like the DS not to be able see
> whether a given message is a handshake message or an application
> message.
> 
> and if it is a handshake message, i want to be able to make a handshake
> message that shows up for a group of K people to look the same to an
> observer as a handshake for a group of K+1 people (this motivates the
> request for padding.
> 
> I recognize that some of this might come into conflict with richard
> barnes' vision of a DS that stores a cache of messages from each
> participant in a given group for future replay -- so i think we need
> further dicsussion on it.
> 
>        --dkg
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls