[TLS] Merkle Tree Certificates

David Benjamin <davidben@chromium.org> Fri, 10 March 2023 22:09 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32465C15171B for <tls@ietfa.amsl.com>; Fri, 10 Mar 2023 14:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.245
X-Spam-Level:
X-Spam-Status: No, score=-9.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvFhc_7P0BUG for <tls@ietfa.amsl.com>; Fri, 10 Mar 2023 14:09:28 -0800 (PST)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 9402FC151520 for <tls@ietf.org>; Fri, 10 Mar 2023 14:09:28 -0800 (PST)
Received: by mail-yb1-xb35.google.com with SMTP id i6so6742127ybu.8 for <tls@ietf.org>; Fri, 10 Mar 2023 14:09:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1678486167; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nR6sR8FTXhO58Jo3SpaE483MkBB+CNgaii9kR8zyY0I=; b=TxN/6//xlmwzzrt7qBCF6dEWEsyVu2czHgh+zulxasOfu6/MSUqV+juihuZDSYbD2s doqGzW1nDat2QD/Ovu8HK40Qxsqz/x+/D534XtASSD8/4l1iDbz8k6evkaqO2VP/1cu1 UFbTG8l8hRLVIhHYJL/6seufcqFqi10MgTx3o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678486167; 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=nR6sR8FTXhO58Jo3SpaE483MkBB+CNgaii9kR8zyY0I=; b=WRrv2HSlQk+JNlE6kMPBViE81lcrmLJmXMtNnNSoXv/XUiSDTQ8o0bqi4RmvD2uPmA TJre6Kg7jgA2u/vRmawQUfyQyEoUvRd5WkGbRRzerdZF8GKbJtlEFpLKFOUcYgEXYS4V IuAPE5j5ZlujtaOBFjBlYPBIK8ybhJLvBynfUwKkgshtF3L5VmrpYGzUIj6ePZLNO05S SQcjYe8ehYaoBfzbiGmTYg+sUIosAHpHdu/9pPi44jXq/Uneflc4dZC5/YE7zlsZ7sYL OvHKmxVUDlrt4o9FUZOXGbwy5MaV/RARffXtpj2QDLIhvuHWIY/qMSNcbqZR0HUyygAH +w7A==
X-Gm-Message-State: AO0yUKWPbD1g0WDk+gwsS0XoGkwh+GsHjRNlKHg2HZrfcSYs5NP4pR1u Y37lm8rW5e6RTnevPs7tyeo69OoqyDG8bIzERR4uJ29VSS2UJsfmQACl
X-Google-Smtp-Source: AK7set93NyAgebAKCiiu26wkiKRJS358EllAl41kNr+lFW4I8J1prbWWlLIQfpwp8vr7IvOdFFtrN8K6U7xAJNiSKZI=
X-Received: by 2002:a25:9292:0:b0:b1a:64ba:9cac with SMTP id y18-20020a259292000000b00b1a64ba9cacmr8643809ybl.4.1678486166895; Fri, 10 Mar 2023 14:09:26 -0800 (PST)
MIME-Version: 1.0
References: <167848430887.5487.1347334366320377305@ietfa.amsl.com>
In-Reply-To: <167848430887.5487.1347334366320377305@ietfa.amsl.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 10 Mar 2023 17:09:10 -0500
Message-ID: <CAF8qwaD9x5v1uU6mLtnUAGMnBW881ZE0ymK8rsQzrV2hfj7yHA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: Bas Westerbaan <bas@cloudflare.com>, Devon O'Brien <asymmetric@google.com>
Content-Type: multipart/alternative; boundary="000000000000bd7cf805f6930330"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aKncr_-vz_w69LjbLZeQoIGW4hs>
Subject: [TLS] Merkle Tree Certificates
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 22:09:32 -0000

Hi all,

I've just uploaded a draft, below, describing several ideas we've been
mulling over regarding certificates in TLS. This is a draft-00 with a lot
of moving parts, so think of it as the first pass at some of ideas that we
think fit well together, rather than a concrete, fully-baked system.

The document describes a new certificate format based on Merkle Trees,
which aims to mitigate the many signatures we send today, particularly in
applications that use Certificate Transparency, and as post-quantum
signature schemes get large. Four signatures (two SCTs, two X.509
signatures) and an intermediate CA's public key gets rather large,
particularly with something like Dilithium3's 3,293-byte signatures. This
format uses a single Merkle Tree inclusion proof, which we estimate at
roughly 600 bytes. (Note that this proposal targets certificate-related
signatures but not the TLS handshake signature.)

As part of this, it also includes an extensibility and certificate
negotiation story that we hope will be useful beyond this particular scheme.

This isn't meant to replace existing PKI mechanisms. Rather, it's an
optional optimization for connections that are able to use it. Where they
aren't, you negotiate another certificate. I work on a web browser, so this
has browsers and HTTPS over TLS in mind, but we hope it, or some ideas in
it, will be more broadly useful.

That said, we don't expect it's for everyone, and that's fine! With a
robust negotiation story, we don't have to limit ourselves to a single
answer for all cases at once. Even within browsers and the web, it cannot
handle all cases, so we're thinking of this as one of several sorts of PKI
mechanisms that might be selected via negotiation.

Thoughts? We're very eager to get feedback on this.

David

On Fri, Mar 10, 2023 at 4:38 PM <internet-drafts@ietf.org> wrote:

>
> A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name:           draft-davidben-tls-merkle-tree-certs
> Revision:       00
> Title:          Merkle Tree Certificates for TLS
> Document date:  2023-03-10
> Group:          Individual Submission
> Pages:          45
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
> Html:
> https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs
>
>
> Abstract:
>    This document describes Merkle Tree certificates, a new certificate
>    type for use with TLS.  A relying party that regularly fetches
>    information from a transparency service can use this certificate type
>    as a size optimization over more conventional mechanisms with post-
>    quantum signatures.  Merkle Tree certificates integrate the roles of
>    X.509 and Certificate Transparency, achieving comparable security
>    properties with a smaller message size, at the cost of more limited
>    applicability.
>
>
>
>
> The IETF Secretariat
>
>
>