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

["Kampanakis, Panos" <[e-mail]>]

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


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.




On Wed, Feb 16, 2022 at 2:41 PM Kampanakis, Panos <[e-mail]<mailto:[e-mail]>> wrote:
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.