[TLS] Re: Adoption Call for Trust Anchor IDs
David Benjamin <davidben@chromium.org> Wed, 15 January 2025 16:15 UTC
Return-Path: <davidben@google.com>
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 ED690C1DA1F8 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 08:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.393
X-Spam-Level:
X-Spam-Status: No, score=-9.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 ZTp1ZaPY_Cov for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 08:15:46 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3471DC1DA1D3 for <tls@ietf.org>; Wed, 15 Jan 2025 08:15:46 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-aaee0b309adso1124816366b.3 for <tls@ietf.org>; Wed, 15 Jan 2025 08:15:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1736957745; x=1737562545; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gu4R94iADDWbvM3gi+CumKlMoT5iCFy573P3sQ/Ge6w=; b=K6tUgkjHukYvx2jW0szcQ+BSTKjdk0bSp0hMooveyjHckb3Jl+4Va/NaYm/PTGNbnq wJyz8ow4RI/Ib1lxCT/5VBZP7IDBwtdO1Otl/MkcM9BFZasCIIVR1jfWTP0QnGLDoIG0 fDmLqE9Yi+i5HUPiHmf8iuRJbtXdtiIGwxN20=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736957745; x=1737562545; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gu4R94iADDWbvM3gi+CumKlMoT5iCFy573P3sQ/Ge6w=; b=sMhlF8ltZcbzwGfba0im8hHof4shp0/jFS8yeoD718bmfQDwkNUMPVeT8YuJz9cLfC mueRk6T2oAAJbID+PcaKgJEthjC/Eq4QRO4lu5oARFmmcy9p17wSYf1VK5ifecFUZrSx ws3CM7TG4xsu5RcW3I1+Yem+WP4NccAoA8PEWnnfVIalF3u9u9mJo3ypSC8P98MPix4y PGz5RsIXiebEafIvBdgyf0L6dydZ4d5czO5hMlCIHZwkcvd7YZf/jOu7swIGm8hhFvNA jW31+7NqYPirmuyFZSn41EaWHAJZW5KpV2FFWkjyXiSlVG29voMr5wKykc1/mmd/Y3Ox 3vsg==
X-Gm-Message-State: AOJu0YwfvP74c8DDWcsx0W4AeAicY0sSbMOi/4lNLZDu2XdW97mMLLhi ETOwU0zK229WEWbNkgPPQAiAEGSIWKMXCusrSdp+VSMDrE6bWrF1Fs/98TTAtp+q3rgMJFc/dU9 f0RhSRG0qJGnNAtMSZC2qI0xbMzKK4Yr9C73fM2RiSYPAeitm
X-Gm-Gg: ASbGncsj88sZrhVNjFooOkNEM09V5nJ4wdg/ZJzNFgBgkdHzBiaBLTR1Jj8iqpptYG+ F8zQVhBP8CtCHc56mX3OELKJ6LaZfJLPLe6aZ
X-Google-Smtp-Source: AGHT+IGJ4tZZexfSbPsT648nUqvimF/lgClviVpIwlifr0i49NxZfetA9QVRV6airDJp/2jww+3gilEpfz2tF/BNYKw=
X-Received: by 2002:a17:907:981:b0:aae:df74:acd1 with SMTP id a640c23a62f3a-ab2ab67059dmr3158434066b.11.1736957744435; Wed, 15 Jan 2025 08:15:44 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDHaHXAcpXjtzoA7U-T7B0LoqxSxXsbp7-Rq+gF3shj7Q@mail.gmail.com>
In-Reply-To: <CAOgPGoDHaHXAcpXjtzoA7U-T7B0LoqxSxXsbp7-Rq+gF3shj7Q@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 15 Jan 2025 11:15:26 -0500
X-Gm-Features: AbW1kvZlxfFZboDzvF0Yyjyui3zK1ldgA53T2i59_WKhN694o4886KbO06WhmJw
Message-ID: <CAF8qwaDsgqwmH34DJgfv4Xnfy5YcDZK1S5Q5YttfoTQtrGEYgg@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="0000000000005963a2062bc0fd56"
Message-ID-Hash: TFAQZZ4EUFQ6R3J77SKRLEYYIS2PJTID
X-Message-ID-Hash: TFAQZZ4EUFQ6R3J77SKRLEYYIS2PJTID
X-MailFrom: davidben@google.com
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
CC: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Adoption Call for Trust Anchor IDs
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/FdnOlCR1k9GIEiVvTKAuF4_aIKA>
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>
Unsurprisingly, I support adoption. To recap from the interim where we took on this problem, server operators need to be compatible with all their supported clients, while clients need to curate accepted certificates to maintain user security. This client function is security-critical: accepting a wrong name/key binding enables that key to intercept TLS. Clients cannot just check a name/key binding from first principles, so they delegate to PKIs: elaborate systems of trusted keys, trusted operators, expiration, revocation, delegation, etc. These systems are inherently dynamic. To trust a CA is to predict its future behavior, which is inherently subjective. Sometimes those CAs are found untrustworthy, and clients must act to preserve user security. Beyond that, as the working group often discusses, different clients have different needs. Not everything looks like a browser. Those different needs influence how the client interacts with a PKI. This naturally leads to diversity, across different clients and different versions of the same client. From the interim, supporting this, with today's PKIs and today's tools (including cross-signs), is not easy for server operators. The result is a conflict between security-critical PKI maintenance, and keeping a service available to users. Both goals then suffer, thus the motivation to solve this problem. Trust Anchor IDs applies TLS's standard, well-understood approach to these problems: parameter negotiation. It is a retool of certificate_authorities, a similar, longstanding mechanism dating back to SSL 3.0. It is widely deployed in client certificates PKIs, but is not ideal for existing, larger PKIs. Trust Anchor IDs tries to meet those existing PKIs where they are, and TLS's usual style of solution. At the same time, it is not specific to one PKI. Not everything is a browser. I think this is a good starting point for the working group. My coauthors and I are eager to start working on it with you all. As with other drafts, we very much expect that this too will change after adoption, perhaps significantly. (E.g. discussion over how to approach tradeoffs between DNS vs. unhinted ClientHellos.) This is a large solution space, and navigating it in a working group document lets us do so reflecting the group's consensus. As for the draft arguing not to solve this, gosh, coming up on ten years of contributing to this community, I don't think I've ever been quoted so much! Unfortunately, it largely misrepresents both what's in our draft and the motivations discussed at the interim. I'd rather not follow this pattern of quoting and trying to dispute each sentence at length. Speaking for myself, I am exhausted by the tenor of discussion that produces, and am eager to move on to a more productive stage of this process. I think more effective would be that we discuss any specific topics on the list that folks may be interested in. Thanks all! David On Wed, Jan 15, 2025 at 11:00 AM Joseph Salowey <joe@salowey.net> wrote: > At the trust tussle Interim in October we had consensus that the working > group was interested in working on the following problem: > > “Avoid client trust conflicts by enabling servers to reliably and > efficiently support clients with diverse trust anchor lists, particularly > in larger PKIs where the existing certificate_authorities extension is not > viable” > > After IETF 121, we asked for submissions for possible working group > adoption as a starting point for this work. We received two submissions: > > [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03 > <https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/> > > [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 > <https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/> > > [1] defines a new protocol mechanism, while [2] provides an explanation of > why the mechanism in [1] may not be needed and may be problematic. Since > the second draft does not define a protocol mechanism we are not > considering it for adoption, but we request that working group members > review both documents and use [2] as input into determining whether we > should adopt [1] as a working group item. Adoption as a working group item > means the working group has change control over and can modify it as > necessary; an adopted document is only a starting point. Please respond to > this thread if you think the document should be adopted as a working group > item. If you think the document is not appropriate for adoption please > indicate why. This adoption call will close on February 7, 2025. Also > please remember to maintain professional behavior and keep the discussion > focused on technical issues. > > > Thanks, > > > Sean, Deirdre and Joe > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org >
- [TLS] Adoption Call for Trust Anchor IDs Joseph Salowey
- [TLS] Re: Adoption Call for Trust Anchor IDs David Benjamin
- [TLS] Re: Adoption Call for Trust Anchor IDs Bob Beck
- [TLS] Re: Adoption Call for Trust Anchor IDs Andrew Chen
- [TLS] Re: Adoption Call for Trust Anchor IDs Ryan Hurst
- [TLS] Re: Adoption Call for Trust Anchor IDs Brendan McMillion
- [TLS] Re: Adoption Call for Trust Anchor IDs Robert Relyea
- [TLS] Re: Adoption Call for Trust Anchor IDs Loganaden Velvindron
- [TLS] Re: Adoption Call for Trust Anchor IDs Martin Thomson
- [TLS] Re: Adoption Call for Trust Anchor IDs David Adrian
- [TLS] Re: Adoption Call for Trust Anchor IDs Watson Ladd
- [TLS] Re: Adoption Call for Trust Anchor IDs Mike Shaver
- [TLS] Re: Adoption Call for Trust Anchor IDs Stephen Farrell
- [TLS] Re: Adoption Call for Trust Anchor IDs Thom Wiggers
- [TLS] Re: Adoption Call for Trust Anchor IDs Bas Westerbaan
- [TLS] Re: Adoption Call for Trust Anchor IDs Clint Wilson
- [TLS] Re: Adoption Call for Trust Anchor IDs Kyle Nekritz
- [TLS] Re: Adoption Call for Trust Anchor IDs Christopher Patton
- [TLS] Re: Adoption Call for Trust Anchor IDs Kathleen Moriarty
- [TLS] Re: Adoption Call for Trust Anchor IDs Dennis Jackson
- [TLS] Re: Adoption Call for Trust Anchor IDs Kampanakis, Panos
- [TLS] Re: Adoption Call for Trust Anchor IDs Nick Harper
- [TLS] Re: Adoption Call for Trust Anchor IDs Salz, Rich
- [TLS] Re: Adoption Call for Trust Anchor IDs David Schinazi
- [TLS] Re: Adoption Call for Trust Anchor IDs Christopher Wood