Re: [MLS] AEAD data in messages

Jon Callas <jon@callas.org> Tue, 13 August 2019 22:03 UTC

Return-Path: <jon@callas.org>
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 DE6E01208C2 for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 15:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=callas.org
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 Rk3CfdaK4Lpg for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 15:03:37 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 601511208E6 for <mls@ietf.org>; Tue, 13 Aug 2019 15:03:37 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id gn20so576798plb.2 for <mls@ietf.org>; Tue, 13 Aug 2019 15:03:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QY/06HHj1MnLVpwdyyICxSlwuOCXSyvDH28p1KmSdTY=; b=HcIu3fARartHMMpWQoMN58NjeiCaSxJAJuJ/QNawmpEO6Nn6oiHfiJed1SWI3xox8i PXVo6eCEkH5VjdZqKLhwfIqQmc/lDUH/6Qg/OpGakiEQxdExJVLteodHdmZ/6GvxMRbL 4ggyvc7ihOiz1VxCaUGt4+h0nnUf1zSS91xC+9yqqvhciezsx9H6Cyx1NcGtu7LQMD0S Rfsoe0GKZzePsgIV6Wsvk+gL2V4efx7ZOpZ2QO2kG3dPot3Fxu6uC+Cg6gkLsMsiT07a 4OcuR7Up+LUFfRaoMrpJrCTCOzT66IzXYLYn+JrKMKijRCmOxeF7myeLqjfkCuNc8Ara nmpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QY/06HHj1MnLVpwdyyICxSlwuOCXSyvDH28p1KmSdTY=; b=OJ82dQOIi6ivzufaXzYEoDxlXyqxEHheISQXnthMvgMqJLFu2oV0Re/n+CbSBp+mdY h/rtIElWQlabhxV0vtQaoRrdw2yOuwkeWZesoLzxqfxEMjea/PaIJmEt5cIVryOrJ5KD Y/i1pheK9nUtvjLAqfHnGroicYzgyc+3HXkgE/bn2JpA48vvp+Tp88VMZrryzydPHFLq 0F1eFM5udafr4luYaMBSuhffMswfGaocQiLF9OfYzzPz9wlPQ5M9ZEzEMCTCTkbnYKnN nmtlkXcAg7LzrJeXd042xEu7TpFHIxSEz9MASbErONUF542NzAN46QWvaZrTcbHXTk/b vOkg==
X-Gm-Message-State: APjAAAUwNj8JPzF4ijkz19WbhXYOS6SQWrIdJVCx8suTvPVrcbAErzX6 l7yBjN0pr4D6gm4gohSSPOLR4A==
X-Google-Smtp-Source: APXvYqy+miq2vyzxf17tFkN7R6N2KA1JOMBHabkfHSUFz1z5fD20edG/tLyKaCdASDPB/N9OGF2BPw==
X-Received: by 2002:a17:902:20ec:: with SMTP id v41mr19108264plg.117.1565733816712; Tue, 13 Aug 2019 15:03:36 -0700 (PDT)
Received: from [10.125.12.150] (67-207-120-150.static.wiline.com. [67.207.120.150]) by smtp.gmail.com with ESMTPSA id m7sm3833124pfb.99.2019.08.13.15.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 15:03:35 -0700 (PDT)
From: Jon Callas <jon@callas.org>
Message-Id: <BC3D8868-1498-4455-8C52-9EC712A03058@callas.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1AFFAA80-6D4F-40B8-AB52-06575D622D67"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 13 Aug 2019 15:03:34 -0700
In-Reply-To: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com>
Cc: Jon Callas <jon@callas.org>, mls@ietf.org, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
To: Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>
References: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/pPxULaZ2oZ1Yz-S_XiIWsqsgQVw>
Subject: Re: [MLS] AEAD data in messages
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: Tue, 13 Aug 2019 22:03:40 -0000


> On Aug 12, 2019, at 4:15 PM, Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>; wrote:
> 
> Hello!
> I was wondering if you considered allowing additional plaintext but authenticated data in MLS messages.

I have a small raised eyebrow about this. Similar to rlb's comment, it's not hard.

My primary concern is that any AAD in the message is ripe for putting in things that are side-channel or traffic analysis leaks. I have a secondary concern that if one uses this to talk to the delivery service, it's unauthenticated from the service's viewpoint, and consequently creates an opportunity for an attacker to fuzz the delivery service. Moreover that attacker could be a legitimate user of the service.

I note that you said, "Delivery service is often TLS encrypted so client-server connection should be secure" in follow-on discussion, but that's in my opinion a reason *not* to have this feature. That's either a layering violation or you could achieve the same effect by just sending an unauthenticated message to the service that is protected by TLS. By putting a server message in the AAD of an AEAD message, 

> 
> While I can't think of immediate, compelling use cases right now,

That strikes me as a reason *not* to do it, but again, along with rlb, I'm willing to look at a proposal. Note that my concerns here suggest things you should address in that proposal.

> I am wondering if such extensibility wouldn't be desired. For example, in encrypted video calls, resolution, framerate, or audio volume can be put in plaintext so that the selective forwarding unit can decide which streams to forward to the group members (and the recipient also uses this data)..

Here's a sample attack. In this, Alice and Bob are communicating over the service and Harry the Hacker has compromised the router nearest Alice and thus can see or modify all messages. Harry modifies one of Alice's messages, changing the volume field to maximum volume. The server acts on the changed volume, but Bob drops the message, because the MAC fails. If the message gets retransmitted, Harry doesn't change the volume. Alice and Bob likely see the volume of the call going to max for no readily understandable reason. As you note, using TLS is a quick mitigation.

Another attack uses Gary the Griefer instead of Harry. Gary is an authenticated used of the service and is in a session with Alice and Bob. Gary does exactly what Harry did above -- send a message that the server will act on, setting the volume to max -- but knows that this message will dropped by Alice and Bob.

I believe that if someone wants to send a command to the service, then it shouldn't be piggybacked inside the normal messages, but that there needs to be a separate edge-to-service key and command set.

> 
> Here are some use-cases for MLS that I can think of:
> * sending a 'sending device identifier' in case if delivery service can't differentiate different user devices from each other. 

This is a traffic-analysis data leak.

> * sending 'message type' that server can act upon. For example, delivery report sent by the recipient to the sender, which also acts as an ACK to the server that the message was persisted.

Again, this should be done under the aegis of an edge-to-service key.

> * authenticating message id (but make it visible to server to avoid redelivery),

That's also an information leak.

> * other use cases that I can't think of right now.
> 

I have one more that's perhaps at least mildly paranoid and perhaps not entirely fair.

* sending information needed for "exceptional access" such as the GCHQ Ghost User proposal. This could put in trap/trace data, copies of the messages encrypted to access keys, etc. 

That's not fair because if we presume government-compelled software mods, they could mandate a lot of things. However, this provides a mechanism that could enable a single gimmicked client to undermine the security of the whole system transparently. This would really be true of the plaintext AAD was typically ignored by the client. Preventing this is thorny, because it would require defining what the syntax of the AAD is, and mandating some dramatic failure if unknown AAD is present.

Despite this, I'd love to see a proposal. It could be useful. It could also be a major flaw, and this is why I would like to see a real use case as well as mitigations against abuse in the proposal.

	Jon