Re: [TLS] Merkle Tree Certificates

[Stephen Farrell <[e-mail]>]

Hiya,

I had a read and think this is a great topic for
discussion.

A few points:

- I think we'd benefit from trying to think through
the dynamics of this, e.g. how many of each entity
might we see and how'd that differ from the current
web PKI and possibly affect the web? (It's fine that
that analysis emerge in time, not asking for it now.)

- I do think the trust_anchors extension values might
be better off as e.g. truncated hashes of public keys
or something like that.

- Aside from better on-the-wire efficiency, I think
another reason to examine designs like this is that
adding multiple public keys and signatures to x.509
certs (one of the alternative designs) seems like it
might be a bit of a nightmare, as PKI libraries are
buggily updated to try handle that - designs like
this seem better in terms of keeping the new code in
a less risky place.

Cheers,
S.

On 10/03/2023 22:09, 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 <[e-mail]> 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
>>
>>
>>
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls