[Mls] Regarding Signatures

Nadim Kobeissi <nadim@symbolic.software> Mon, 05 February 2018 20:03 UTC

Return-Path: <nadim@symbolic.software>
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 E793E12D94B for <mls@ietfa.amsl.com>; Mon, 5 Feb 2018 12:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=oxdihKTr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k9glWO07
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 n4kLbT8rRwFv for <mls@ietfa.amsl.com>; Mon, 5 Feb 2018 12:03:23 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DACE127909 for <mls@ietf.org>; Mon, 5 Feb 2018 12:03:23 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9F07F20AE6 for <mls@ietf.org>; Mon, 5 Feb 2018 15:03:21 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 05 Feb 2018 15:03:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=7KFzWsElfRTlX4yx3zJo8nPbd3/I38wBlFdUIPASb 4k=; b=oxdihKTr6fNL3UxvqeL67D5V9AwmAu7CvGvpfxJp8SVkpiflEkUr4AUBU GlLHEaAqNTTAHc66o9aePSDgbDYZ5ZcYzFmsKcm14vzxRT52HYlLbLg2paPuNhvF fo/fBPBGQQ6udh2LAD3WooM/v3FK0Wn1dPOFT4igpTNrr+bA+0zcPDPBYvGxFWaA IUveI8V5wS6YsZa4nawqh/wP6bx8ZzhLtSLmdhRO7rLEFv40bk+batu6+THgHp3V GWKNRKrAQAOBgjPluUWCbeIJ7a6ICwpDt7LKQLHhzTj5XSpSgJRfAyeL7OuGij1b KHWl/7J/LBVmR5uVgUfaahJeOtfoQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=7KFzWsElfRTlX4yx3zJo8nPbd3/I3 8wBlFdUIPASb4k=; b=k9glWO07Dz40QsyR+UT1N60AkHeJaCvK5B0da9BsmtCbD aP18DjTkGt+CkJ99izm8MZkQkzbqWSaO3R+IWUrz1y8ErfWU59E2Enhus/c1Eju2 tyP3hzDOtBtFGMK5LzxW9TLbff4cNjTBduw+CpzD1+tcjoNrPRni4/coZA0Cuyt4 g6GAYtALUsLZ45nuXvZuU/C6etG2QJbaNkgSbCV5KmBFergpxGJhJLAbvfPGQGjp QUW4W9XH1K+pTD6V9+YUpO9g3iJMuAuOuhRNP1eJeSLiIFDeC7MMDS1bkdUkGovz tClmFd3i+tNFKxB7+ysouf1rT8POBT27nR0vz96zQ==
X-ME-Sender: <xms:ibh4WhFx1EfvTIPjfwUbJjnKqDJ_I0mIH-fLZvz7nxBnFc85DFD07Q>
Received: from [10.209.6.150] (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 4BF7A2415E for <mls@ietf.org>; Mon, 5 Feb 2018 15:03:21 -0500 (EST)
From: Nadim Kobeissi <nadim@symbolic.software>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <0FF1E387-CD8B-4CC6-81EC-0289CC0F7519@symbolic.software>
Date: Mon, 5 Feb 2018 21:03:20 +0100
To: mls@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/oZu6Uy_cG6XB2-UrV4x6DQGYjoo>
Subject: [Mls] Regarding Signatures
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Feb 2018 20:03:26 -0000

Hello everyone,
mls-protocol-00 says the following with regards to signing keys possessed by each participant:

"Identity Key:  A long-lived signing key pair used to authenticate the
      sender of a message.”

So far, I’ve been able to identify some missing details with regards to signatures in this protocol:

1. Cipher Suite Ambiguity:
Cipher suites seem to specify only Diffie-Hellman key agreement functions and hash functions, but not signature functions. A reference to ECDSA seems to exist under the P-256 cipher suite subsection, but it appears to be nevertheless decontextualized. More confusingly, the HandshakeType struct seems to specify an open-ended "SignatureScheme algorithm” element. Why does this exist outside the namespacing afforded by cipher suites, if at all?

2. Mention of Supporting Certificates for Signatures:
In Section 6.1, a future possibility for including a certificate for signatures is mentioned. This seems like a bad idea: do we really want to introduce X.509 and ASN.1 parsing when we have the opportunity to finally move away from it?

3. Gratuitous Signature Usage Causes Performance Issues and Conflicts with Deniability:
Signatures seem to be sometimes used gratuitously:
	A. The clearest instance of this is in 9.2, client-side enforced ordering, which suggests adding a signed envelope to *every message* simply in order to obtain client-enforced message ordering by signing a counter. This seems like overkill.
	B. To a lesser extent, this is also the case in all five handshake messages (Init, UserAdd, GroupAdd, Update, Delete), which, while a more sensible venue for signatures, does raise the question of whether handshake message authenticity can be maintained in some other way (chaining keys deriving a chain of authenticity from a signed AKE in the Init handshake message, which is currently unspecified? we should definitely think more about this, and I hope we don’t end up empty-handed.)

This is problematic, firstly, due to performance concerns, since signatures are the slowest primitives. Aside from that, though, the amount of signatures being employed as part of a regular session conflicts with an explicit goal of the protocol: mls-architecture-00 mentions deniability in section 3.2.2.5.

Signal Protocol has a wonderful construction where signatures are used to obtain an AKE. Then an HKDF is used to create a ratchet of chaining keys which chain the authenticity of the AKE down throughout the rest of the conversation. In an entire Signal session, only one signing operation is ever performed by each party. Perhaps something similar could be adopted here? Signatures have always been the most unwieldy primitive, and it might be fruitful to consider restricting them as much as possible within this protocol.

Regards,

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office