Re: [MLS] Include signature in the confirmed transcript hash?

Richard Barnes <> Thu, 17 September 2020 22:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 803B13A0D4C for <>; Thu, 17 Sep 2020 15:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DCR6Uha6lEUF for <>; Thu, 17 Sep 2020 15:22:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EAE03A0D42 for <>; Thu, 17 Sep 2020 15:22:05 -0700 (PDT)
Received: by with SMTP id v54so3303907qtj.7 for <>; Thu, 17 Sep 2020 15:22:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BIjteFti2l2RWDdr4FmFUtyhya54D35fU23rbgrw7tU=; b=KQRgweb/r79hGKqI6d7Ie4tnpDArvrGNC0Lvhtwbq/mRGBiiRPyLEQJ/Lpnttg0YAB GFWEWwbrbHx7zLLggB3CWuopw1drej3/zMtNAMq4rVOcDabX3kI2TxM1EGCyKxGrW4JN XDkIjUXqhQhU0ugnLlcaeGmaE3tJYALAV8EY6uvNDpNsRTA5OjqNrEBmB2QBv2BiRimm P7fIa++vA9XvVYAD5RCLennjVEQy4IZTK+ko2ziBE4o8VKvs6/J2PNy3CIWMAqicTupE 3r9TupSq9Zgk8kz08fopy5hReN7Nutp1rGEMxkcPwQ/5jP1FgU3RkhdXFmhjOT7z9klY OGcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BIjteFti2l2RWDdr4FmFUtyhya54D35fU23rbgrw7tU=; b=axS5vTz+sbtUuMqcdiE5UlSV+1q2rS/5lBUXoqHGDpQE17Q6yfnplWRweKYLQDVlDT wPMP7+QHkmzmBh88mwb4iWCGnDDDUsEopA7vrZ6pePjixCV4rrvxrNtK04eHK3qWJlby +Ips5JWfh0cL79d8lO2xoQ1KUNmYmZ15eNoqr+grd3sV1UHxP8NxgGPZTf2lK0B+a8X4 8hTGIXuvjSHKAZ6u6enE/2GcLAE+jLdqOXCdQsXRTX94KFm1yjcZj7hOnZU0frsgpYUD pV096gB+pVYJ2qeI5Bb3vzOM8sdlU0wHvSJiawrBqqWX/ZBSRYRM/d+Z2Di47g1hEVPI caew==
X-Gm-Message-State: AOAM532h2j4c4QQh7t1GE7zuPabXbCIMwWlcKv2nT7gVLIQ9ZkU/7qXv aO5hY7Fh3lb8Fnh469VTN12s1LMF7q884gnErhmua0aRIFSx/Q==
X-Google-Smtp-Source: ABdhPJytB/aa9tWuYNl5mBy7jMacSQlCJeBqCZ4XRwHHNKfEdvRAGWb2va2uxchV98XUo3gC+zBuZBmlKEIyD7H2fy4=
X-Received: by 2002:ac8:1b92:: with SMTP id z18mr29416240qtj.265.1600381324924; Thu, 17 Sep 2020 15:22:04 -0700 (PDT)
MIME-Version: 1.0
References: <003401d68cf9$d7c5d420$87517c60$>
In-Reply-To: <003401d68cf9$d7c5d420$87517c60$>
From: Richard Barnes <>
Date: Thu, 17 Sep 2020 18:21:40 -0400
Message-ID: <>
To: Marta Mularczyk <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000060ac4705af89d0ea"
Archived-At: <>
Subject: Re: [MLS] Include signature in the confirmed transcript hash?
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: Thu, 17 Sep 2020 22:22:09 -0000

Hi Marta,

Thanks for writing this up.  This analysis seems sound to me. It reminds me
of the structure of the server's first flight post-ServerHello in TLS [1]:

    AEAD(EncryptedExtensions Certificate CertificateVerify Finished)

That means you end up with (1) message content, (2) signature over message
content, (3) MAC that confirms agreement on the derived secrets (4) AEAD
authentication tag that verifies membership in the prior group (established
by the ClientHello/ServerHello).  Which I think is the same order you're
proposing here.  Just to restate to confirm I'm understanding:

MLSPlaintext.signature = Sign(sig_private_key; MLSPlaintext.group_id, ...
confirmed_transcript_hash = Hash(confirmed_transcript_hash,
MLSPlaintext.confirmation_tag = MAC(confirmation_key,

I don't think this completely gets us out of the need for the
interim_transcript_hash.  We will still need it if we want to include the
confirmation_tag in the transcript.  This seems like a good idea, analogous
to TLS including the Finished message in the transcript for post-handshake
messages [2].  (For the same reason, I would argue that the membership_tag
would *not* need to go in the transcript.)

There's also a bit of weirdness here arising from the fact that we use the
same framing for Commits, Proposals, and application data
(MLSPlaintext/MLSCiphertext).  In particular, the signature part is
shared.  So on the one hand, the natural syntax given the above is to put
the confirmation_tag after the signature (so that the signature covers
everything above it).  But on the other hand, that's weird because what do
you do with the confirmation_tag for non-Commit messages?  ("Leave it
empty" would be the obvious answer.). You could leave the confirmation_tag
where it is syntactically, and just change the computations, but that would
break the (admittedly aesthetic) property that the signature covers
everything above it.

Overall, though, I think this is worth writing up a PR on.  I look forward
to your proposal for how to resolve the syntax issue :)

Thanks again,


On Thu, Sep 17, 2020 at 1:43 PM Marta Mularczyk <> wrote:

> Hi all,
> Together with Joël Alwen and Daniel Jost, we noticed some unexpected (at
> least to us) effects of the way transcript hash is computed. What are your
> thoughts on this?
> Details: Say Alice and Bob each processes a commit packet and they end up
> with the same epoch secrets. Expected guarantee: agreement on the secrets
> implies being in sync -- agreement on the group state, and being able to
> continue progressing epochs.
> Problem: the latter is false if the packets processed by Alice and Bob
> only differ in the signature string (it's easy to come up with many
> equivalent ECDSA signatures, given only the signer's public key). Now Alice
> and Bob agree on the confirmed_transcript_hash, and hence on the current
> secrets, but not on the interim_transcript_hash, so they won't agree on the
> next epoch secrets. Result: they will never accept the same commit (due to
> not matching confirmation_tag) and so they'll never be in sync in the next
> epoch.
> This can be solved by including the signature in the
> confirmed_transcript_hash and not signing the confirmation_tag (the tag is
> also not part of the transcript_hash). We claim that this doesn't affect
> security. Assume Alice sends a commit and the adversary intercepts the
> packet. Consider these 3 cases:
> - if the adversary doesn't know the current epoch secrets, then he can't
> modify any part of Alice's packet (due to AEAD/MAC security of the message
> framing).
> - if he knows the epoch secrets but not Alice's signing key, then the only
> thing he can, in principle, modify is the confirmation_tag. However, the
> tag is fully determined by the signed part of the commit (and the
> transcript history).
> - if he knows both, then the adversary can already produce any packet he
> wants on behalf of Alice.
> An additional advantage of this solution is that it simplifies the
> protocol by removing the interim_transcript_hash.
> In detail, a commit now proceeds as follows:
> 1. construct the MLSPlaintext with the Commit object and
> confirmation_tag=0,
> 2. sign the MLSPlaintext and include the result in the
> confirmed_transcript_hash,
> 3. advance the key schedule and update the confirmation_tag in the
> MLSPlaintext.
> If the working group generally agrees on the above approach, we'll be
> happpy to draft a PR.
> Best,
> Marta
> _______________________________________________
> MLS mailing list