Re: [MLS] Stupidest possible message protection

Richard Barnes <rlb@ipv.sx> Sun, 02 December 2018 22:51 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693D130DCC for <mls@ietfa.amsl.com>; Sun, 2 Dec 2018 14:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level:
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKwKMVu4rezP for <mls@ietfa.amsl.com>; Sun, 2 Dec 2018 14:51:45 -0800 (PST)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0821130DC7 for <mls@ietf.org>; Sun, 2 Dec 2018 14:51:44 -0800 (PST)
Received: by mail-oi1-x22b.google.com with SMTP id b141so9281195oii.12 for <mls@ietf.org>; Sun, 02 Dec 2018 14:51:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZFQ1it9b+REPxppz3JvaQsIxZyhyyA68dAvAwgDVhOc=; b=Pxa318aWKW8WzLtIC4ztgTdiAaR1pTZaoiJLaKr+KvLjYYJLuTB2/QIZqfrGmcOzTa Nw0dUNjjmtAIOxYPwsQHzkdhFpUzxXKkA7NDJe0//n1tqml/f48Ioof3SvmyCfEskJK/ 637GwewOop90MQmbskEz0juCnxB2pGKTyuuP7VY1cgUDQl3UyoZSb95oiReHKjPw6rSa 2evnrlOodjqUfXfXeMI47LYRnzDLHqMIPESQ7wlynybBn/7G9XvEjDXN0OAwE+v1M1XJ +8b1ExikQpqfTTVKwAe2D7GY3wNF5XN1nwCWlKb7lWav44rpzMD5Qz3fDyoM+qxJWPoy qAkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZFQ1it9b+REPxppz3JvaQsIxZyhyyA68dAvAwgDVhOc=; b=UYrZ53+xnDPcgcjthy0PvJui3nu84+7J9VWeo+m+ieBjY5QzVn5AMRavzQrPs/TWLQ +2BV/w4dpxb3x2evAtL0ERhPVDQeEt8Jx26+kixkoLqXvKzrTTFZ8W4quykE8fxoHUpw +wU+t0lNVphiRdpktHMEA21krTrpbXR448KBpupPBnb7TtDKaiLr649VMiAPradHU3So 7vqt2IJdJayFNobML9DGSIVLuKuWafQxmsywyP+LV7CKEgjMpqvXZQGYhigkbFzMscz0 KFcw9yYRwC4EAjn8p0WMXeg07rTIuDCjKuvBSjRU88QN4XY9omUWC8JjLeyYDIYL/TZg hWLw==
X-Gm-Message-State: AA+aEWZjdc4GeWUaHrLsOVDIqCwxKSD4g1z7CW0hU0ZkXVFl+/CeRv4P 9RwcQu9Hf/mmx+8G598Io59OYD91ry4JG0JpBxZCNw==
X-Google-Smtp-Source: AFSGD/UgfAD7liKkGcuxs7Roy3L4kRUK8Q/yhFzGlhllZuKlrJdwJWS/D8+W4qUQCX4YLnclBn4BNEDyj4mwf/dLkIU=
X-Received: by 2002:a54:4f1d:: with SMTP id e29mr8143132oiy.310.1543791104021; Sun, 02 Dec 2018 14:51:44 -0800 (PST)
MIME-Version: 1.0
References: <CAL02cgTjD==YgS848sBWEGrBBkNMAtbUXJuV6RrDmak_+Mu6fw@mail.gmail.com> <CACsn0ckND-uBNwcfQTZrY+7sZr6OWqkA1_z71Jb7PHYz7yh6dg@mail.gmail.com>
In-Reply-To: <CACsn0ckND-uBNwcfQTZrY+7sZr6OWqkA1_z71Jb7PHYz7yh6dg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Sun, 02 Dec 2018 17:51:33 -0500
Message-ID: <CAL02cgSfqV-r3kvJkdi0E7H44MMuYJTOux0xWNi0F55iCuwZ-A@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: mls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005ce7e1057c11e0b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/A10aHNm_Fg6G3sc7Kk6HMBZotgs>
Subject: Re: [MLS] Stupidest possible message protection
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Dec 2018 22:51:47 -0000

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.
>