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

[Ryan Hurst <[e-mail]>]

For what it is worth, agree with Sophie, trust anchor negation is needed
regardless of PQC, and tying the two topics together artificially would not
make either problem domain easier to solve.

Ryan

On Fri, Jul 26, 2024 at 3:28 PM Sophie Schmieg <sschmieg=
[e-mail]> wrote:

> I don't think trust anchor negotiation needs a lot more discussion, over
> what has happened already. All in all, I think it's a good mechanism that
> is fairly well defined and it's not clear to me how it would benefit from
> an interim.
> PQ TLS on the other hand has a lot of open questions about things like
> different variants of Merkle Tree Certificates that I would love to flesh
> out further. If we want an interim, we should focus on that question, and
> leave trust anchors out of the discussion, in my opinion, moving them
> towards adoption instead of drawing out the process even longer.
>
> On Fri, Jul 26, 2024 at 11:38 AM Dennis Jackson <ietf=
> [e-mail]> wrote:
>
>> 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 in within 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]> <ietf=[e-mail]>
>> Sent: Tuesday, July 23, 2024 9:51 PM
>> To: TLS List <[e-mail]> <[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 to [e-mail]
>>
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>