Re: [TLS] AuthKEM: Splitting the draft and next steps
On Wed, Jul 05, 2023 at 04:34:28PM +0200, Thom Wiggers wrote:
>
> Op wo 5 jul 2023 om 14:22 schreef Ilari Liusvaara >:
>
> > On Wed, Jul 05, 2023 at 09:26:57AM +0200, Thom Wiggers wrote:
> > > Hi Ilari,
> >
> > * The certificate being a message, it is subject to acknowledgements.
> > However, server hello must be logically before it. This is required
> > to meet the acknowledgment epoch rule.
> > * The server flight needs to be broken into two just before server
> > Finished, first part being unordered with certificate, and second
> > being the next flight. This is required to have the certificate
> > available for computing finished, and to meet the implicit
> > acknowledgment rule.
> >
>
> I'm very open to hacks, such as turning it into an ECH-style encrypted
> extension. Whatever makes this easier.
>
> I think the main open question, also for regular client-auth
> pre-shared-kem-key AuthKEM is how do we treat this message in the
> transcript if the server *can't* decrypt this message (and tries to fall
> back to e.g. plain AuthKEM or TLS). But this is something that is in the
> issue tracker and document already.
The transcript would be computed with plain AuthKEM or TLS rules.
This is already required for handling the case where client thinks the
server supports PSK-KEM, but the server supports only TLS (e.g., due to
information time skew, or non-uniform cluster). This needs to fallback
to regular TLS.
> > And then it occured to me earlier today that web browsers might not like
> > the abbreviated AuthKEM very much: They really do not like to use DNS
> > for server authentication, instead preferring to use certificates sent
> > in-band. Of course, adding certificate message would duplicate the key
> > information, which is a footcannon.
> >
>
> The keys-in-DNS idea is definitely more of an extension that I do not want
> to solve before settling on the main protocol. The main hard problem seems
> to be authenticating this key in DNS, and we definitely do not want to push
> all certificates there. (ChrisW told me that keys-in-DNS was also briefly
> discussed and shot down for semi-static/OPTLS for similar reasons). I am
> hoping we might have some synergies with the infra that supports ECH and
> perhaps the proposed much-compressed merkle tree certificates though. Any
> such deployments, which will need to periodically update the DNS records in
> the case of MTCs, might be a bit more advanced but seem by no means
> impossible.
Unfortunately, I don't think DNS is capable of handling the more
elaborate MTC negotiation.
With regard to certificate size, the main limit with newer DNS
transports (Do{T,Q,H,H3}) is the hard 64kB limit for a record set.
I think nowadays certificates are mostly 2.5-7kB or thereabouts.
However, future post-quantum certificates can be much larger.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Abridged Certificate Compression
Hi all, I've submitted the draft below that describes a new TLS certificate compression scheme that I'm calling 'Abridged Certs' for now. The aim is to deliver excellent compression for existing classical certificate chains and smooth the transition to PQ certificate chains by eliminating the root and intermediate certificates from the bytes on the wire. It uses a shared dictionary constructed from the CA certificates listed in the CCADB [1] and the associated extensions used in end entity certificates. Abridged Certs compresses the median certificate chain from ~4000 to ~1000 bytes based on a sample from the Tranco Top 100k. This beats traditional TLS certificate compression which produces a median of ~3200 bytes when used alone and ~1400 bytes when combined with the outright removal of CA certificates from the certificate chain. The draft includes a more detailed evaluation. There were a few other key considerations. This draft doesn't impact trust decisions, require trust in the certificates in the shared dictionary or involve extra error handling. Nor does the draft favor popular CAs or websites due to the construction of the shared dictionary. Finally, most browsers already ship with a complete list of trusted intermediate and root certificates that this draft reuses to reduce the client storage footprint to a few kilobytes. I would love to get feedback from the working group on whether the draft is worth developing further. For those interested, a few issues are tagged DISCUSS in the body of the draft, including arrangements for deploying new versions with updated dictionaries and the tradeoff between equitable CA treatment and the disk space required on servers (currently 3MB). Best, Dennis [1] Mozilla operates the Common CA Database on behalf of Apple, Microsoft, Google and other members. On 06/07/2023 23:11, internet-dra...@ietf.org wrote: A new version of I-D, draft-jackson-tls-cert-abridge-00.txt has been successfully submitted by Dennis Jackson and posted to the IETF repository. Name: draft-jackson-tls-cert-abridge Revision: 00 Title: Abridged Compression for WebPKI Certificates Document date: 2023-07-06 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt Status: https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/ Html: https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge Abstract: This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
