Re: [MLS] Stupidest possible message protection

This seems like a neat approach; I agree that putting the bit into the
GroupState is a good idea.
As Watson says, this could be an opening for downgrade attacks, so we
should make sure that there's as little negotiation as possible about
the "encrypt handshake messages" bit. Having it just go in the group
state and requiring clients to know it seems fine, although there is the
case of an app which previously didn't encrypt handshake messages and
now wants to.
At a high level I support the idea.

k

On Sun, 2 Dec 2018, at 10:51 PM, Richard Barnes wrote:
> 
> 
> On Sun, Dec 2, 2018 at 17:31 Watson Ladd
> <watsonbladd@gmail.com> wrote:>> On Sun, Dec 2, 2018 at 2:25 PM Richard Barnes <rlb@ipv.sx> wrote:
>>  >
>>  > Hey all,
>>  >
>>  > As we discussed in Bangkok, there are trade-offs between
>>  > encrypting handshake messages and enabling the delivery service to
>>  > assist with scaling.>>  >
>>  > 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.>>  >
>>  > 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.>> 
>>  Doesn't the server need to agree with the client how to do this?
> 
> The server needs to be aware of it’s going to provide any assistance,
> yes.   But in principle, clients could choose to encrypt and the
> server would never know.  I think the more important question is
> whether clients all need to agree.> 
>> And
>>  what about downgrade attacks?
> 
> Seems like there are basically two choices: (1) don’t worry
> about it, let the application figure it out, or (2) include the
> “encryptHandshake” bit in the GroupState so that everyone
> agrees on it.> 
> I think (1) is probably sufficient, since I think most apps will pick
> one.  But (2) seems prudent.> 
> —Richard
> 
> 
>> 
>> >
>>  > Cheers,
>>  > --RIchard
>>  >
>>  >
>>  > _______________________________________________
>>  > MLS mailing list
>>  > MLS@ietf.org
>>  > https://www.ietf.org/mailman/listinfo/mls
>> 
>> 
>> 
>>  -- 
>>  "Man is born free, but everywhere he is in chains".
>>  --Rousseau.
> _________________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls