Re: [MLS] Malicious user segmenting the group

Hi Jon,

This is definitely an active issue.  See my message earlier today about
authentication / key confirmation.

There have been some discussions of ZKPs for this, but AFAIK, no workable
proposal has emerged.  The problem is that what you want to prove is that a
sequence of keys are the result of transforming a chain of hashes from hash
outputs to key pairs -- if you want to do a ZKP with a general hash
function, the ZKP is very expensive, and if you adapt the hash function to
have nicer proof properties, you lose some of the cryptographic properties
you would want.

My current thinking is that we should probably try to address this at the
protocol level.  In some of the pre-BoF discussions, we had talked about
doing some specification of ACK / NACK messages.  Now that at least some
endpoints can recognize a bad message, it seems like we could define a NACK
that says "that handshake message was invalid" and basically let endpoints
veto invalid messages.

If someone wants to come up with a concrete proposal, I would love to
discuss further.

--Richard

On Mon, Oct 22, 2018 at 1:37 PM Jon Toohill <jtoohill=
40google.com@dmarc.ietf.org> wrote:

> Hey MLS folks,
>
> I'm still skimming through the mailing list archives to get up to speed,
> so apologies if this has already been discussed & solved. I saw the
> following note in a recent version of the protocol draft:
>
> [[ OPEN ISSUE: It is not possible for the recipient of a handshake message
>> to verify that ratchet tree information in the message is accurate, because
>> each node can only compute the secret and private key for nodes in its
>> direct path. This creates the possibility that a malicious participant
>> could cause a denial of service by sending a handshake message with invalid
>> values for public keys in the ratchet tree. ]]
>>
>
> It seems like this could be solved by having the handshake message sender
> prove in zero knowledge (i.e. without revealing their secret or the parent
> secret) that they derived the parent public key correctly. ZK-SNARKs are
> one way of doing that, but my admittedly weak understanding is that
> generating proofs might be too computationally expensive for mobile
> devices. Does this seem like a worthwhile direction to investigate? Does
> anyone know of a more efficient construction that could be used in MLS?
>
> -Jon Toohill
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>