Re: [TLS] Merkle Tree Certificates

Bas Westerbaan <> Wed, 07 June 2023 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7C1AC15107D for <>; Wed, 7 Jun 2023 01:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kt96_L3_WZQC for <>; Wed, 7 Jun 2023 01:51:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 86D4EC151075 for <>; Wed, 7 Jun 2023 01:51:25 -0700 (PDT)
Received: by with SMTP id 00721157ae682-5664b14966bso88069697b3.1 for <>; Wed, 07 Jun 2023 01:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686127884; x=1688719884; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Kfsv1imWtjgI9UJZ29DODH1c0Bb5hFyBW1de/7+cM18=; b=VNXC8bm9yqUZUr3aW6Mwon/G7z/R63t1FSROyJeGYACIzkrHz9PdYcxm9JXr1u0sP1 viHz8BBtdCLchM859tQaeZI/R9waC0AxqUt3SvGXJNywUg1bkClyDogSZRHge6JRB2AT E9jebmgLh9ikUuyq/drmsKvP8NLEDdyjXaDgA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686127884; x=1688719884; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Kfsv1imWtjgI9UJZ29DODH1c0Bb5hFyBW1de/7+cM18=; b=edRYRBd6LTmmTOZBEImdTICwtNZewxOp7Mzx0/uPP7pdmdgcT9ngg9A5CaPbqq7qAx /5onmNWUkbhiuJpgUZ/kp9p2hl/rBy8ZtfjrzCJByL+hhl1koA2QFf6q1fCzZ3UVcxig +6r6OOMcnzoZHSXontLnb8tmmSCjVk1KU15jAzsC74HUAAbmNnVqZCDhTeZBOQVByUPh kNYm2y///UIckqJlxepJ9lSh3QSjEUpdZAkINXNFy3YnOIkzA8S/jhoPx7IEfjPY2HEe PamMu8d+tvJCw4N+ldQHmlOWYkypEHdZk6ZhxKZVjZLf2pvgs6E/wMIT66i8tYL6In34 ss2A==
X-Gm-Message-State: AC+VfDzihKdJ7a7MHo7ccUgJX96d3+xAF/H0IwQlA3QF2g5S9m/bHnqi avZ8fpGGJr942dbg684qJz0l0LT7w7pJHRQE3FuM4Q==
X-Google-Smtp-Source: ACHHUZ6vOZvZRH+xhpVCt6VJeRbio2pyQ7sOTJ7piKxTg98DTOgFFxCxK+X2eCVVVfmufX+nBDhHGOCCjGpIA0SSBoA=
X-Received: by 2002:a0d:d94c:0:b0:561:94ac:43e with SMTP id b73-20020a0dd94c000000b0056194ac043emr5860078ywe.26.1686127884085; Wed, 07 Jun 2023 01:51:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <ZBsxgM/cv+vuBPEj@LK-Perkele-VII2.locald> <> <ZH7mrdGzq/Za4Ypm@LK-Perkele-VII2.locald> <> <ZH9cei5JY6+0q7yr@LK-Perkele-VII2.locald>
In-Reply-To: <ZH9cei5JY6+0q7yr@LK-Perkele-VII2.locald>
From: Bas Westerbaan <>
Date: Wed, 07 Jun 2023 10:51:12 +0200
Message-ID: <>
To: Ilari Liusvaara <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000941ee505fd863d2c"
Archived-At: <>
Subject: Re: [TLS] Merkle Tree Certificates
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2023 08:51:29 -0000

> I mean, is there a cryptographic reason for it?


> (However, absent cryptographic reasons, this all is way premature.)

Indeed. We like to have a concrete proposal, but thinking through these
details is premature at this point.

[snip] What that in effect does
> is to make it much more difficult to exploit chosen-prefix collisions in
> hash function.

However, that requirement holds irrespective of the hash function used,

and it has in fact been held for SHA-256 (regardless of there not being
> any known even remotely feasible attacks) instead of just being a dead
> letter from the past with much worse hash functions.

Ah, it would indeed be neat if we could design this, so that we do not
require (chosen prefix) collision resistance of the hash. I'd say it's nice
to have, but not a must. Tracking in