IETF Logo Mail Archive

Re: [MLS] Stupidest possible message protection

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Mon, 03 December 2018 08:01 UTC

Return-Path: <karthik.bhargavan@gmail.com>
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 37C10128D68 for <mls@ietfa.amsl.com>; Mon, 3 Dec 2018 00:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T8FqLre2qbpP for <mls@ietfa.amsl.com>; Mon, 3 Dec 2018 00:01:30 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 42B74124C04 for <mls@ietf.org>; Mon, 3 Dec 2018 00:01:30 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id z18so4655920wmc.4 for <mls@ietf.org>; Mon, 03 Dec 2018 00:01:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OPb2e/Vh146F+5GHM55sExbW9gp5f6QbHq+uPiIMz0s=; b=VLPKBENNndXcdvHQROA/w9eN0/+G7p3zpPcnqiSiq9EgJwUkWc2/TQdaEcr/h9Gv8a wEFQbtKFrpEBqgNi/BhQcJcr+NTrTOnpq7a+CdnoN2fHasPyp3sD4N88Azh6DoS5Snkd 8W9yVUhbGJE6YpheWKuCDjY5IWA5EwYfpT4vOsKpyU90tbwBApiQW0MrrBGG1GANcPgG muSysGyBcaA7qKlOxBsz9DR+WfCogQS12Ib14dZxKgMaFQPQVXd09fE9jhrb6X6ACLq6 VsKRccLTy0CpdfchuyLROFdaKWeJVpINNnF38mn7Y+QN2tiThogE3xsqPKULfu048d8w 8PNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OPb2e/Vh146F+5GHM55sExbW9gp5f6QbHq+uPiIMz0s=; b=T2n2yEmJNwDqpAnn6iceSqR5bB1eQlOhv332GPw90PykiqyuPHKom+8Stro3QGanK2 ysefoFDu8a/zjQEfQ4wzXuDudXETDvlzrjyfJWO6N7qDyo8uY9MZc6s8+7pRsx6OloxT guRGS82OIxcDlZ4FdHJJ5iL2Vxx+BMayqEeDxylTp8f/lc3aXjeLfl58sWbdLFKL6/Xf kazoP9tNzvjpFi5+L4vp6OZvb0hNz1khDjJ7eyt8XLbQoHLgYox07n4jTbhIbtlV+a/B hrk8rogK+WUTPrO1LQ69f1ClkP/lTu0jGYMXTyOaJHVSCTz/IsuUouzg+bj0/+PymPVZ lF8g==
X-Gm-Message-State: AA+aEWbbstTji108wYbESUeKbwXlLEW4aP6wA3+wKApU4FhIIJA4a0De IKcRb+n2YkG+NW+PI+plxF4=
X-Google-Smtp-Source: AFSGD/XndA1I5Dair5Ne6asjse3tfHxa08i3PW/aW8ws8O+r0IoKDazkf8unRlK1klkGVUDjRWdi0g==
X-Received: by 2002:a7b:c8d7:: with SMTP id f23mr7042380wml.121.1543824088542; Mon, 03 Dec 2018 00:01:28 -0800 (PST)
Received: from wifi-pro-83-000.paris.inria.fr (wifi-pro-83-000.paris.inria.fr. [128.93.83.0]) by smtp.gmail.com with ESMTPSA id l3sm17310010wma.44.2018.12.03.00.01.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 00:01:27 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <CAL02cgTjD==YgS848sBWEGrBBkNMAtbUXJuV6RrDmak_+Mu6fw@mail.gmail.com>
Date: Mon, 03 Dec 2018 09:01:27 +0100
Cc: mls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6369845D-4139-4043-90F8-08AFAD4EE47B@gmail.com>
References: <CAL02cgTjD==YgS848sBWEGrBBkNMAtbUXJuV6RrDmak_+Mu6fw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/qybH_6WERK0kh2bK2qLXoi5lawI>
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: Mon, 03 Dec 2018 08:01:33 -0000

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

-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

v2.35.0 | Report a Bug | By Email | System Status