On 24/07/2024 12:59, Tim Hollebeek wrote:
I think this is a good summary. I want to support this sort of effort, in part
because it's very similar to some other ideas my boss and I were pushing about
five years ago. Something similar to this would solve, but also cause, lots of
problems. It's not clear whether the net result is better or worse.
But I find it difficult or impossible to evaluate for exactly the reasons
Dennis mentions: there's no context explaining how it will be used, or any
discussion of the impact on the many other things that would need to change for
this draft to be useful.
We need to have open and honest discussions about how roots and root management
will work going forward, if we want things to work differently in the future.
-Tim
Thanks Tim and Ilari!
In the meeting on Wednesday, there was only a few minutes for discussion
at the end of the session.
However, the chairs did propose a vote on 'If we were to adopt T.E. or
T.A.I, which draft would you prefer?' (to be clear, there was no way for
participants to indicate 'adopt neither draft'). That vote showed a
strong preference for the new Trust Anchor Indicators draft over the
older Trust Expressions draft which really helps narrow the discussion
going forwards.
Watson proposed an interim which was supported by 10+ people in the
meeting [1] and I think is a clear signal that folks feel further
discussion is necessary. If the chairs can facilitate either an interim
or a dedicated session for this topic at the next IETF meeting, I would
be very happy to give a presentation to explain the concerns about both
the risks and the practicality of the proposal. I hope the authors would
also be willing present their answers to some of the questions below,
including their vision for delivering (fully) Post-Quantum TLS and their
proposal's role inwithin that.
I look forward to reading the author's updated draft when they've had a
chance to integrate the feedback from this meeting and will be happy to
adjust my own comments once the new draft is ready.
In the meantime, I think the mailing lists (and my keyboard) could
certainly use the rest.
Safe Travels, Dennis
[1]
https://drive.google.com/file/d/1lgGb3htLz0cO__tnEJPk_ga5X64RsMB6/view?usp=sharing
Original:
https://zulip.ietf.org/#narrow/stream/140-tls/topic/ietf-120/near/128259
-----Original Message-----
From: Dennis Jackson<[email protected]>
Sent: Tuesday, July 23, 2024 9:51 PM
To: TLS List<[email protected]>
Subject: [TLS]Discussions on Trust Anchor Negotiation at IETF 120
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 [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
TLS mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
