[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