[TLS]Discussions on Trust Anchor Negotiation at IETF 120

Dennis Jackson <ietf@dennis-jackson.uk> Wed, 24 July 2024 04:51 UTC

Return-Path: <ietf@dennis-jackson.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EB3C1D5C58 for <tls@ietfa.amsl.com>; Tue, 23 Jul 2024 21:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra7_m07AKOUA for <tls@ietfa.amsl.com>; Tue, 23 Jul 2024 21:51:13 -0700 (PDT)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050:0:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B36C1D4A8E for <tls@ietf.org>; Tue, 23 Jul 2024 21:51:12 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4WTM6M0Rtrz9slP for <tls@ietf.org>; Wed, 24 Jul 2024 06:51:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1721796667; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=qDdJzYZ9ClyWTy2LcOgFbPLeX0ZCb8OPd4eeocTe14U=; b=tuz5801QRqpgvXhbAhK/RIM5zRhg8p0ZABrPSe7lAmmSCk7EDW6DfDVq/V9FPASuHfxEha GFeUsP1esuBc1WuwYCLH/NCfO6qYwd5UGFVa5PklSSp+RUb9muSy/t0wpAAo6Ac7Ycx5iZ exiwYBzsKSSAPklESmzMC3e2hcD2/hPva+WixiCRL+yZsXznAj5DrNCTYbnHxAIkIUAPwJ Ox1Tk6kCrT6oXikprq9130CUY1CDjmzFxPNUBQZwIisyxV2bFpBl5IFypXMNjtWiltoWb+ ct1qjHlRLzcgpZRFgO4H55qAwWZUH38MQXXaiihvC0JH7POatJunsRRNfpLmRQ==
Message-ID: <d1589f89-35cb-489f-b195-30feb3e7e40f@dennis-jackson.uk>
Date: Tue, 23 Jul 2024 21:51:04 -0700
MIME-Version: 1.0
From: Dennis Jackson <ietf@dennis-jackson.uk>
To: TLS List <tls@ietf.org>
Content-Language: en-US
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4WTM6M0Rtrz9slP
Message-ID-Hash: WPRNFA4P3COHQUEXWOY7HG5PITJISCWE
X-Message-ID-Hash: WPRNFA4P3COHQUEXWOY7HG5PITJISCWE
X-MailFrom: ietf@dennis-jackson.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Discussions on Trust Anchor Negotiation at IETF 120
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/c2S4BskNxYChjg0ZV_vWTHmjZiY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

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