Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt

[Dennis Jackson]

Hey Ilari,

I think you are still misunderstanding the scheme. To clarify:

On 01/03/2024 18:01, Ilari Liusvaara wrote:

The unrecognized identifier issue is a bit more subtle.
Suppose that a client:

- Has only partial list of certificates (enough to cover the built-in
   trust store).
- Allows an admin to add a new trust anchor, or to override validation
   error.

Then such client can get into situation where server sends chain that
should be valid, but instead references a certificate the client does
not have. Which is a hard error.


As laid out in 3.1, this draft works with a fixed list of certificates. 
Clients cannot use the scheme if they are not willing to have a full 
list of the certificates. Clients can trust a superset or subset of 
roots that are present on the list, any certificates not in the fixed 
pass 1 list are simply not compressed in that pass. A key goal of this 
draft is not to risk any breakage (unlike with suppressing intermediates).


If you have any editorial feedback on where you think this part of the 
draft is unclear, suggestions are welcome. I'm not sure where you've got 
the idea that only partial lists of certificates are possible.


Best,
Dennis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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&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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-esni-18.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-esni-18.txt is now available. It is a work item
of the Transport Layer Security (TLS) WG of the IETF.

   Title:   TLS Encrypted Client Hello
   Authors: Eric Rescorla
Kazuho Oku
Nick Sullivan
Christopher A. Wood
   Name:draft-ietf-tls-esni-18.txt
   Pages:   51
   Dates:   2024-03-04

Abstract:

   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-18

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-esni-18

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [TLS] Trust Expressions Follow-up

[Orie Steele]

Thanks for your thoughtful reply.

Inline:

On Sat, Mar 2, 2024 at 9:21 PM David Benjamin  wrote:

> Hi Orie,
>
> Thanks for the note! I'm not very familiar with the SCITT work, so I can't
> speak to it directly. But perhaps I can try to describe what we're trying
> to achieve for TLS, and that might help you determine whether it applies to
> SCITT?
>
> We're looking here to address problems caused by single-certificate
> deployment models in TLS. In an ecosystem where one server may serve many
> diverse clients (ranging from evergreen browsers, to decade-old TV set-top
> boxes) with different requirements, that deployment model results in a ton
> of conflicts as the PKI evolves to meet user security needs. The first
> message in this thread, and this document
>  try
> to describe the problem and goals a bit.
>
> TLS, being an online protocol, lends itself well to negotiation-based
> solutions (we do it for cipher suites, etc.), where the server has multiple
> certificates available and then somehow the client and server are able to
> determine which to use. Trust expressions aim to provide that "somehow".
> The manifests business is purely a supporting structure to get there, since
> we need to be able to succinctly describe what are fairly large lists of
> trusted CAs in many PKIs. If there isn't an analogous deployment problem or
> online protocol in SCITT, the work probably isn't directly applicable.
>

I think the SCITT analog here is managing code signing certs when trying to
verify a software bill of materials that covers both public and private CAs.


> I didn't quite follow the transparency service comments (this may be my
> unfamiliarity with SCITT again), but this draft isn't trying to change PKI
> structure. Or rather, it isn't trying to do so directly. Having a robust
> negotiation mechanism *enables* us to explore structural changes. I do
> think that will be valuable, as post-quantum dramatically changes some
> trade-offs here. (Signatures and keys are now *huge*.*)* E.g. there's the
> intermediate elision use case you noted. But that one isn't related to
> transparency and is simply observing that intermediate elision and
> short-lived trust anchors are the same thing.
>

This sorta lines up with the current solutions for short lived certs seen
in the wild today, such as Sigstore.

Is proving possession of an email address good enough to sign software?

What about scenarios with MFA, CI systems with certificates for each build
server, with HSM keys... etc.

It seems that there might be some conceptual alignment on "these certs for
this name, on these timescales", even if the certs are used for different
things.

SCITTs focus is to provide an access controlled audit log for details
related to the software supply chain.

I'm still trying to wrap my head around how
draft-davidben-tls-trust-expr maps to the CT use case (
https://datatracker.ietf.org/doc/rfc9162/), or how they might be related in
an ideal setting.

It seems like SCITT Receipts for a trust expression manifest might be a
thing, assuming you are trying to reason about which trust store manifests
that are used by a 3rd party, without the ability to talk to them
directly... Perhaps that's a "SCITT can help you audit how a trust store
was used" use case... or... maybe trust expressions help SCITT auditors
make quick sense of SCITT Receipts from PKIs that have aging identities
co-mingled with new ones, which seems to be common in software supply
chains.


> We do have another draft, draft-davidben-tls-merkle-tree-certs, which
> explores a much more differently structured PKI, aiming to fit with how the
> Web PKI currently does transparency. Though we wrote that draft first and
> have not yet had time to rebase it atop trust expressions. There are
> probably other data points in this design space too, and I hope certificate
> negotiation will help us find the right ones for various use cases.
>

 Skimming the draft you mentioned, perhaps this is also a point of overlap
between your 2 drafts and the SCITT architecture:

https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs-01#section-10.3

You might build a "Merkle Tree certificate", using a SCITT transparency
service, since a SCITT receipt is logically an inclusion proof for a single
certificate,

A "signed feed of receipts" can be thought of as an intermediate data
structure for Merkle tree certs... possibly... I need more time to digest
the draft.

Thanks for your comments.


> David
>
> On Fri, Mar 1, 2024 at 6:39 PM Orie Steele 
> wrote:
>
>> I found the CDDL in the appendix intriguing:
>>
>>
>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#appendix-A
>>
>> In SCITT, we've been kicking around a related concept...
>> It's had several names, all of which have led to confusion, so I will not
>> repeat them here, but I want to overlay how they have been re

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&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
TLS@ietf.org
ht