On Wed, Feb 16, 2022 at 2:41 PM Kampanakis, Panos <kpa...@amazon.com> 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. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
