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