Subject: Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

From: "Kampanakis, Panos" <[email-masked]>
Date: Mon, 14 Feb 2022 03:33:05 +0000

Hi TLS WG,

This draft draft-kampanakis-tls-scas-latest is attempting to resurrect Martin’s original draft-thomson-tls-sic. It proposes using two new TLS 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or client to not send its Intermediate CA (ICA) certificates. 

It assumes that we can pre-cache or load all the necessary intermediate CAs in order to build the cert chains to authenticate peers. As a data point, the size of a full ICA cache for the web would be 1-2MB (1-2 thousand ICAs) based on testing and 3rd party data [7][8]. 1-2MB is trivial for most usecases. When it is not, other caching mechanisms can be used. 

The main usecases that would benefit from this would be 
- post-quantum (D)TLS (PQ certs are going to be big and thus introduce issues for (D)TLS and QUIC [1][2][3][4]).
- EAP-TLS in cases with big cert chains [5][6]
- constrained environments where even a few KB in a (D)TLS handshake matter

We believe we have addressed the comments regarding the original draft https://mailarchive.ietf.org/arch/browse/tls/?q=draft-thomson-tls-sic  

Feedback and discussion are welcome. 

Rgs,
Panos

[1] https://blog.cloudflare.com/sizing-up-post-quantum-signatures/   
[2] https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/  
[3] https://dl.acm.org/doi/10.1145/3386367.3431305 
[4] https://assets.amazon.science/00/f8/aa76ff93472d9b55b6a84716e34c/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates.pdf 
[5] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert 
[6] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13 
[7] https://github.com/FiloSottile/intermediates  
[8] https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport  

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 13, 2022 2:34 PM
To: Bas Westerbaan <[email-masked]>; Bytheway, Cameron <[email-masked]>; Martin Thomson <[email-masked]>; Kampanakis, Panos <[email-masked]>
Subject: [EXTERNAL] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt

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.

A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt
has been successfully submitted by Panos Kampanakis and posted to the IETF repository.

Name:           draft-kampanakis-tls-scas-latest
Revision:       00
Title:          Suppressing CA Certificates in TLS 1.3
Document date:  2022-02-13
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest

Abstract:
   A TLS client or server that has access to the complete set of
   published intermediate certificates can inform its peer to avoid
   sending certificate authority certificates, thus reducing the size of
   the TLS handshake.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Feb 2022 09:42:31 +0200

On Mon, Feb 14, 2022 at 03:33:05AM +0000, Kampanakis, Panos wrote:
> Hi TLS WG,
> 
> This draft draft-kampanakis-tls-scas-latest is attempting to resurrect
> Martin’s original draft-thomson-tls-sic. It proposes using two new TLS
> 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or
> client to not send its Intermediate CA (ICA) certificates. 
> 

Some quick comments:

1) There are a few "shall" in the text. Should those be "SHALL"?

2) Section 3.2:

"To prevent a failed TLS connection, a client could chose to not send
its intermediates regardless of the flag from the server, if it has a
reason to believe the issuing CAs do not exist in the server ICA
list." 

... Shouldn't the client send its intermediates if it thinks the server
does not have them.

3) Why there are two flags? I do not see a case where both would be
sent in the same message.

4) In WebPKI, there are some cornercases (constrained ICAs) where the
client might be missing a certificate or certificates in the chain.
Currently the WebPKI root program rules allow not disclosing
"technically constrained" certificates (but there are plans to change
this).

5) In the client auth scenario, the server might have exhaustive
list of all issuing ICAs it accepts, so including any ICAs is never
necressary. However, this might be handled even currently by not
giving the client a chain. However, doing this in other direction
can be quite dangerous without prior agreement.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 14 Feb 2022 11:43:12 -0500

Hi Panos,

There was additionally some discussion during IETF 105 [1], which looked a
bit about the problem.

As a problem statement, it's definitely an interesting problem, and
certainly, one we need to start preparing to solve practically. I think one
very direct question is this: If we are confident that the client and
server have negotiated some shared trust bundle reliably, why would we use
intermediates at all? That is, if a given client knows a certificate path
such that Root->Intermediate 1->Intermediate 2 exists, sufficient that it
can be omitted within the TLS exchange and only send End Entity, then how
is that functionally different than simply saying "Intermediate 2" is the
Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6) for
Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for validating
End Entity? What value does "Intermediate 1", or "Root 1", serve from a
protocol or conceptual layer?

This might sound too abstract, but I think highlights the core concept of
the proposal, which is that certificate path building and validation become
unnecessary in a scheme where we're eliding intermediates. In the original
deployment model of TLS using X.509, the certificates sent were simply
pointers into the X.500 Directory. Of course, we all know that didn't
manifest, and we certainly don't depend on the Directory, and so we used
the certificate chains provided in-band to communicate trust in a world
where the Directory doesn't exist. The flags proposal, in effect, is
introducing the notion of a "static Directory" - such as the examples you
pointed to of Mozilla's CSV output or Filippo's consolidation of that
output.

I realize this suggests a much larger change to the trust model we've
inherited from Netscape's snap decisions 25 years ago, but given PQ, does
it make sense to re-examine whether or not we need such intermediates at
all? That is, if we're willing to say "This is signed by Intermediate 2,
and you're expected to know about it and its limitations", how is this
different from saying "This is signed by Trust Anchor Foo, and you're
expected to know about it and its limitations". I'm not suggesting online
signing by roots, but rather, that this extension firmly rejects the "trust
roots, discover intermediates" model of 1996, so why shouldn't we lean into
this more for PQ?

I'm not sure I see addressed in the draft how it handles the problem
previously raised on the mic [1] and on the list [2], regarding version
skew problems. Section 3.1 of the draft states "To prevent a failed TLS
connection, a client MAY choose not to send the flag if its list of ICAs
hasn't been updated in TBD3 time or has any other reason to believe it does
not include the ICAs for the peer", but this leaves a lot open to
interpretation. For example, is it expected that clients will retry the
connection, as suggested in [3]? That seems to be the suggestion from 3.1's
"If the connection still fails ... the client MUST NOT send the flag in a
subsequent connection to the server". Or is this meant to be left
unspecified, similar to Section 3's "It is beyond the scope of this
document to define how CA certificates are identified and stored"? It seems
rather fundamental to the assessment of the proposal to understand the
proposed client behaviours here.

A significant amount of practicality for this proposal rests on what the
value for TBD3 is. For example, if this is seen as the only practically
viable (at Internet scale) way to deploy PQ, then we should presume that a
failure for the client to have a fresh set is, effectively, a failure to
communicate with a site that needs such a fresh set. Have I misunderstood
the conclusions of your research [4]?

If this is functionally necessary for certain deployments, then the choice
of TBD3 is a reflection of "How long do servers/CAs need to wait, before a
newly provisioned intermediate becomes practically deployable"? When
Certificate Transparency (RFC 6962) examined a similar question, the
suggestion by CAs then was that 24 hours (the proposed CT MMD for direct
integration into the log) was untenable, and thus SCTs, the "immediate
promise to log, without proof of having been integrated into the Merkle
tree", were introduced. Ilari's point about technically constrained
subordinates is related to this; even for those not constrained, today's
ecosystem has them functionally usable immediately, and disclosure is not
required for week(s) after by policies, if at all. The choice of TBD3 is
both a reflection of, and an expectation of, broader ecosystem behaviours
and changes, but which are left somewhat minimally specified, and which
seems rather substantial.

The current draft doesn't address the question about how "The Web PKI" is
not a comprehensive set of all CAs, but rather, an overlapping/intersecting
set from independent vendors. This raises practical questions about
deployability, because it speaks a bit to trust anchor agility within these
applications. For example, Vendor A supports Root 1 -> Intermediate 1 ->
Intermediate 2, with Root 1 in their trust store. Vendor B supports Root 2
-> (Cross-Signed) Root 1 -> Intermediate 1 -> Intermediate 2, with Root 2
in their trust store, and Root 1 not included. The semantics of "omit
intermediates", and what precisely is being elided, effectively rests on
unknown client configuration. The Section 3 [EDNOTE] seems to acknowledge
this, in that there are a host of trade-offs at play, all of which require
some degree of client state to be communicated to the server. This is
alluded to by saying, in Section 3.1, "a server could choose not to send
its intermediates regardless of the flag from the client, if it has reason
to believe the issuing CAs do not exist in the client ICA list", but
without reference to how practically that would be determined.

During the IETF 105 discussion, there was some discussion about "CCADB
version" during the mic discussion, as one way of approaching an
agreed-upon definition/registry for a set of certificates, but which would
only be applicable to a particular user community. The draft here
highlights three variations that all serve as a form of cookie
(Fingerprint, HMAC, Ticket). While these might be viable for some use
cases, some of the large-scale deployment concerns would be the increasing
effort to segment and isolate forms of network traffic between origins
within browsers, and to limit the lifetime of tracking tickets. This
already had some discussion during the cross-sni-resumption, which shares a
similar state overlap, but it may be worth exploring how well the
amortization here works when faced under "real world" conditions (of
multiple parallel connections racing, isolated between different security
principals/origins, with limited lifetimes).

Within a wholly constrained environment, such as IoT, in which the operator
of both TLS peers functionally has perfect knowledge of the PKI in use,
these issues are not a consideration, and so it's understandably compelling
there. But, in such a scenario, they can already account for this by just
eliding intermediates today without requiring negotiation. Negotiating via
flags comes in when both parties don't have perfect knowledge or consistent
configuration between each other, but functionally, if they negotiate the
flag, we're requiring that they do have perfect knowledge. That's why I'm
still a little uneasy about this proposal, not because I think it's
inherently unworkable, but because there's a lot of devil in the details
here that are much broader, in practice, than just specifying a flag. I'd
love to make sure we've got some understanding for practical deployments of
this, or else I can see this being an interop nightmare in deployment.

[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-tls-00
[2] https://mailarchive.ietf.org/arch/msg/tls/KAAKiEki36gL8g40ZimNHk39OXY/
[3] https://mailarchive.ietf.org/arch/msg/tls/sJ4vlchFfKtKqYDADdxwAWoR2ug/
[4]
https://www.amazon.science/publications/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Wed, 16 Feb 2022 05:45:47 +0000

Good comments, thank you Ilari. 

To answer your comments  

> 1) There are a few "shall" in the text. Should those be "SHALL"?

The two "shall" refer to draft-ietf-tls-tlsflags. Based on experience from previous drafts, we do not want to repeat normative language from another draft, so we kept them lowercase. We can still consider making them normative though. 

> 2) Section 3.2: "To prevent a failed TLS connection, a client could chose to not send its intermediates regardless of the flag from the server, if it has a reason to believe the issuing CAs do not exist in the server ICA list."
> ... Shouldn't the client send its intermediates if it thinks the server does not have them. 

You are right. Nit. We will fix it. I created issue https://github.com/csosto-pk/tls-suppress-intermediates/issues/5 for it. 

> 3) Why there are two flags? I do not see a case where both would be sent in the same message.

In the original draft there was only one. But we want for both the client and server (CertReq) to be able to signal to their peer to suppress CAs. draft-ietf-tls-tlsflags defines that the peer needs to acknowledge the flag, thus we needed one per direction. 

> 4) In WebPKI, there are some cornercases (constrained ICAs) where the client might be missing a certificate or certificates in the chain.
> Currently the WebPKI root program rules allow not disclosing "technically constrained" certificates (but there are plans to change this).

Good point. That has come up in discussions with my co-authors. As Martin was pointing out, a lot hinges on the semantics of the tls_flags bit.  We probably can say that it means "I have all the intermediates I am willing to accept".  That's a little too absolute for the web PKI as it stands. We don't have stats on how often we'd fail as a result; we would have to check but unconstrained intermediates probably isn't exceptional. The flag should probably say "I have all the *unconstrained* intermediates that I'm willing to accept" or maybe "I have all the intermediates from that I'm willing to accept, unless it's the WebPKI and then I only have unconstrained intermediates"' 

But if MSRP 2.8 adds constrained intermediates, then "I have all the intermediates I am willing to accept" may just suffice. 

I created issue https://github.com/csosto-pk/tls-suppress-intermediates/issues/6  for this.

> 5) In the client auth scenario, the server might have exhaustive list of all issuing ICAs it accepts, so including any ICAs is never necressary. However, this might be handled even currently by not giving the client a chain. However, doing this in other direction can be quite dangerous without prior agreement.

I am not sure I am following that argument. If the client does not have a chain what happens if the server does not have all intermediates?

By quite dangerous do you mean that if they have not pre-agreed on the ICA list there could be an auth failure and recovery will not be easy because the server can't track the clients it is expecting ICAs from? Am I getting you right? 

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Ilari Liusvaara
Sent: Monday, February 14, 2022 2:43 AM
To: [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Mon, Feb 14, 2022 at 03:33:05AM +0000, Kampanakis, Panos wrote:
> To: Bas Westerbaan <[email-masked]>; Bytheway, Cameron 
> <[email-masked]>; Martin Thomson <[email-masked]>; Kampanakis, 
> Panos <[email-masked]>

Some quick comments:

2) Section 3.2:

"To prevent a failed TLS connection, a client could chose to not send its intermediates regardless of the flag from the server, if it has a reason to believe the issuing CAs do not exist in the server ICA list."

... Shouldn't the client send its intermediates if it thinks the server does not have them.

3) Why there are two flags? I do not see a case where both would be sent in the same message.

4) In WebPKI, there are some cornercases (constrained ICAs) where the client might be missing a certificate or certificates in the chain.
Currently the WebPKI root program rules allow not disclosing "technically constrained" certificates (but there are plans to change this).

5) In the client auth scenario, the server might have exhaustive list of all issuing ICAs it accepts, so including any ICAs is never necressary. However, this might be handled even currently by not giving the client a chain. However, doing this in other direction can be quite dangerous without prior agreement.

-Ilari

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Feb 2022 13:26:31 +0200

On Wed, Feb 16, 2022 at 05:45:47AM +0000, Kampanakis, Panos wrote:
> The two "shall" refer to draft-ietf-tls-tlsflags. Based on experience
> from previous drafts, we do not want to repeat normative language
> from another draft, so we kept them lowercase. We can still consider
> making them normative though. 

I think the language in tlsflags about acknowledging extensions is
confusing. Tlsflags behavior should be similar to extensions, which do
not have acknowledgment requirement in base TLS (any acknowledgement
requirement is per extension). So I think any acknowledgement
requirement should be explicitly stated normatively.

As to why I find tlsflags language confusing: I think flags as
shorthand for empty extensions, and TLS extensions can be capability
advertisments (no reply). E.g., compress_certificate, which happens
to add a new HandshakeType.

> In the original draft there was only one. But we want for both the
> client and server (CertReq) to be able to signal to their peer to
> suppress CAs. draft-ietf-tls-tlsflags defines that the peer needs to
> acknowledge the flag, thus we needed one per direction. 

There are no less than four existing TLS extensions (and flags work
similarly to extensions), which work in both directions with the
same codepoint, in the IANA registry:

- status_request
- signed_certificate_timestamp
- delegated_credentials
- transparency_info

And there does not seem to be a percedent for extension that works in
both directions, but with different codepoints.

> > 4) In WebPKI, there are some cornercases (constrained ICAs) where
> > the client might be missing a certificate or certificates in the
> > chain. Currently the WebPKI root program rules allow not disclosing
> > "technically constrained" certificates (but there are plans to
> > change this).
> 
> Good point. That has come up in discussions with my co-authors. As
> Martin was pointing out, a lot hinges on the semantics of the
> tls_flags bit.  We probably can say that it means "I have all the
> intermediates I am willing to accept".  That's a little too absolute
> for the web PKI as it stands. We don't have stats on how often we'd
> fail as a result; we would have to check but unconstrained
> intermediates probably isn't exceptional. The flag should probably
> say "I have all the *unconstrained* intermediates that I'm willing
> to accept" or maybe "I have all the intermediates from that I'm
> willing to accept, unless it's the WebPKI and then I only have
> unconstrained intermediates"' 

I would expect constrained intermediates to be quite rare. IIRC, there
is a lot of red tape in Baseline Requirements about constrained ICAs.

> But if MSRP 2.8 adds constrained intermediates, then "I have all the
> intermediates I am willing to accept" may just suffice. 

MSRP 2.8 is slated for this year, so it might very well fix this issue
for WebPKI.

Another way to address the issue would be to write some text that the
server might want to send any ICA that has not been publically
disclosed. As that is neutral to PKI and is exactly what makes
constrained ICAs problematic here.

> I am not sure I am following that argument. If the client does not
> have a chain what happens if the server does not have all
> intermediates?

Sending ICA will not help: The authentication would still fail.

But actually, if using public PKI certificates for client auth (usually
not a great idea), then this can fail rather badly with legacy servers
that do not have issuing ICA lists at all.

> By quite dangerous do you mean that if they have not pre-agreed on
> the ICA list there could be an auth failure and recovery will not
> be easy because the server can't track the clients it is expecting
> ICAs from? Am I getting you right? 

The problem is legacy clients. If one of those connects to the server
and server omits the chain, that will cause handshake failure.

Unfortunately, currently there are fair amount of misconfigured servers
that behave this way.

-Ilari

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Wed, 16 Feb 2022 19:41:11 +0000

Thanks for the insightful comments Ryan.

Some responses below (sorry long email):

> how is that functionally different than simply saying "Intermediate 2" is the Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6) for Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for validating End Entity? What value does "Intermediate 1", or "Root 1", serve from a protocol or conceptual layer?

Agreed, it is not different. But I believe adding Intermediates to the trust bundle is less straightforward to be deployed everywhere especially when expanding the scope to many more CAs. Note that the draft does not consider the ICA list a trust list. It is just a list to build the chain. There is some text in the draft trying to convey that.

> The flags proposal, in effect, is introducing the notion of a "static Directory" - such as the examples you pointed to of Mozilla's CSV output or Filippo's consolidation of that output.

Agreed. But although the directory option is the most straightforward option, there is a dynamic cache building element too. I have experimented with this a bit; someone may not even need a full ICA list. It could build its cache dynamically as it starts connecting to peers. If it has not seen the peer before it caches its ICAs the first time. And uses an update algorithm when the cache is full and has a new cache miss. [4] has some basic details about this. Admittedly that is the less straightforward and probably less common option. I added some text in the draft to reflect both options, but we do not want to define how the ICAs get discovered. We just want the peer to declare “I somehow know my peer ICAs”.

> I'm not suggesting online signing by roots, but rather, that this extension firmly rejects the "trust roots, discover intermediates" model of 1996, so why shouldn't we lean into this more for PQ?

Good point. I think the challenge is the significant scope change as you are suggesting because now you are supposed to vet and somehow trust many more CAs that don’t have their key offline like roots do. Generally, significant changes like that scare me. Also let’s not forget the challenges of having the TLS client say “if PQ, do PKI differently, else keep the Netscape model”.

> I'm not sure I see addressed in the draft how it handles the problem previously raised on the mic [1] and on the list [2], regarding version skew problems. [...] It seems rather fundamental to the assessment of the proposal to understand the proposed client behaviours here.

To summarize, you had it right. If the client thinks it has the ICAs it signals it. If the connection fails, it tries again without suppression. The cache is acquired either statically from CCADB or some vendor or service somewhere, or by building a dynamic cache as explained above.

> For example, if this is seen as the only practically viable (at Internet scale) way to deploy PQ, then we should presume that a failure for the client to have a fresh set is, effectively, a failure to communicate with a site that needs such a fresh set.

It is not the only option, but we consider this as low hanging fruit that trims the PQ data sent in the handshake by a good amount. Here is the PQ Auth data (in MB) from the server without suppression
And this is the same data with suppression

There have been more proposals like KEMTLS, or using different algorithm (smaller signature, bigger public key) in the SCT, OCSP staple or Root CA, or using CRLite and saving one extra OCSP signature. These do trim the data as well. But they also introduce significant changes or may not be viable depending on the standardized options. So, we consider the ICA suppression option as relatively straightforward, low hanging fruit.

I would rephrase it to “a failure to have a fresh set means not taking advantage of the faster handshake with ICAs suppressed”.

> The choice of TBD3 is both a reflection of, and an expectation of, broader ecosystem behaviours and changes, but which are left somewhat minimally specified, and which seems rather substantial.

Agreed. We need to crisp up TBD3. We think that with CT and, say, two day's grace, a client that requires SCTs can actually be sure that its chosen set of intermediates will do. No need for CCADB for that usecase. But you are right we need expand on TBD3.

> This is alluded to by saying, in Section 3.1, "a server could choose not to send its intermediates regardless of the flag from the client, if it has reason to believe the issuing CAs do not exist in the client ICA list", but without reference to how practically that would be determined.

Yeah, we could work on the text there. Basically if the server knows it got a cert from new ICA which is likely to not exist in the list it could just send the chain. Or if there is a special Private PKI usecase where the server changed ICAs and the clients will not know because they are not configured yet, it could do that as well. I created issue https://github.com/csosto-pk/tls-suppress-intermediates/issues/7  to track this.

> This already had some discussion during the cross-sni-resumption, which shares a similar state overlap, but it may be worth exploring how well the amortization here works when faced under "real world" conditions (of multiple parallel connections racing, isolated between different security principals/origins, with limited lifetimes).

Yes, good comment. We had discussed these with co-authors. We are not convinced that the ticket or any of the other options are worth it. We would need more data to substantiate it. That is why we have the EDNOTE in the draft.

> But, in such a scenario, they can already account for this by just eliding intermediates today without requiring negotiation. Negotiating via flags comes in when both parties don't have perfect knowledge or consistent configuration between each other, but functionally, if they negotiate the flag, we're requiring that they do have perfect knowledge.

Anecdotally, in previous work I had done in WiSUN and 802.15.4, we were going to extensive lengths to pre-provision endpoints with CAs before deploying. But I see these constrained / IoT usecases to easily fit the dynamic cache category. These PKIs usually have 1-2 ICAs max. That cache can be very trivially built and maintained dynamically without perfect previous knowledge.

Rgs,
Panos

From: TLS <[email-masked]> On Behalf Of Ryan Sleevi
Sent: Monday, February 14, 2022 11:43 AM
To: Kampanakis, Panos <kpanos=[email-masked]>
Cc: Bytheway, Cameron <[email-masked]>; [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

Hi Panos,

There was additionally some discussion during IETF 105 [1], which looked a bit about the problem.

As a problem statement, it's definitely an interesting problem, and certainly, one we need to start preparing to solve practically. I think one very direct question is this: If we are confident that the client and server have negotiated some shared trust bundle reliably, why would we use intermediates at all? That is, if a given client knows a certificate path such that Root->Intermediate 1->Intermediate 2 exists, sufficient that it can be omitted within the TLS exchange and only send End Entity, then how is that functionally different than simply saying "Intermediate 2" is the Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6) for Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for validating End Entity? What value does "Intermediate 1", or "Root 1", serve from a protocol or conceptual layer?

This might sound too abstract, but I think highlights the core concept of the proposal, which is that certificate path building and validation become unnecessary in a scheme where we're eliding intermediates. In the original deployment model of TLS using X.509, the certificates sent were simply pointers into the X.500 Directory. Of course, we all know that didn't manifest, and we certainly don't depend on the Directory, and so we used the certificate chains provided in-band to communicate trust in a world where the Directory doesn't exist. The flags proposal, in effect, is introducing the notion of a "static Directory" - such as the examples you pointed to of Mozilla's CSV output or Filippo's consolidation of that output.

I realize this suggests a much larger change to the trust model we've inherited from Netscape's snap decisions 25 years ago, but given PQ, does it make sense to re-examine whether or not we need such intermediates at all? That is, if we're willing to say "This is signed by Intermediate 2, and you're expected to know about it and its limitations", how is this different from saying "This is signed by Trust Anchor Foo, and you're expected to know about it and its limitations". I'm not suggesting online signing by roots, but rather, that this extension firmly rejects the "trust roots, discover intermediates" model of 1996, so why shouldn't we lean into this more for PQ?

I'm not sure I see addressed in the draft how it handles the problem previously raised on the mic [1] and on the list [2], regarding version skew problems. Section 3.1 of the draft states "To prevent a failed TLS connection, a client MAY choose not to send the flag if its list of ICAs hasn't been updated in TBD3 time or has any other reason to believe it does not include the ICAs for the peer", but this leaves a lot open to interpretation. For example, is it expected that clients will retry the connection, as suggested in [3]? That seems to be the suggestion from 3.1's "If the connection still fails ... the client MUST NOT send the flag in a subsequent connection to the server". Or is this meant to be left unspecified, similar to Section 3's "It is beyond the scope of this document to define how CA certificates are identified and stored"? It seems rather fundamental to the assessment of the proposal to understand the proposed client behaviours here.

A significant amount of practicality for this proposal rests on what the value for TBD3 is. For example, if this is seen as the only practically viable (at Internet scale) way to deploy PQ, then we should presume that a failure for the client to have a fresh set is, effectively, a failure to communicate with a site that needs such a fresh set. Have I misunderstood the conclusions of your research [4]?

If this is functionally necessary for certain deployments, then the choice of TBD3 is a reflection of "How long do servers/CAs need to wait, before a newly provisioned intermediate becomes practically deployable"? When Certificate Transparency (RFC 6962) examined a similar question, the suggestion by CAs then was that 24 hours (the proposed CT MMD for direct integration into the log) was untenable, and thus SCTs, the "immediate promise to log, without proof of having been integrated into the Merkle tree", were introduced. Ilari's point about technically constrained subordinates is related to this; even for those not constrained, today's ecosystem has them functionally usable immediately, and disclosure is not required for week(s) after by policies, if at all. The choice of TBD3 is both a reflection of, and an expectation of, broader ecosystem behaviours and changes, but which are left somewhat minimally specified, and which seems rather substantial.

The current draft doesn't address the question about how "The Web PKI" is not a comprehensive set of all CAs, but rather, an overlapping/intersecting set from independent vendors. This raises practical questions about deployability, because it speaks a bit to trust anchor agility within these applications. For example, Vendor A supports Root 1 -> Intermediate 1 -> Intermediate 2, with Root 1 in their trust store. Vendor B supports Root 2 -> (Cross-Signed) Root 1 -> Intermediate 1 -> Intermediate 2, with Root 2 in their trust store, and Root 1 not included. The semantics of "omit intermediates", and what precisely is being elided, effectively rests on unknown client configuration. The Section 3 [EDNOTE] seems to acknowledge this, in that there are a host of trade-offs at play, all of which require some degree of client state to be communicated to the server. This is alluded to by saying, in Section 3.1, "a server could choose not to send its intermediates regardless of the flag from the client, if it has reason to believe the issuing CAs do not exist in the client ICA list", but without reference to how practically that would be determined.

During the IETF 105 discussion, there was some discussion about "CCADB version" during the mic discussion, as one way of approaching an agreed-upon definition/registry for a set of certificates, but which would only be applicable to a particular user community. The draft here highlights three variations that all serve as a form of cookie (Fingerprint, HMAC, Ticket). While these might be viable for some use cases, some of the large-scale deployment concerns would be the increasing effort to segment and isolate forms of network traffic between origins within browsers, and to limit the lifetime of tracking tickets. This already had some discussion during the cross-sni-resumption, which shares a similar state overlap, but it may be worth exploring how well the amortization here works when faced under "real world" conditions (of multiple parallel connections racing, isolated between different security principals/origins, with limited lifetimes).

Within a wholly constrained environment, such as IoT, in which the operator of both TLS peers functionally has perfect knowledge of the PKI in use, these issues are not a consideration, and so it's understandably compelling there. But, in such a scenario, they can already account for this by just eliding intermediates today without requiring negotiation. Negotiating via flags comes in when both parties don't have perfect knowledge or consistent configuration between each other, but functionally, if they negotiate the flag, we're requiring that they do have perfect knowledge. That's why I'm still a little uneasy about this proposal, not because I think it's inherently unworkable, but because there's a lot of devil in the details here that are much broader, in practice, than just specifying a flag. I'd love to make sure we've got some understanding for practical deployments of this, or else I can see this being an interop nightmare in deployment.

[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-tls-00
[2] https://mailarchive.ietf.org/arch/msg/tls/KAAKiEki36gL8g40ZimNHk39OXY/
[3] https://mailarchive.ietf.org/arch/msg/tls/sJ4vlchFfKtKqYDADdxwAWoR2ug/
[4] https://www.amazon.science/publications/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Feb 2022 09:45:31 +1100

> requirement should be explicitly stated normatively.

I agree with Ilari here.  We shouldn't need to acknowledge this extension.  And, as far as I can tell, the flags draft doesn't require it (though I admit that the text there on binary AND is confusing).

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 16 Feb 2022 22:36:23 -0500

> Some responses below (sorry long email):

No worries, I think this invites some long responses, in part, because it's
complex.

> > how is that functionally different than simply saying "Intermediate 2"
> is the Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6)
> for Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for
> validating End Entity? What value does "Intermediate 1", or "Root 1", serve
> from a protocol or conceptual layer?
>
>
>
> Agreed, it is not different. But I believe adding Intermediates to the
> trust bundle is less straightforward to be deployed everywhere especially
> when expanding the scope to many more CAs. Note that the draft does not
> consider the ICA list a trust list. It is just a list to build the chain.
> There is some text in the draft trying to convey that.
>

I don't think I communicated this well then. Although this is trying to do
something simple (in as much as treating the TLS and PKI layers distinct),
I think it's missing that it's shifting a significant portion of that
problem to PKI layer (re: synchronizing those ICAs), and also introducing
complexity to the TLS layer (re: fallbacks and retries). If the problem
statement is primarily oriented around PQ, then perhaps it's better to
explore a solution that tries to keep both layers simple.

Basically, it needs to be a little crisper what the client capabilities
are. Presently, it handwaves them as out-of-scope, but as a consequence,
makes it difficult to justify the assumptions/complexity that they hide.
Does the client have durable storage (e.g. does the IoT device need
rewritable media and not just ROM)? Does the client have a reliable (within
TBD3) out-of-band update mechanism for metadata such as intermediates? Is
the TLS implementation expected to be able to re-establish a connection
(which many TLS APIs are not themselves responsible for, or at least,
abstract that away)? These all affect the shape of the present design, but
also any simplifications.

> But although the directory option is the most straightforward option,
> there is a dynamic cache building element too. I have experimented with
> this a bit; someone may not even need a full ICA list. It could build its
> cache dynamically as it starts connecting to peers.
>

As you captured later, this is (effectively) reintroducing TLS fallback. We
worked very hard to try to minimize that, and while there are retries (ala
HRR), they're integrated into the connection state machine. Needing to
re-establish a new connection, sans flag, is a very big failure mode here,
and one that definitely influences the shape of API design.

Equally, this introduces some of the privacy risks that the EDNOTE was
trying to dodge. It seems like the choice to reintroduce "connection
re-establishment" logic would have bearing on the security and privacy
assumptions here, and is worth making sure it's captured.

Alternatively, if we take out this on-demand discovery piece, then we're
effectively saying "Clients need a reliable update channel for this to
work". Which may be a reasonable thing, but equally, it opens up the realm
for simplifications, as discussed above and below here.

> <snip> We just want the peer to declare “I somehow know my peer ICAs”.
>

Right, the criticism in the past is that it's not "I somehow know", but
rather, "I *think* I know my peer's CAs", with some probability of being
wrong. The what to do when things are wrong is important, and realizing
that different peers may be more or less wrong (e.g. depending on update
cadences) has a significant impact on deployability.

>
> > I'm not suggesting online signing by roots, but rather, that this
> extension firmly rejects the "trust roots, discover intermediates" model of
> 1996, so why shouldn't we lean into this more for PQ?
>
>
>
> Good point. I think the challenge is the significant scope change as you
> are suggesting because now you are supposed to vet and somehow trust many
> more CAs that don’t have their key offline like roots do. Generally,
> significant changes like that scare me. Also let’s not forget the
> challenges of having the TLS client say “if PQ, do PKI differently, else
> keep the Netscape model”.
>

So, two responses.

- In your responses to Ilari, and your original message, there seems to be
some assumption that Mozilla policy is representative and reflective of
what's possible here (c.f. disclosures). As much as I love and have
actively contributed to that policy, I'm also uncomfortable with using it
as a stand-in for the Web PKI or generalizations. That said, because you
were willing to lean on it regarding constrained intermediates, then it
should be clear that the "vet and trust more CAs" has already been a part
of the policy for some time. Every intermediate is subjected to the same
policies, the purpose of disclosure of said intermediates was intentionally
to support that vetting first and foremost, and any new intermediates are
equally subjected to that vetting. So if your response was meant to capture
"This is difficult", then it's overlooking "This is already being
done/required".

- This model is, explicitly, proposing to "do PKI differently", but perhaps
in ways that are subtle. This introduces, albeit intentionally does not
specify, the problem of determining what exactly those intermediates are,
and in a way (within the TBD3 timeframe) of synchronizing those widely to
clients. Equally, it's being proposed precisely because "For PQ, we need to
do PKI differently". So it doesn't seem an unreasonable step here.

As I said, I don't disagree with the goals, but I think one of the concerns
is that this tries a patch solution, but does so in ways that introduces
problematic dependencies/assumptions, and my previous reply was trying to
tease those out a little so that they're explicit as to what was considered
and/or rejected.

For example, the concern of "trust many more CAs that don't have their key
offline like roots do" misses that in the absence of a functioning
revocation system, we already trust those intermediates just as much as we
trust those roots, and with the same risks. This is why browsers, at least,
have developed systems of "revocation suppression" - by having the client
already know about revocation of intermediates apriori (CRLSets, Valid,
OneCRL/CRLLite, etc). In order for intermediate suppression to be
functionally viable, you need that out-of-band delivery mechanism (and yes,
I'm counting build-as-you-go as OOB). So the distinction here of
online/offline is, in a model that assumes a reliable mechanism to discover
intermediates, one without a difference.

Unless we're willing to take those very large handshakes to also have
stapled OCSP responses, then whether it's through CRL fetching-and-batching
(which is, in many ways, an OOB delivery mechanism) or some vendor-supplied
mechanism like browsers', we're still saying "Clients need some reliable
way to fetch an external resource to update". And, if we're willing to say
that, then we introduce the opportunity for a lot of simplification here.

> There have been more proposals like KEMTLS, or using different algorithm
> (smaller signature, bigger public key) in the SCT, OCSP staple or Root CA,
> or using CRLite and saving one extra OCSP signature. These do trim the data
> as well. But they also introduce significant changes or may not be viable
> depending on the standardized options. So, we consider the ICA suppression
> option as relatively straightforward, low hanging fruit.
>

I'm not sure I would agree that a 3-8 MB handshake to preserve the status
quo is exactly low hanging fruit. This is where looking to see what can be
done to remove the necessity of those SCTs and OCSPs, rather than trying to
patch them into a PQ world. The viability of CT itself becomes more suspect
in a world of ginormous signatures, if only because monitors/auditors lose
the ability to effectively monitor, even if we had perfectly-efficient
in-band TLS delivery such as via caching/elision.

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Fri, 18 Feb 2022 04:47:09 +0000

Thx Ilary. 

ACK about the unconstrained CAs and the MSRP 2.8. I updated the git issue and we will address it in text. 

About the tlsflags, make sense. It would simplify things too. The impression I got from the old draft-thomson-tls-sic thread and the tlsflags draft was that it mandates an acknowledgement. I will confirm with Yoav. 

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, February 16, 2022 6:27 AM
To: Kampanakis, Panos <[email-masked]>
Cc: [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Wed, Feb 16, 2022 at 05:45:47AM +0000, Kampanakis, Panos wrote:
> from previous drafts, we do not want to repeat normative language from 
> another draft, so we kept them lowercase. We can still consider making 
> them normative though.

I think the language in tlsflags about acknowledging extensions is confusing. Tlsflags behavior should be similar to extensions, which do not have acknowledgment requirement in base TLS (any acknowledgement requirement is per extension). So I think any acknowledgement requirement should be explicitly stated normatively.

As to why I find tlsflags language confusing: I think flags as shorthand for empty extensions, and TLS extensions can be capability advertisments (no reply). E.g., compress_certificate, which happens to add a new HandshakeType.

> acknowledge the flag, thus we needed one per direction.

There are no less than four existing TLS extensions (and flags work similarly to extensions), which work in both directions with the same codepoint, in the IANA registry:

- status_request

And there does not seem to be a percedent for extension that works in both directions, but with different codepoints.

> intermediates probably isn't exceptional. The flag should probably say 
> "I have all the *unconstrained* intermediates that I'm willing to 
> accept" or maybe "I have all the intermediates from that I'm willing 
> to accept, unless it's the WebPKI and then I only have unconstrained 
> intermediates"'

I would expect constrained intermediates to be quite rare. IIRC, there is a lot of red tape in Baseline Requirements about constrained ICAs.

> intermediates I am willing to accept" may just suffice.

MSRP 2.8 is slated for this year, so it might very well fix this issue for WebPKI.

Another way to address the issue would be to write some text that the server might want to send any ICA that has not been publically disclosed. As that is neutral to PKI and is exactly what makes constrained ICAs problematic here.

But actually, if using public PKI certificates for client auth (usually not a great idea), then this can fail rather badly with legacy servers that do not have issuing ICA lists at all.

> By quite dangerous do you mean that if they have not pre-agreed on the 
> ICA list there could be an auth failure and recovery will not be easy 
> because the server can't track the clients it is expecting ICAs from? 
> Am I getting you right?

The problem is legacy clients. If one of those connects to the server and server omits the chain, that will cause handshake failure.

Unfortunately, currently there are fair amount of misconfigured servers that behave this way.

-Ilari

---

From: Bas Westerbaan <[email-masked]>
Date: Fri, 18 Feb 2022 11:59:34 +0100

> quo is exactly low hanging fruit.
>

If we use Dilithium2 for every signature, we're looking at about 17kB extra
— not 3-8MB. ICA suppression removes one public key and signature, so 3.7kB.

This is where looking to see what can be done to remove the necessity of
> those SCTs and OCSPs, rather than trying to patch them into a PQ world.
>

If Rainbow or GeMMS doesn't make the cut, then replacing SCTs by inclusion
proofs (to some daily picked side-loaded STHs) could be interesting (as
they're ~1kB each), but that's not low hanging fruit.

> The viability of CT itself becomes more suspect in a world of ginormous
> signatures,
>

Dilithium2 and Falcon signatures+public keys are 2.4+1.3kB and 666+897B
respectively. That won't cause trouble for CT.

Best,

 Bas

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Feb 2022 20:39:36 +0200

On Fri, Feb 18, 2022 at 04:47:09AM +0000, Kampanakis, Panos wrote:
> 
> About the tlsflags, make sense. It would simplify things too. The
> impression I got from the old draft-thomson-tls-sic thread and the
> tlsflags draft was that it mandates an acknowledgement. I will
> confirm with Yoav. 

The text in tlsflags looks like it mandates an acknowledgement,
but I think it might be just confusing text.

Regarding actual need for acknowledgement for this flag, I think that
server acknowledging it could be useful so client knows if retrying
without flag could be useful or not.

For the client acknowledging it, I find that much less useful. If
server proposes the extension, it better have exhaustive issuer
list, be using certificates as just holders for raw public keys,
or using certificate fingerprints for identification. Anything
else looks like it is asking for trouble.

-Ilari

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Fri, 18 Feb 2022 19:10:37 +0000

Makes sense. 

The thing to clarify if tlsflags should mandate an acknowledgement by default. Yoav confirmed that the spirit of the tlsflags draft currently is to require an acknowledgement.

I am tracking it here https://github.com/csosto-pk/tls-suppress-intermediates/issues/9 , but I think the WG needs to reach consensus on the default behavior. 

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, February 18, 2022 1:40 PM
To: Kampanakis, Panos <[email-masked]>
Cc: [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Fri, Feb 18, 2022 at 04:47:09AM +0000, Kampanakis, Panos wrote:
> tlsflags draft was that it mandates an acknowledgement. I will confirm 
> with Yoav.

The text in tlsflags looks like it mandates an acknowledgement, but I think it might be just confusing text.

Regarding actual need for acknowledgement for this flag, I think that server acknowledging it could be useful so client knows if retrying without flag could be useful or not.

For the client acknowledging it, I find that much less useful. If server proposes the extension, it better have exhaustive issuer list, be using certificates as just holders for raw public keys, or using certificate fingerprints for identification. Anything else looks like it is asking for trouble.

-Ilari

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Sat, 19 Feb 2022 03:59:23 +0000

Hi Ryan,

So, if can summarize and address your points:

- Pushing the problem to the PKI and TLS layers should be kept simple. Agreed.
- The probability of ICA being wrong affects deployability. Agreed.
- We ought to be clear about the ICA acquisition mechanisms, TBD3, TLS reestablishment. Point taken, issue created so we can crisp up the language https://github.com/csosto-pk/tls-suppress-intermediates/issues/11
- adding ICAs in the trust bundle is kind of done already in some cases like when revocation info is not checked and static CRLs, CRLite etc are pre-downloaded out of band. That is not much different than the ICA acquisition mechanism. Point taken. I would argue that trusting that an ICA’s key has not been revoked is not the same as adding it to the trust bundle. But that is probably semantics, your point makes sense. It would be interesting to understand how many ICAs exist in trust bundles already, just out of curiosity.
- A failure due to incorrect ICA list is a big failure mode to not be underestimated. Point taken.
- If we can assume an OOB mechanism to load the ICAs then we can simplify things. Practically we can assume there is no failure. Agreed, but I am not sure that we should not include any non-normative language for the inadvertent corner case though. There should be a fallback, one that we are assuming will never happen, but an implementer should account for it.
- Connection re-establishment affects the security and privacy assumptions and should be captured. I am not sure the concern is worse than the regular fingerprinting text already in the draft, but point taken. We can improve the text and I created an issue for it. https://github.com/csosto-pk/tls-suppress-intermediates/issues/12

I would be interested to track how that ICA list has been changing over time. Let’s see if we can get data on that for FFs preload list, Filippo’s or others.

About SCTs and OCSP,  CRLite is a good option OOB too. About SCT, it is a hard problem. We should not forget the other usecases including the EAP-TLS John Mattson had brought up before and other usecases where SCTs are not used and will still be dealing with the issue. But for the Web if there was a way to avoid or do SCTs differently it would alleviate these heavy handshakes. Open to ideas like Bas’ STHs, but I consider these high hanging fruit as Bas also pointed out. 😉

Good discussion, thx.

From: Ryan Sleevi <[email-masked]>
Sent: Wednesday, February 16, 2022 10:36 PM
To: Kampanakis, Panos <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Bytheway, Cameron <[email-masked]>; [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Wed, Feb 16, 2022 at 2:41 PM Kampanakis, Panos <[email-masked]<mailto:[email-masked]>> wrote:
Some responses below (sorry long email):

No worries, I think this invites some long responses, in part, because it's complex.

I don't think I communicated this well then. Although this is trying to do something simple (in as much as treating the TLS and PKI layers distinct), I think it's missing that it's shifting a significant portion of that problem to PKI layer (re: synchronizing those ICAs), and also introducing complexity to the TLS layer (re: fallbacks and retries). If the problem statement is primarily oriented around PQ, then perhaps it's better to explore a solution that tries to keep both layers simple.

Basically, it needs to be a little crisper what the client capabilities are. Presently, it handwaves them as out-of-scope, but as a consequence, makes it difficult to justify the assumptions/complexity that they hide. Does the client have durable storage (e.g. does the IoT device need rewritable media and not just ROM)? Does the client have a reliable (within TBD3) out-of-band update mechanism for metadata such as intermediates? Is the TLS implementation expected to be able to re-establish a connection (which many TLS APIs are not themselves responsible for, or at least, abstract that away)? These all affect the shape of the present design, but also any simplifications.

But although the directory option is the most straightforward option, there is a dynamic cache building element too. I have experimented with this a bit; someone may not even need a full ICA list. It could build its cache dynamically as it starts connecting to peers.

As you captured later, this is (effectively) reintroducing TLS fallback. We worked very hard to try to minimize that, and while there are retries (ala HRR), they're integrated into the connection state machine. Needing to re-establish a new connection, sans flag, is a very big failure mode here, and one that definitely influences the shape of API design.

Equally, this introduces some of the privacy risks that the EDNOTE was trying to dodge. It seems like the choice to reintroduce "connection re-establishment" logic would have bearing on the security and privacy assumptions here, and is worth making sure it's captured.

Alternatively, if we take out this on-demand discovery piece, then we're effectively saying "Clients need a reliable update channel for this to work". Which may be a reasonable thing, but equally, it opens up the realm for simplifications, as discussed above and below here.

Right, the criticism in the past is that it's not "I somehow know", but rather, "I think I know my peer's CAs", with some probability of being wrong. The what to do when things are wrong is important, and realizing that different peers may be more or less wrong (e.g. depending on update cadences) has a significant impact on deployability.

So, two responses.

- In your responses to Ilari, and your original message, there seems to be some assumption that Mozilla policy is representative and reflective of what's possible here (c.f. disclosures). As much as I love and have actively contributed to that policy, I'm also uncomfortable with using it as a stand-in for the Web PKI or generalizations. That said, because you were willing to lean on it regarding constrained intermediates, then it should be clear that the "vet and trust more CAs" has already been a part of the policy for some time. Every intermediate is subjected to the same policies, the purpose of disclosure of said intermediates was intentionally to support that vetting first and foremost, and any new intermediates are equally subjected to that vetting. So if your response was meant to capture "This is difficult", then it's overlooking "This is already being done/required".

- This model is, explicitly, proposing to "do PKI differently", but perhaps in ways that are subtle. This introduces, albeit intentionally does not specify, the problem of determining what exactly those intermediates are, and in a way (within the TBD3 timeframe) of synchronizing those widely to clients. Equally, it's being proposed precisely because "For PQ, we need to do PKI differently". So it doesn't seem an unreasonable step here.

As I said, I don't disagree with the goals, but I think one of the concerns is that this tries a patch solution, but does so in ways that introduces problematic dependencies/assumptions, and my previous reply was trying to tease those out a little so that they're explicit as to what was considered and/or rejected.

For example, the concern of "trust many more CAs that don't have their key offline like roots do" misses that in the absence of a functioning revocation system, we already trust those intermediates just as much as we trust those roots, and with the same risks. This is why browsers, at least, have developed systems of "revocation suppression" - by having the client already know about revocation of intermediates apriori (CRLSets, Valid, OneCRL/CRLLite, etc). In order for intermediate suppression to be functionally viable, you need that out-of-band delivery mechanism (and yes, I'm counting build-as-you-go as OOB). So the distinction here of online/offline is, in a model that assumes a reliable mechanism to discover intermediates, one without a difference.

Unless we're willing to take those very large handshakes to also have stapled OCSP responses, then whether it's through CRL fetching-and-batching (which is, in many ways, an OOB delivery mechanism) or some vendor-supplied mechanism like browsers', we're still saying "Clients need some reliable way to fetch an external resource to update". And, if we're willing to say that, then we introduce the opportunity for a lot of simplification here.

I'm not sure I would agree that a 3-8 MB handshake to preserve the status quo is exactly low hanging fruit. This is where looking to see what can be done to remove the necessity of those SCTs and OCSPs, rather than trying to patch them into a PQ world. The viability of CT itself becomes more suspect in a world of ginormous signatures, if only because monitors/auditors lose the ability to effectively monitor, even if we had perfectly-efficient in-band TLS delivery such as via caching/elision.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 19 Feb 2022 13:14:39 +0200

On Sat, Feb 19, 2022 at 03:59:23AM +0000, Kampanakis, Panos wrote:

> - If we can assume an OOB mechanism to load the ICAs then we can
> simplify things. Practically we can assume there is no failure.
> Agreed, but I am not sure that we should not include any
> non-normative language for the inadvertent corner case though.
> There should be a fallback, one that we are assuming will never
> happen, but an implementer should account for it.

It seems to me that the dominant failure modes are:

- Using old ICA list that is missing some newly minted ICA.
- Using custom TA that is missing ICA data.

> - Connection re-establishment affects the security and privacy
> assumptions and should be captured. I am not sure the concern is
> worse than the regular fingerprinting text already in the draft,
> but point taken. We can improve the text and I created an issue
> for it. https://github.com/csosto-pk/tls-suppress-intermediates/issues/12

Regarding security and privacy, the most severe impact of any attack
I can come up with is determining if some arbitrary ICA is on the
ICA list or not (for passive attacks, that is restricted to the issuing
ICA used by the server). Practical impact of attacker being able to do
that depends on how many endpoints share that same ICA list.

Rough outline of the attack (active variant): Fabricate a certificate
purporting to be from some ICA, send it to client and observe if the
client retries (ICA not on the list) or just fails (ICA is on the list).

> I would be interested to track how that ICA list has been changing
> over time. Let’s see if we can get data on that for FFs preload
> list, Filippo’s or others.

I only have some isolated random datapoints on number of disclosed
WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that
time, that number has grown from 1669 to 1820.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 19 Feb 2022 16:28:52 -0500

On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara <[email-masked]>
wrote:

> > for it.
> https://github.com/csosto-pk/tls-suppress-intermediates/issues/12
>

I'm hopeful that some may be interested to perform a more thorough
analysis. We saw enough complexity with respect to previous TLS versions
and the fallback logic being possible to induce downgrade attacks that I
think we should be very wary about introducing a class of anticipated
handshake failures that require connection re-establishment, especially
across independent TLS sessions. I realize that sounds a little like FUD,
but rather: every time we've tried to do this, it's blown up spectacularly,
so we need to make sure we're not setting up another bomb.

I also think the active attack analysis is a bit lacking, especially since
the attacker has the ability to mint arbitrary ICAs on demand, without
running afoul of any existing client policies. For example, for the Web
PKI, by virtue of nameConstraints without pathLen in the basicConstraints,
the site can mint arbitrary ICAs and arbitrary EE certificates. Combined
with the discovery mechanism discussed, this is effectively the same as
other forms of stateful tracking (ala HSTS tracking), and thus likely to be
subjected to the same mitigations that would largely render the benefits
here ineffective, at best.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 25 Feb 2022 18:17:08 +0200

> so we need to make sure we're not setting up another bomb.

I have hard time seeing how one could construct downgrade attack out of
this, as it just requests extra data from server on fallback. For most
other retry stuff, downgrade attack risk is obvious as less secure modes
are introduced / more secure modes are removed.
 
> here ineffective, at best.

Having pathLen >= 1 would do as well, right?

And such ICAs can already be abused for tracking if the browser does
transvalidity. Suppress ICAs flag would make it worse, by allowing other
sites to read such tracking supercookies.

Defense is not doing transvalidity nor cached AIA chasing (since those
caches represent state that could be attacked). This closes the attack
for both with and without suppress ICAs.

Another defense to make reading ICA list harder would be to always
trigger fallback if certificate validation fails and ICAs were
suppressed.

Neither defense would render suppress ICAs ineffective, since in vast
majority of cases one can use quasi-static ICA list to buld verifiable
certificate chain and then use that with no fallback.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 25 Feb 2022 14:36:46 -0500

> are introduced / more secure modes are removed.

I think I’m raising a question about whether or not implementations will
actually do this, and arguably, to explicitly specify this if this is the
expectation. In theory, yes, if the only thing changing in a fallback is an
optional flag, it “shouldn’t” have concerns. In practice, however, these
sorts of fallbacks (e.g. various server bug workarounds) introduce
compositions that cause new and unexpected interactions. This is why the
ecosystem has tried very hard to avoid fallbacks (c.f. TLS 1.3) and
ensuring that both parties are able to commit to the negotiation. We saw
this with the renegotiation issues getting confused state from the initial
handshake.

Sure, “without pathLen constraints”

> sites to read such tracking supercookies.

Transvalidity was never something widely supported outside of a specific
product/library (Mozilla NSS). But yes, this is the point: this feature
gives a much stronger signal.

> for both with and without suppress ICAs.

I fail to see how it closes it without suppress ICAs, particularly because
the current draft very explicitly suggests caching as a possibility.  And
yes, implementations that wish to mitigate cross-context tracking are
working to isolate those caches, and this was my point: doesn’t this
isolation defeat the benefits of the caching / the likelihood of
intermediate omission succeeding, and functionally mean that there needs to
be a reliable, semi-real-time distribution mechanism for intermediates to
achieve the benefits?

I’m trying to look at this from a systems perspective, and tease out
explicitly: what is this solution assuming exists in order to achieve the
desired effect, and with those assumptions, are there
simpler/less-risky/alternative technical solutions? Not to bikeshed, but
because the design assumptions here are unstated and have practical and
meaningful ecosystem effect, and so we at least owe that much.

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Sat, 26 Feb 2022 04:17:30 +0000

> I only have some isolated random datapoints on number of disclosed WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that time, that number has grown from 1669 to 1820.

Thx Ilari. Understood. 

We are looking into how we could quantify how the complete ICA list changes over time in order to evaluate TBD3. Probably it would be in the days to weeks timeline than years, but that remains to be seen. Of course that would not cover usecases other than WebPKI, but probably that is the more dynamic one. 

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Ilari Liusvaara
Sent: Saturday, February 19, 2022 6:15 AM
To: [email-masked]
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Sat, Feb 19, 2022 at 03:59:23AM +0000, Kampanakis, Panos wrote:

> Agreed, but I am not sure that we should not include any non-normative 
> language for the inadvertent corner case though.

> assumptions and should be captured. I am not sure the concern is worse 
> than the regular fingerprinting text already in the draft, but point 
> taken. We can improve the text and I created an issue for it. 

Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list.

Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list).

> over time. Let’s see if we can get data on that for FFs preload list, 
> Filippo’s or others.

I only have some isolated random datapoints on number of disclosed WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that time, that number has grown from 1669 to 1820.

-Ilari