Return-Path: 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 BFEA312EB11 for ; Tue, 23 Oct 2018 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=fZMV/q2F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N/t5Nq0n 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 07MTAaa0D-cO for ; Tue, 23 Oct 2018 08:12:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA03130E2A for ; Tue, 23 Oct 2018 08:12:58 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8DEE321D12 for ; Tue, 23 Oct 2018 11:12:57 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 23 Oct 2018 11:12:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 3QTaa7dA+tWKRvD95pvAmXkNDGcou3LkbRu9Mtpr7K8=; b=fZMV/q2FVvL7sKtK TgHMlgmDASCRyTIzYmkTSPNW/P8ekoNF7FLtaskLB0vXlVbtyuPLUuUQcpAfNdKD ez+VlHybtgG2IBcsKda8IPeQ5R28sxemgKvA/igLwqhPwWxBCzAHr6oXWTnxnCx/ PNY/c4A8zx3vKe45YyFaMhhTwJg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3QTaa7dA+tWKRvD95pvAmXkNDGcou3LkbRu9Mtpr7 K8=; b=N/t5Nq0nYt9N76zDAgh8yw1SSgBCGJt3MYBH8oq90GkZYW/NMKoo6tBOQ 3ocLVMFF9Ed5mpT7Xc5sGQ0p5lUWIwU0tCXwoSmGBErNBn1uGtix7gm/G6o5c5lt IQKeFsdFdUU5RidaB/KtoQnJUygah5jBOxOIhcVYKCM+mcxV49ZAYqiUoBGYOvlj SqRYKqSUJOI4t6NsakshHsgJqOaJOwgfIEUbudBXGPWpXw8ULuFRwQGggNuhIlRF Ivex5k7CN7HOz6R3Ht3x99/6a0UgTlzLHEeQSoaMwkPEliH/P1MqaHPgb4Ac5v7q 5itv2ghR/eI0zq6X8gu2xOUL5GqRg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 340DE9E172; Tue, 23 Oct 2018 11:12:57 -0400 (EDT) Message-Id: <1540307577.2861642.1551828416.05A754F2@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154030757728616420" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b315a288 Date: Tue, 23 Oct 2018 16:12:57 +0100 In-Reply-To: References: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:13:02 -0000 This is a multi-part message in MIME format. --_----------=_154030757728616420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I wouldn't die on this hill, but I prefer the MAC design just for cleanness reasons in analysis. Collapsing the final two MAC invocations in the derivation doesn't seem like it gets you very much. Note that we wouldn't have to MAC over the message transcript---over the constant zero might be enough. k On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote: > > > On Tue, Oct 23, 2018 at 6:34 AM Russ Housley > wrote:>> >>> Hey all, >>> >>> In the just-released -02 draft of MLS, I've added a key confirmation >>> step to the handshake authentication process. Important question >>> after "=====" below...>>> >>> In the previous draft, there was an authentication mechanism that >>> ensured that if two group members ended up with different GroupState >>> objects, then they would have different keys. However, it did not >>> provide any way for group members to recognize that this was the >>> case, except for AEAD checks on encrypted messages failing.. With >>> explicit key confirmation, the recipient of a Handshake message >>> knows that if processing of the handshake message succeeds, then the >>> recipient has the same GroupState as the sender.>>> >>> This provides a degree of protection against malicious insiders that >>> send different TreeKEM values to different parts of the tree. >>> Namely, only the subset of the tree that got the key matching the >>> key confirmation will accept the Handshake message; the others will >>> be locked out. (Assuming a broadcast channel; if the sender can send >>> different key confirmations to different recipients, then this is no >>> help.). This isn't complete protection, but at least the locked-out >>> members know they've been locked out, and can complain about it.>>> >>> ===== >>> >>> The major question here is whether it's sufficient to derive a key >>> confirmation value from the key schedule and publish it, or whether >>> the value derived in the key schedule should be used as a MAC key to >>> generate a MAC over the message transcript. I've posted PRs for >>> both; the latter is what I merged in -02>>> >>> Derive: https://github.com/mlswg/mls-protocol/pull/72 >>> MAC: https://github.com/mlswg/mls-protocol/pull/71 >>> >>> On the one hand, the MAC-based approach is what is done in TLS. It >>> feels safer, because we never publish anything that's in the key >>> schedule diagram.>>> >>> On the other hand, the Derive-Secret operation used to create the >>> key confirmation value in the key schedule is **already** based on >>> HMAC. So it doesn't seem like the extra MAC step is adding that >>> much value.>>> >>> If we can convince ourselves that the Derive approach (without the >>> extra MAC) is sufficient, I would prefer to do that, since it's >>> simpler. But feedback on this point would be very much appreciated.>> >> The Derive approach is straightforward. If this leaks in any >> surprising way, then draft-ietf-tls-exported-authenticator has a >> problem too, right?> > I don't think that necessarily follows. That draft follows the MAC > approach, in that the values it exports from the TLS key schedule are > used as inputs to a MAC, and only the MAC output is published.> > That said, I agree it's instructive to look at uses of the TLS > exporter to identify parallel risks here. You would want to find some > case where an exported value is used as a public value. > Unfortunately, the only other major usage of exporters that comes to > mind is DTLS-SRTP, which exports a key and salt. You could use that > to argue either way, since the salt is notionally public, but in > practice is never published.> > --Richard > > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --_----------=_154030757728616420 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I wouldn't die on this hill, but I prefer the MAC design just for cleanness reasons in analysis. Collapsing the final two MAC invocations in the derivation doesn't seem like it gets you very much.

Note that we wouldn't have to MAC over the message transcript---over the constant zero might be enough.

k


On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote:


On Tue, Oct 23, 2018 at 6:34 AM Russ Housley <housley@vigilsec.com> wrote:

Hey all,

In the just-released -02 draft of MLS, I've added a key confirmation step to the handshake authentication process.  Important question after "=====" below...

In the previous draft, there was an authentication mechanism that ensured that if two group members ended up with different GroupState objects, then they would have different keys.  However, it did not provide any way for group members to recognize that this was the case, except for AEAD checks on encrypted messages failing..  With explicit key confirmation, the recipient of a Handshake message knows that if processing of the handshake message succeeds, then the recipient has the same GroupState as the sender.

This provides a degree of protection against malicious insiders that send different TreeKEM values to different parts of the tree.  Namely, only the subset of the tree that got the key matching the key confirmation will accept the Handshake message; the others will be locked out. (Assuming a broadcast channel; if the sender can send different key confirmations to different recipients, then this is no help.). This isn't complete protection, but at least the locked-out members know they've been locked out, and can complain about it.

=====

The major question here is whether it's sufficient to derive a key confirmation value from the key schedule and publish it, or whether the value derived in the key schedule should be used as a MAC key to generate a MAC over the message transcript.   I've posted PRs for both; the latter is what I merged in -02

On the one hand, the MAC-based approach is what is done in TLS.  It feels safer, because we never publish anything that's in the key schedule diagram.

On the other hand, the Derive-Secret operation used to create the key confirmation value in the key schedule is **already** based on HMAC.  So it doesn't seem like the extra MAC step is adding that much value.

If we can convince ourselves that the Derive approach (without the extra MAC) is sufficient, I would prefer to do that, since it's simpler.  But feedback on this point would be very much appreciated.

The Derive approach is straightforward.  If this leaks in any surprising way, then draft-ietf-tls-exported-authenticator has a problem too, right?

I don't think that necessarily follows.  That draft follows the MAC approach, in that the values it exports from the TLS key schedule are used as inputs to a MAC, and only the MAC output is published.

That said, I agree it's instructive to look at uses of the TLS exporter to identify parallel risks here.  You would want to find some case where an exported value is used as a public value.  Unfortunately, the only other major usage of exporters that comes to mind is DTLS-SRTP, which exports a key and salt.  You could use that to argue either way, since the salt is notionally public, but in practice is never published.

--Richard

_______________________________________________
MLS mailing list

--_----------=_154030757728616420--