Re: [Mls] Regarding Signatures

"Katriel Cohn-Gordon" <> Tue, 06 February 2018 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0F4F126E3A for <>; Tue, 6 Feb 2018 07:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=t597lvkA; dkim=pass (2048-bit key) header.b=sKxSg5V8
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EBnYxDylb_oO for <>; Tue, 6 Feb 2018 07:07:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 630A112D7F8 for <>; Tue, 6 Feb 2018 07:07:53 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A8CC520D1E for <>; Tue, 6 Feb 2018 10:07:50 -0500 (EST)
Received: from web6 ([]) by compute6.internal (MEProxy); Tue, 06 Feb 2018 10:07:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=FvSbYjEuLGyzJtOK5UctpArXcv hexU0T4HCNkhFGciM=; b=t597lvkAQXhKIQuYP78X0Wxjuzf7GxNL6mrj0Ux0E1 BwlwKlYFNOCaa/TbeBDyHgwsLEI1OT5vgsU7THh0ViVvdxeGgt9fATnAJcMySsyQ 88fASHaWVH0olTSjDEmQ2oEb1YNIkqNCuXmugRX+5EBPQSLj6ATHv48HMurJCHo7 o=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FvSbYj EuLGyzJtOK5UctpArXcvhexU0T4HCNkhFGciM=; b=sKxSg5V8Dk37ZOfugkcQ6f H4XpiSVZYgpIhjSMOiPp/wVYC+vSqm5uJHvru8GXhBiLTmfRfHAyBy4bq1iMqdL0 0FU9gNlvfv0Nm593vOqVQzpwE/rMVWhfcTfh4pBmY6ytoePliHLDg/6oY9uSFLwJ Vu7U01s7qhpXc9cP+gSixU8/mlUB0v9+LxUUj1RffyW7qHf7+DCcfdiQ7GJaLdHZ u9f0v7MTbjy+ZY9u8rrbnlXh8bYgmqCh0W0NPC+8ycVur4ORd0jmV/UemAxwZuSb Bgt3EDty7v4cilhwMrSAAiCIT46PpOkzapGYqg/eWlz5PI0XjJHp5PuzW/aCqf8w ==
X-ME-Sender: <xms:xsR5WgsTqxL8I6lZ2ZOxbEcdFEt5D1jutsJowt9VeMhjbQPbcA-8Sw>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 873994265; Tue, 6 Feb 2018 10:07:50 -0500 (EST)
Message-Id: <>
From: "Katriel Cohn-Gordon" <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-fde26eb3
Date: Tue, 06 Feb 2018 15:07:50 +0000
In-Reply-To: <>
References: <>
Archived-At: <>
Subject: Re: [Mls] Regarding Signatures
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Feb 2018 15:08:00 -0000

Thanks for the comments! On (3), I agree it makes sense to restrict the use of signatures where it's not otherwise problematic, but note that Signal only avoids them because it is two-party: the Sender Key variant includes an explicit signature on every message precisely because symmetric keys don't work for message origin authentication in the n-party case. (Which must mean that the performance isn't _too_ bad, given WhatsApp uses sender keys.)

That is, suppose A, B and C all share a symmetric key and A receives a message authenticated by that key. A can't tell whether B or C sent the message unless there is something else going on, either a signature or some pairwise symmetric key that only A and one other party knows.

There may well be a design that increases the level of deniability while not impacting other more-important goals (for example, by distributing a signature key in a deniable way), and I would be all in favour of that!


On Mon, 5 Feb 2018, at 8:03 PM, Nadim Kobeissi wrote:
> 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
> 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 •
> Sent from office
> _______________________________________________
> MLS mailing list