IETF Logo Mail Archive

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

Filippo Valsorda <filippo@ml.filippo.io> Thu, 19 June 2025 03:31 UTC

Return-Path: <filippo@ml.filippo.io>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2657636C2C1B for <tls@mail2.ietf.org>; Wed, 18 Jun 2025 20:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=filippo.io header.b="t4I0aR+X"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Mn04cf8s"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaRiR8mZI1k8 for <tls@mail2.ietf.org>; Wed, 18 Jun 2025 20:31:47 -0700 (PDT)
Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C3E8B36C2C12 for <tls@ietf.org>; Wed, 18 Jun 2025 20:31:47 -0700 (PDT)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id B3797138047B; Wed, 18 Jun 2025 23:31:47 -0400 (EDT)
Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-11.internal (MEProxy); Wed, 18 Jun 2025 23:31:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1750303907; x=1750390307; bh=qLrnc8kndD R8gHzH0QbX4/jWL+YT/2NE894hzqzkmU4=; b=t4I0aR+XxxXvhlJOUU8WJ22Ovt vhp2H6Vd4jSs0WmDDCLlP0LrkYmVCgHyRFh2jHxJXtez5n15MEGCqWTj2bYIvXXu LFxwlb/lYTrXTVbydgPidjQTiLcA/mRsO264DFP1aLhWMKc5XlQx3zk0K1JXjlUm xRGRts6aR/VoBvGuEjVgXB9l6nBPCGJsogcHUM+75I3YlPs7aDjunk2tWShZCapX vxpvAfVBUHYeZcarMfizaVizFlxB/V549f3x3DeMwvedtAbI+xpJszDKionis7NC SsUEu0yGqf7yf+VOLyKfp9UEuI/TJsKQku+15szPxwHVspL8iC67pZtq3tTg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1750303907; x=1750390307; bh=qLrnc8kndDR8gHzH0QbX4/jWL+YT/2NE894 hzqzkmU4=; b=Mn04cf8sr/Vd7H/Z/1bZNzZrv4KEcEMvAU60xNsdE785+uNvs9b z6EK43Lsar1FRu9536oC+mYqX5rrU4mCHFkMKt1AACSdzE2s9WcmUccaPFeATDbY 8DUddai2hD0wolITLeE8/VSJdunDJHnncpr3ykIz5cMPES2g3tz+rThJcE66yPsE RhUY5ckd0FWWsFZm89C0jg077lZP3hF5FSKQ8QBBNBOzJIgSTgPbDV3TSyoJxKW6 ZsUiszNs2LCYHMJbVqgvvUc0y1O85ipuiFayY42ETaJ+5CVO7gBCtGMFm5OQGBKJ um9OM7eErIabbi/keBdACypS/HvHjNfHNFQ==
X-ME-Sender: <xms:o4RTaDYMwbQS3U4IWtciXG9UniMERt0KYcQxN9DGxF9ZC7DMj2320g> <xme:o4RTaCbT6MRY_hxtbIWSNi83PVTQBwSdE5VvlVfE8VP1egAVvhwSfU_YK-_teViiP LsboKyx8GMtrQZXJg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdeggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerredttden ucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhilhhiphhpohesmh hlrdhfihhlihhpphhordhioheqnecuggftrfgrthhtvghrnhepieegueejvefgffekhedu leevleegieevveduvddvjeejudfhtdeuieduteeguddunecuffhomhgrihhnpehrfhgtqd gvughithhorhdrohhrghdpgihmphhprdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepfhhilhhiphhpohesmhhlrdhfihhlihhpphhord hiohdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohep uggrvhhiuggsvghnsegthhhrohhmihhumhdrohhrghdprhgtphhtthhopegurhgrfhhtqd hfrhgrnhhkqdhmthhlshdqvhhirgdqshgvrhhvvghrrghuthhhqdgvgihtvghnshhiohhn sehfrhgrnhhkrdhfhihipdhrtghpthhtohepthhlshesihgvthhfrdhorhhg
X-ME-Proxy: <xmx:o4RTaF9jPpdsdWKF1JpVJQCjK0AjdV5L895UhJmJvJdyoMKFXszDLQ> <xmx:o4RTaJoVT7VVAkpbBkS3UI6vgG5F2kPQNzvQgZY7ezQ81_t5WT6rGA> <xmx:o4RTaOpSUPKD9Pbmxy3R6UedTQORER274KU2Oy0hPgkPVky6hMCSbA> <xmx:o4RTaPQlUDMgAigDhNNYrzML52_B3Fax6adzI-kSFRRlXpumZCd3Ew> <xmx:o4RTaKdTRd7x0nNXQw2HLT3scd7Wwfvah3T80dBLQ-qVWT2tmSRCqAgR>
Feedback-ID: i2e91459c:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id E2915700062; Wed, 18 Jun 2025 23:31:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T853231f333e0b773
Date: Thu, 19 Jun 2025 05:31:24 +0200
From: Filippo Valsorda <filippo@ml.filippo.io>
To: Klaus Frank <draft-frank-mtls-via-serverauth-extension@frank.fyi>, David Benjamin <davidben@chromium.org>
Message-Id: <51df6085-8c3b-4652-b8d8-5d78120c37ce@app.fastmail.com>
In-Reply-To: <19a905e5-5a07-4369-83e4-be082f59c9f7@frank.fyi>
References: <45jp5tle7ixk7xhc57j5extnhg772nhhguqp4arvuppjuotkdo@jq5vd74bdpbg> <CAF8qwaAj8rYkRWatDuxmBQ+TQu7Yw1GPNm-Jf+W1CT0j18nwBg@mail.gmail.com> <e556eac0-adc1-4130-acc2-4c4cd2a00d86@frank.fyi> <0be5270b-e5f9-48e3-90ef-1ee38ee913e5@app.fastmail.com> <19a905e5-5a07-4369-83e4-be082f59c9f7@frank.fyi>
Content-Type: multipart/alternative; boundary="50b2a1272ccc42fcb84cf4256112bb09"
Message-ID-Hash: IISHI5YWJ4G4VM36B6BH3TXXIJAFRMKY
X-Message-ID-Hash: IISHI5YWJ4G4VM36B6BH3TXXIJAFRMKY
X-MailFrom: filippo@ml.filippo.io
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066
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/YmNoso7dHLv4FylhhsIYrGCAbQI>
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>

2025-06-19 01:41 GMT+02:00 Klaus Frank <draft-frank-mtls-via-serverauth-extension@frank.fyi>:
> On 2025-06-19 00:57:35, Filippo Valsorda wrote:
> > Getting roots to ship with operating systems is certainly a hard multi-year project, but why does ejabberd or an MTA need to use the OS root store?
> >
> > If the XMPP and/or SMTP ecosystems feel the need for a PKI which behaves differently from the WebPKI, can't they ship the roots of such a PKI with their code?
> >
> > Boulder is open source and ACME is an extensible protocol, so the barrier to standing up a PKI has never been lower.
> >
> Simply but cause ejabberd isn't the only XMPP software in existance, 
> same for an MTA (however the issue there is mostly caused by microsoft 
> demanding such a certificate to accept mails within a hybrid deployment, 
> as someone from Microsoft was so kind to jump in I think we can leave 
> that part to them to answer)
> 
> mutual SMTP between the MX servers is basically considered to have 
> failed. Exactly for what the Chrome Policy wants everyone to do. Because 
> it lacked a common trust store for the PKI certificates. RFC7672 even 
> talks about this in problem and come to the conclusion that reliance on 
> a common trust store is impractical. Others went the route of re-using 
> the OS root store, which basically reuses the web browsers Web-PKI for 
> the most part, but in hind sight probably should have followed the same 
> approach as RFC7672.
> See section 3.1.3 https://www.rfc-editor.org/rfc/rfc7672#section-3.1.3 
> and section 10 https://www.rfc-editor.org/rfc/rfc7672#section-10 already 
> explain a lot about why it isn't as easy as "standing up a PKI".

I'm sorry, I am losing track. Sounds like mutual TLS in SMTP was already not a thing *before* the policy change, except for one vendor, then? That would leave only XMPP as affected, correct? How many XMPP server implementations are there? I see eight on this page <https://xmpp.org/software/?platform=all-platforms>.

I think something that would help the conversation move forward would be getting details of affected software and protocols *as they are actually deployed*, and then of the alternatives they have, so the group can assess whether this or another is the most appropriate solution.

> The central idea behind my draft is basically that it is more feasible 
> to add allowing serverAuth certificates to be used by systems expecting 
> server-to-server connections even on the TLS-Client side before the 
> deadline hits, where as re-architecting all current usages to use DANE 
> and have every operator arround the world populate their DANE records 
> within DNS is not (esp because still not all TLDs have DNSSEC support, 
> and even for some that do have it (like e.g. ".de" or ".eu") domain 
> registrars like e.g. namecheap don't offer it citing that the TLD 
> supossidly wouldn't support it).
> 
> 
>

v2.32.0 | Report a Bug | By Email | System Status