Re: [TLS] draft-ietf-tls-cert-abridge Update

[Dennis Jackson <[e-mail]>]

Hi Panos,

On 05/03/2024 04:14, Kampanakis, Panos wrote:
>
> Hi Dennis,
>
> > I can see two different ways to handle it. Either as you suggest, we 
> have it be a runtime decision and we just prefix the compressed form 
> with a byte to indicate whether pass 2 has been used. Alternatively, 
> we can define two codepoints, (pass 1 + pass 2, pass 1).
>
> > I'd like to experiment with both operations and measure what the 
> real world difference is first, then we can make a decision on how to 
> proceed. There's also been more interest in the non-webpki use case 
> than I expected, so that needs to factor in to whichever option we pick.
>
> Maybe these will not matter for the scenario I am considering. Let’s 
> say the client advertised support for draft-ietf-tls-cert-abridge. And 
> the server sent back
> - CompressedCertificate which includes the 2 identifiers for the ICA 
> and RootCA from Pass 1.
>
> - uncompressed, traditional CertificateEnty of the end-entity certificate
>
> Or it sent back
>
> - uncompressed, traditional CertificateEnties for the  ICA and RootCA 
> certs
>
> - CompressedCertificate which includes the ZStandard compressed (based 
> on the Pass2 dictionary) end-entity cert
>
> My point is that nothing should prevent the client from being able to 
> handle these two scenarios and normative language should point that 
> out. Any software that can parse certs in compressed form, ought to be 
> able to parse them in regular form if the server did not support Pass1 
> (CA cers were not available for some reason) or Pass2 (eg. if CT Logs 
> were not available for some reason).
>
> Am I overseeing something?
>
Yes I think so. TLS1.3 Certificate Compression applies to the entire 
Certificate Message, not individual CertificateEntries in that message. 
Those individual entries don't currently carry identifiers about what 
type they are, their type is negotiated earlier in the 
EncryptedExtensions extension.

So to handle this as you propose, we'd need to define a type field for 
each entry to specify whether that particular entry had undergone a 
particular pass (or both). In my message, I was suggesting either have 
it be a single label for the entire message or putting the label into 
the TLS1.3 Cert Compression codepoint.

Best,
Dennis

> *From:* Dennis Jackson <ietf=[e-mail]>
> *Sent:* Monday, March 4, 2024 10:47 AM
> *To:* Kampanakis, Panos <[e-mail]>; TLS List <[e-mail]>
> *Subject:* RE: [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update
>
> *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.
>
> Hi Panos,
>
> On 02/03/2024 04:09, Kampanakis, Panos wrote:
>
>     Hi Dennis,
>
>     I created a git issue
>     https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but
>     I am pasting it here for the sake of the discussion:
>
>     What does the client do if the server only does Pass 1 and
>     compresses / omits the chain certs but does not compress the
>     end-entity certs (Pass 2)?
>
>     The client should be fine with that. It should be able to
>     reconstruct the chain and used the uncompressed end-entity cert.
>     It should not fail the handshake. I suggest the Implementation
>     Complexity Section to say something like
>
> I can see two different ways to handle it. Either as you suggest, we 
> have it be a runtime decision and we just prefix the compressed form 
> with a byte to indicate whether pass 2 has been used. Alternatively, 
> we can define two codepoints, (pass 1 + pass 2, pass 1).
>
> I'd like to experiment with both operations and measure what the real 
> world difference is first, then we can make a decision on how to 
> proceed. There's also been more interest in the non-webpki use case 
> than I expected, so that needs to factor in to whichever option we pick.
>
> Best,
> Dennis
>
>     /> Servers MAY chose to compress just the cert chain or the
>     end-certificate depending on their ability to perform Pass 1 or 2
>     respectively. Client MUST be able to process a compressed chain or
>     an end-entity certificate independently./
>
>     Thanks,
>
>     Panos
>
>     *From:* TLS <[e-mail]> <mailto:[e-mail]>
>     *On Behalf Of *Dennis Jackson
>     *Sent:* Friday, March 1, 2024 8:03 AM
>     *To:* TLS List <[e-mail]> <mailto:[e-mail]>
>     *Subject:* [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update
>
>     *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.
>
>     Hi all,
>
>     I wanted to give a quick update on the draft.
>
>     On the implementation side, we have now landed support for TLS
>     Certificate Compression in Firefox Nightly which was a
>     prerequisite for experimenting with this scheme (thank you to Anna
>     Weine). We're working on a rust crate implementing the current
>     draft and expect to start experimenting with abridged certs in
>     Firefox (with a server-side partner) ahead of IETF 120.
>
>     On the editorial side, I've addressed the comments on presentation
>     and clarification made since IETF 117 which are now in the editors
>     copy - there's an overall diff here [1] and atomic changes here
>     [2] . There are two small PRs I've opened addressing minor
>     comments by Ben Schwarz on fingerprinting considerations [3] and
>     Jared Crawford on the ordering of certificates [4]. Feedback is
>     welcome via mail or on the PRs directly.
>
>     Best,
>     Dennis
>
>     [1]
>     https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt
>     <https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt>
>
>     [2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/
>
>     [3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files
>
>     [4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls