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

Natanael <> Thu, 17 September 2020 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26C4A3A07A3 for <>; Thu, 17 Sep 2020 12:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 04PpjgJuO6wh for <>; Thu, 17 Sep 2020 12:11:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600393A0796 for <>; Thu, 17 Sep 2020 12:11:17 -0700 (PDT)
Received: by with SMTP id i26so4747947ejb.12 for <>; Thu, 17 Sep 2020 12:11:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qIcTIXOK5lpk7by5d4GFHCvobIsB1uKZEafX4e5U7rw=; b=orgFWlbd3HxY8Snf75Wj4U91LMzntOSIjrOr/TJsJFDK+lmkrQZurTIyRjJvX5LdwT XEMIpqERYDXfTcL3t5KGT2hYkgvtqgMGTx0xLBWOrL/e8qzowFURo7n7je7NX7cHtIjO liujCelVlJA6VIwOsFyhuMwKTGlH5r9V3SFQODvGSbXlX8EhB2k9vCARJ6qZAnfR/bdX iImdNBBkpxKmYFMZhI47h4bVK8Zuumw2SgluqY7bnTfUyMXyG3uxv6FY+6cGQfeB9uO6 HDY1LKUy6k/9VRN9hnMut14pqXuyyuGDFxNw8Pd8G14bokezOh/GQH80tk9szD8Gy95B qgkQ==
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=qIcTIXOK5lpk7by5d4GFHCvobIsB1uKZEafX4e5U7rw=; b=CLhdysJNa/QfaSg1UG0rDcIlDYJJugicLiX4thZP3zpD8RZkLAd8KGUMUiCH0TW8bq WMjIQ2O1pd2XajPrla1r6UanrzVhqwaptmCxCCYjk4GzLgpIsTGp8q3lQLTp75/UqBKM fIcgCJ+yxTnhrpphpXiPEl43dkoPLZtEKWKrfjTdZ1QnlBbuT8RmOFneK8D+riD9Pu45 TKn978BVZoVhf+KVdChUAN/BEfpSvu4LcdQCtEEJR9g6cz81sprPSEOs1muhLuMNnQ3d R35PURRY8jN/YtJnKY1Ao6rtAKJrZVfVuXoWzWr7m/urB0a+0e+GSWMzuaBM5FyyVXJu qx0w==
X-Gm-Message-State: AOAM531/ebmFQXL4qKB7t/lIECg5N2gGI81zIkQhSsy0LJFDLMpXGxVy yWjYQfqNGHf6B4lmoFx4g7rzDcR1e+vvA1Bz+jI=
X-Google-Smtp-Source: ABdhPJwAtP18oYWCqIIeX/IvXTA5vd9ObdY/aO1P1/cd37ARtobnbC5HyejqN/yyWYXu7qJXSC24MKdrUW+Mp5K9iSQ=
X-Received: by 2002:a17:906:9416:: with SMTP id q22mr24639809ejx.82.1600369875769; Thu, 17 Sep 2020 12:11:15 -0700 (PDT)
MIME-Version: 1.0
References: <003401d68cf9$d7c5d420$87517c60$>
In-Reply-To: <003401d68cf9$d7c5d420$87517c60$>
From: Natanael <>
Date: Thu, 17 Sep 2020 21:11:02 +0200
Message-ID: <>
To: Marta Mularczyk <>
Content-Type: multipart/alternative; boundary="000000000000f4602605af872579"
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 19:11:19 -0000

Den tors 17 sep. 2020 19:43Marta Mularczyk <> skrev:

> 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:
I'd like to note that another option to changing what's hashed is to use an
algorithm designed to guarantee determinism with no malleability, like
Verifiable Random Functions (VRF).

There's currently an ongoing standardization process for VRF:s (one type
based on RSA, one based on ECC), see below;