[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Dennis Jackson <[e-mail]>]

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<ietf=[e-mail]>
>> Sent: Tuesday, July 23, 2024 9:51 PM
>> To: TLS List<[e-mail]>
>> 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 [e-mail]
>> To unsubscribe send an email [e-mail]
>>
>> _______________________________________________
>> TLS mailing list [e-mail]
>> To unsubscribe send an email [e-mail]