On Tue, Jul 23, 2024 at 09:51:04PM -0700, Dennis Jackson wrote: > > Ahead of the meeting tomorrow, I want to highlight some of the questions > which I think we need to find and agree on answers for:
The following are my own opinions. > - What are the problems that we solving? * Allowing server to have multiple certificates for handling spatial (different trust stores) and temporal (different versions of the same trust store) fragmentation of trust stores. * Intermediate supression. > - Who are we solving these problems for? Browsers or everyone? Everyone. > - Are we proposing a hard requirement on this negotiation mechanism for > anyone wanting to do fully PQ TLS? No. However, there may be transition period with really bad spatial fragmentation making this mechanism de facto mandatory (which could then be followed by temporal fragmentation). However, because TLS does have proper algorithm agility, there is little benefit in using fully PQ TLS until CRQC appears. To handle any retroactive attacks, only kex has to be post-quantum, and post-quantum kex can be used (and is used in the wild) with classical certificates. > - Can the proposed mechanism be enabled by default in TLS Libraries without > requiring application changes? Only if using some sort of system certificate validation. Otherwise mostly minor changes are required. Some models turn out to require major server-side application changes (e.g., anything that can dynamically vary number of end-entity certs), and those are to be avoided. > - Can the proposed mechanism support use in a private PKI? How about in a > private PKI that runs over the public Internet (in the now-classic > zero-trust networking model)? Trust Expressions looks like it would work with private PKI. Things are much more muddy with Trust Anchor Identifiers. It does seem to support private PKI, but is that actually usable? > - What is the long-term vision for TLS and the WebPKI? Are we moving forward > together or fragmenting? I would see the fragmentation on WebPKI remaining as it is today, but total fragmentation increasing as some of the stuff now on WebPKI is pulled out to private PKIs. > - How do the proposed mechanisms affect TLS Client Hello fingerprinting or > other tracking vectors? The information transmitted given everything else is very small, as this stuff can be mostly inferred from other things (not reliably enough for servers, but reliably enough for tracking!). > - How would the proposed system work in practice? What happens when actors > follow their own interests rather than the requirements of RFCs? The failure modes seem to confined to: - Tracking vectors. - "I'm vulnerable" signals. However, any extensions, including non-standard ones can have the same failure modes. > - Are less popular clients incentivized to lie in their Trust Expressions > about which root stores they have? The history of browser HTTP User Agent > spoofing [1] highlights how minority clients are forced to spoof the signals > of other browsers to maximize site compatibility (even though it violates > protocol requirements). Here it is likely that problems are due to inaction rather than deliberate steps. And various WebPKI trust stores have high overlap, so lying is very likely to work. Site that wants to deliberately exclude some browser could perform things like TLS fingerprinting or deeper probing of JS APIs. These are much harder to get around than simple user agent checks. > - How would versioning root programs work in practice when security > requirements change? If the same root CAs are in version N and version N+1 > of a root store and version N+1 adopts a stricter security policy - can > these root CAs still issue certificates for version N? Only adding constraints would trigger version change. And clients stuck at version N do not know about the additional constraints, so apply the old more lax rules. > - What are the consequences of making it easier to establish new root > programs? For governments that have previously tried to build domestic root > programs, would solve some of the problems they faced and encourage them to > try again? More private PKIs. And it would not solve the problems with domestic root programs. There might not be any way to add a new root program, requiring any parallel root program to be handled as special case in the code. > Ultimately, these are two complex drafts which propose substantial changes > to TLS and the WebPKI. Besides evaluating the technical details in the draft > themselves, we also have to tackle the nitty gritty operational questions > about how a new system would work in practice—in particular, considering the > incentives of the stakeholders to adopt the system and or to deliberately > deviate from the intended protocol for self-benefit. Only TAI does changes to TLS that could be considered substantial. Neither proposes any substantial change to WebPKI. The main incentive is improved compatibility with various clients. This frequently would need multiple certificates. Even with just one certificate, intermediate suppression would improve performance. > Naturally, good people will often disagree on the nuances of these complex > topics. However, we owe it to each other to communicate constructively, > arrive at a shared understanding and find a path forwards that as much of > the community as possible can support. And especially disagree on severity of various issues. E.g., how bad is it to retry? How bad are issues with ECH compatibility? -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
