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

[Ryan Sleevi <[e-mail]>]

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

>