[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
>