[TLS] Re: Adoption Call for Trust Anchor IDs
Watson Ladd <watsonbladd@gmail.com> Wed, 15 January 2025 19:12 UTC
Return-Path: <watsonbladd@gmail.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 AB017C151096 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 11:12:03 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xo33Ipk1GA9e for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 11:12:03 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 0054AC14F693 for <tls@ietf.org>; Wed, 15 Jan 2025 11:11:57 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-38632b8ae71so129762f8f.0 for <tls@ietf.org>; Wed, 15 Jan 2025 11:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736968316; x=1737573116; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=B6BqGoIl7kjgD+HJztPUNyE4ioWqJmXssIL5ZjGBd8A=; b=ZeNBu2lh3sg6CgeEPRPQ+/U4t7i5xAwbEdZYFS6zERtHA/DREGkGi4twniBf9W3UAf 3rseYKpP5nPxCSkmsud36x1+GuLMHIKKxvts24V99WiF//0GzdZ137hrIh1D8rSpW11a KDn7xxZr+s10efhFLQwJNQ/uFy9Lovx3UNXpe4yT4AR7tcYDYEeZ1/iUBg3msfvgjnTo vQT0pw9qF/RNVVbgU3Lyvv57gJZtqXmLP8xb1hCTySo31x6qkgKcLxEH1AuZvp2XGjRY ub0aJAsSJwngPWcjm//7kD7+hd/bE3baxoxr9+xPzTbb7rocCgGjohOODx7hGqZaIMn9 7KAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736968316; x=1737573116; h=content-transfer-encoding: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=B6BqGoIl7kjgD+HJztPUNyE4ioWqJmXssIL5ZjGBd8A=; b=LunHYeMFd5xXp25gUeDVSyjKPhaGt115vxbtf9P9Fg9JB+1KlLAmos2hRwzna79jRL HUnKEw98UUzFBwwpph1YUBWV8WuULSIDCNq7VwhEbpntP/6melX91BFCwMCmpLyJu8o8 4muUiPbRhv6IuzokBCWOV3aKAgczDwQ1GPP/TiV93UvvJO03cQGax0H6sWL8KxbMot7d 02bjQAqNt9n6davDoODthpH5GKzO/qM0wtOyyP4mpyuFiJkLZ3XL4irJwqJm9kQmPS12 MiKfFD5m/5gOWXosKEOn15bZ3cqsg/J2eKFciCVDDQj4SR9fDZi7+XCNKdUfiMWgT29p C6Uw==
X-Gm-Message-State: AOJu0YyESPn5N5pkrmmrR63IG62ODJkwMo9jRl1ro1SL/4H/fgxmnvv7 /9iKAsC+a+pCgCHxow36K7eM8lC5BoXY9N8TIHNmL4Vku+xBCeN2kfpkZqUfEkIRv+ewHwTTfhU 9YiXNk1kZkTxsnE9lQaNJkmfd6SgmPw==
X-Gm-Gg: ASbGncuVoUMlJJ5U4G5bi0cXLRbGNwdhFJgpe/nb4u6cuScNu0B3IRixp4hT0OdWqR5 d+68txMhbv8bSF5LpFb3vK9gboSVAkRtzxOwSYtaNd5cmzIG1vUOR5c8HoUqWyjtzHHUn4VY=
X-Google-Smtp-Source: AGHT+IHZv/7tMqoP450LPC1sJX6dc49uf5WyMgI8r6TrPd5u09y1ncBHIU48Gs2D5BBAuImUNh6KRqO3ACS7hDu6HYM=
X-Received: by 2002:a05:6000:2a3:b0:386:32ca:aa12 with SMTP id ffacd0b85a97d-38a8733b9dbmr26095080f8f.49.1736968315480; Wed, 15 Jan 2025 11:11:55 -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: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 15 Jan 2025 11:11:43 -0800
X-Gm-Features: AbW1kvZ1EbWrxIEAmWAK5pLxGFg7G_x9VdYVLKJRgwJeRIVQzGdNw_lmOjVTDxs
Message-ID: <CACsn0ck42z=J=AQ4P=UGuUajwLT3DMBD6==8vGtwydZyX3poMg@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: RYGUZKLLM4JU3FYEC4I3ZE2MXI4HNMKY
X-Message-ID-Hash: RYGUZKLLM4JU3FYEC4I3ZE2MXI4HNMKY
X-MailFrom: watsonbladd@gmail.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/_4m4gNMOBfWI89zK9HO5_s_DQM8>
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>
I'm not sure what I think about adoption, but maybe it rounds to yes. At the interim I think I said (although I can't remember if I said or typed it snarkily in a backchannel) that just because problems are worth solving doesn't mean we can solve them. I'm afraid this is one of them. For the specific case of devices with long lifetimes and short updates, sending the CA in the already existing channel ought to work. The problem with trust anchors is it requires some far reaching changes impacting all server software, TLS implementations, client software, server operations, ACME clients, and maybe DNS as well. That ain't happening to a first approximation. Perversely, the implementors best suited to do this are the ones that we need to adopt this the least. At the same time I think that we have a very real "just works in Chrome" problem that negotiation would enable. We've already seen CAs pay more attention to Google and Apple than Mozilla in dealing with incidents. Older proposals where it would have just been an anchor the server needs to know how to deal with would have had all the fun of User Agent capability negotiation. I'm glad to see this proposal at least on a first glance avoids much of that. I do think there are some changes that can fix some of the ubiquity issues, in approximate reverse order of my confidence in them: - Use a hash of the root certificate as an identifier. Do something really clever/stupid depending on perspective to shrink it. This way servers have a fighting chance of figuring out what it is without additional configuration. - Use DNS as an initial hint, not a mandatory field (maybe in draft-beck, not sure) - HRR for when client hello's don't have a right one, so servers can fix busted DNS. - wildcard by client, for cases where DNS doesn't have any info to learn the server config - Some guidance on how to cache this. I do think I need to think more, and I'm definitely not sure we'll eventually solve this, although I'm optimistic enough we can start here. However, if the benefit requires near universal adoption with some really far reaching systemic impacts, I don't think publication would be warranted. Sincerely, Watson On Wed, Jan 15, 2025 at 8: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 > > [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 > > > [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 -- Astra mortemque praestare gradatim
- [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