There has been a lot of discussion over the past few days, both in
person and on the mailing list. I want to share some thoughts on those
discussions before the meeting tomorrow.
My impression is that there is little consensus on which problems we
want to solve as a WG. Resolving this is critical for making progress.
It is almost impossible to have sensible conversations about new drafts
without agreeing on and understanding the problems we want to solve.
The vast majority of folks I've spoken with have said they're interested
in solving the challenges around deploying fully PQ TLS, but don't feel
that we are currently close to a shared understanding of those
challenges or the tradeoffs around the drafts on the table today.
A smaller number of folks are interested in tackling other problems
around root store management. I fear this aspect of the problem space is
even less clearly understood and I heard very little agreement on what
the key challenges are or how they might be addressed.
I hope tomorrow we can focus our discussion on figuring out as a WG the
problem(s) that we want to tackle and where we differ in our
understanding of those problems. I am sure that 20 minutes will not be
enough time to resolve these complex issues, but I hope we can find a
way to continue the conversation constructively.
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:
- What are the problems that we solving?
- Who are we solving these problems for? Browsers or everyone?
- Are we proposing a hard requirement on this negotiation mechanism for
anyone wanting to do fully PQ TLS?
- Can the proposed mechanism be enabled by default in TLS Libraries
without requiring application changes?
- 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)?
- What is the long-term vision for TLS and the WebPKI? Are we moving
forward together or fragmenting?
- How do the proposed mechanisms affect TLS Client Hello fingerprinting
or other tracking vectors?
- How would the proposed system work in practice? What happens when
actors follow their own interests rather than the requirements of RFCs?
- 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).
- 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?
- 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?
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.
Finally, in any proposal which alters the power dynamics of a system,
there will be difficult questions of a political nature, especially when
the system in question is depended upon by billions of people.
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.
Best,
Dennis
[1] https://en.wikipedia.org/wiki/User-Agent_header#User_agent_spoofing
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
