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

[Kampanakis, Panos]

Good point, understood, thanks.

> 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.

I think the former sounds more reasonable. 2 codepoints for (only CA pass 1 
compression) and (Pass1+Pass2) seems to be wasting codepoints.

The problem I am trying to address is cases where 1/ SCTs are not available 
(like Private PKIs), or 2/ the server is lazy and does not want to create that 
dictionary, or 3/ the benefit of Pass 2 is not important enough. I understand 
that you will collect data for 3/ to hopefully prove it, so I will wait for 
those. But I think 1/ and 2/ are still worth addressing.


From: TLS  On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
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 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

But I thought retired people were supposed to sleep in?

From: TLS  On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cert-abridge Update

[External email]

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 
<mailto:ietf=40dennis-jackson...@dmarc.ietf.org>
Sent: Monday, March 4, 2024 10:47 AM
To: Kampanakis, Panos <mailto:kpa...@amazon.com>; TLS List 
<mailto:tls@ietf.org>
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 <mailto:tls-boun...@ietf.org> On Behalf Of 
Dennis Jackson
Sent: Friday, March 1, 2024 8:03 AM
To: TLS List <mailto:tls@ietf.org>
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 Wei

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

[Dennis Jackson]

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 
*Sent:* Monday, March 4, 2024 10:47 AM
*To:* Kampanakis, Panos ; TLS List 
*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  
*On Behalf Of *Dennis Jackson
*Sent:* Friday, March 1, 2024 8:03 AM
*To:* TLS List  
*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

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

[Kampanakis, Panos]

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?


From: Dennis Jackson 
Sent: Monday, March 4, 2024 10:47 AM
To: Kampanakis, Panos ; TLS List 
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  On Behalf Of 
Dennis Jackson
Sent: Friday, March 1, 2024 8:03 AM
To: TLS List 
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_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
TLS@ietf.org

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

[Dennis Jackson]

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  *On Behalf Of * Dennis Jackson
*Sent:* Friday, March 1, 2024 8:03 AM
*To:* TLS List 
*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_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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kampanakis, Panos]

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

> 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  On Behalf Of Dennis Jackson
Sent: Friday, March 1, 2024 8:03 AM
To: TLS List 
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_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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls