Re: [TLS] Merkle Tree Certificates

Hi Hubert, 

I am not an author of draft-davidben-tls-merkle-tree-certs, but I had some feedback on this question: 

RFC7924 was a good idea but I don’t think it got deployed. It has the disadvantage that it allows for connection correlation and it is also challenging to demand a client to either know all its possible destination end-entity certs or be able to have a caching mechanism that keeps getting updated. Given these challenges and that CAs are more static and less (~1500 in number) than leaf certs, we have proposed suppressing the ICAs in the chain (draft-kampanakis-tls-scas-latest which replaced draft-thomson-tls-sic ) , but not the server cert. 

I think draft-davidben-tls-merkle-tree-certs is trying to achieve something similar by introducing a Merkle tree structure for certs signed by a CA. To me it seems to leverage a Merkle tree structure which "batches the public key + identities" the CA issues. Verifiers can just verify the tree and thus assume that the public key of the peer it is talking to is "certified by the tree CA". The way I see it, this construction flattens the PKI structure, and issuing CA's are trusted now instead of a more limited set of roots. This change is not trivial in my eyes, but the end goal is similar, to shrink the amount of auth data. 

-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Hubert Kario
Sent: Monday, March 13, 2023 11:08 AM
To: David Benjamin <davidben@chromium.org>
Cc: <tls@ietf.org> <tls@ietf.org>; Devon O'Brien <asymmetric@google.com>
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Why not rfc7924?

On Friday, 10 March 2023 23:09:10 CET, David Benjamin wrote:
> 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-0
> 0.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-0
> 0.html
> Htmlized:
>  
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-c
> erts
>
>
> 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
>
>
>

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls