[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
Richard Barnes <rlb@ipv.sx> Mon, 16 September 2024 14:32 UTC
Return-Path: <rlb@ipv.sx>
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 25E66C14F6F3 for <tls@ietfa.amsl.com>; Mon, 16 Sep 2024 07:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20230601.gappssmtp.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 TK453B4AGjTt for <tls@ietfa.amsl.com>; Mon, 16 Sep 2024 07:32:50 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 352D0C14F61B for <tls@ietf.org>; Mon, 16 Sep 2024 07:32:49 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id e9e14a558f8ab-3a09af86744so5779735ab.1 for <tls@ietf.org>; Mon, 16 Sep 2024 07:32:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1726497169; x=1727101969; 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=ePEzsaz3we4EV5DlFRRXTOMuwhtoulvmLKJ9I8lnczI=; b=JbvChBM0fl3s7iHhXmruTRo7SKGorCw6ue+nyll5UTsIwTygo9Gj8iaHl8u/lSCYjK DafvOvyXZ8rUsQXq/3hNKVLSFq0qax9OZB/jmv2Q6Z0n9gY7KCA57hYml28PwQFq+n/D lkYcFVlzYc0mIkZIw2AEKrRGRBK9oGFtM2lAP8KLeT6x4YwgLslR8j21WsllF2IqRHpl mNKyeK08H5c+Hhy00Y3zyATw8xrO6boy9KFQocN6eYkvGRavKJZ5TBiFUj6kWP4XOfAQ 6jlDXdYigwUr+Pa+MOAL4uxUxkY8aXfTbsDxyT59LVzh6cqCAl5J64nUffjpGHQ7/7DZ XY4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726497169; x=1727101969; 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=ePEzsaz3we4EV5DlFRRXTOMuwhtoulvmLKJ9I8lnczI=; b=Ms0cLTaKZEPvVhuXWFRuIYlhGIseoM9x/unDiWIoxGWLRpqYtlAP/tGoL5J/tAAJWp 2vSzw5ixTR3rasKiJP1G1TwsYeNintlit+sD/am4om3yYVJ+gD57c6t8pyJ7H4C5uGdX QpY0U08Jb4y/QFQD4BOQTwOO+SYLXib30WwHPbaMFyf5XfAlebbkMi9m2p9Uq9/PKv7F xSi5RrcPZ3ZFZb0G3a8uEzgOQh3QTKY++VaKTZnvvjsYsHkh8Y/gs+nxq4pMXx9XwT6C 9xOBDC+YaaY8iM+AjyXlVmfHjPzgc3j9lLxtWlDmdOOPUR9y/UOKOq9Qx5tmm2fwNBZT V5JQ==
X-Forwarded-Encrypted: i=1; AJvYcCXNNqnyvAaLuZC+RYFOOgj64Jc3PQEJeTR6CMC3ZpDXSohdZCCF+v/FasFmoPVH9//uNXQ=@ietf.org
X-Gm-Message-State: AOJu0YyemD7AtazFjT5EUrWMUD0PRbdpSGLxuJ3G3dzW2XYDC6GiQ9ts gCf1NkhIicfPgiZXz+z4zSCDd2kurs5SiFAzwkqHlElvA58mfCQGqTzv+h2DoP7/8qhG20ZgYId s0TyzY6YafoggFPjfcUtJriTUS7P+fV7YPMcGpRL/tIlQa8WWZIQ=
X-Google-Smtp-Source: AGHT+IHuVwx4mPZto/6+gAFn9t74xOoz33KDUGkLGPNQ8i/733fzdpLXNa8T2DCgcbcttj6ANv1vlhTr9mE2WzXbo2w=
X-Received: by 2002:a05:6e02:198d:b0:3a0:933d:d306 with SMTP id e9e14a558f8ab-3a0933dd371mr60037865ab.9.1726497168938; Mon, 16 Sep 2024 07:32:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAHaGKyeSBGD4AAbnddiWtG7kEvh3Y6mbTyAgw485UfJZhFKXkw@mail.gmail.com> <7CF1C293-C236-4D41-B054-EB0E8B127BEA@sn3rd.com> <CAL02cgS_9ZPKuL_Dm19Guf67u8sDm-AK=cy+WeLVT_juVHQrUQ@mail.gmail.com> <ZuHVU_4qG2jhNJIB@chardros.imrryr.org> <DS7PR21MB3716F7B300177A76AF917A9D8C9B2@DS7PR21MB3716.namprd21.prod.outlook.com> <ME0P300MB07131C6E3D10A9E7188A7CE8EE9B2@ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM> <CAHaGKydXtgVdKBEd0A5J+tti_kUA2dhNr7CZ5vGZi42jrft29g@mail.gmail.com>
In-Reply-To: <CAHaGKydXtgVdKBEd0A5J+tti_kUA2dhNr7CZ5vGZi42jrft29g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 16 Sep 2024 10:32:37 -0400
Message-ID: <CAL02cgQb91Nd61MnNW+C8g4gDa=z4PWcT+qQN=46h8UqK1V5wg@mail.gmail.com>
To: Mark Robinson <mark@markrobinson.io>
Content-Type: multipart/alternative; boundary="00000000000075f7a706223d72de"
Message-ID-Hash: DUZTOJQIEPQCXFHJW4663B3SV5HBCW2V
X-Message-ID-Hash: DUZTOJQIEPQCXFHJW4663B3SV5HBCW2V
X-MailFrom: rlb@ipv.sx
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: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
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/tZvFHVLgHNhokpVVc1njgUcSksw>
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>
Thanks for the additional details, Mark. So it sounds like these organizations are not only requiring that the remote party's certificate be issued by a public CA, but that it be a specific certificate. Couple of observations here: 1. This is clearly not business for the TLS WG. This WG doesn't do anything with how certificate trust is provisioned. UTA might be right, or just run through the DISPATCH process. 2. This seems like a terrible design. * It's basically HTTP certificate pinning [RFC7469], which is being aggressively deprecated by browsers for exactly the downtime reasons you mention. * The public CA isn't adding any value here, and as you note, they add to the downtime risk * Trying to automate this is pointless, because you'll just end up back at the same problem of establishing trust with the other side. If you had an automated "here's my new cert" protocol, well, how do you verify that the thing sending you the new cert is authorized to? In light of (2), I would be disinclined for the IETF to do any work on this particular flavor of the mTLS problem. On Fri, Sep 13, 2024 at 11:08 PM Mark Robinson <mark@markrobinson.io> wrote: > I want to thank everyone for your feedback. It's been super helpful. > > I think I should elaborate on what the problem is and how it can be fixed. > > I've worked with a lot of companies who want to use mTLS (as bas as the > name is) to increase security but don't know how to do it in a way that > won't reduce reliability. For example, many companies require a certificate > signed by a public CA and then *emailed* to them. They have the annual cert > expiry of a regular cert combined with a manual (and hackable process) that > basically guarantees downtime when someone goes on vacation. > > What I'd like to cover: > - How two orgs (that aren't CAs) can exchange keys > - How to rotate keys > - What parameters keys should be set, and how keys should be validated > - When and how keys should be updated > - All of this without manual steps or #$%#$%ing email. > > Setting up cross-validation of TLS should be a single line change for high > performing organizations and should never, ever, ever involve email certs > between customer service reps. > > Mark > > On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann <pgut001@cs.auckland.ac.nz> > wrote: > >> Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org> writes: >> >> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes >> >confusion where customers ask whether "mTLS" is a different protocol or a >> >specific TLS implementation? However, it can be argued that this >> unfortunate >> >term has already taken root. >> >> +1, Richard pretty much said everything I have concerns about but saved >> me a >> lot of typing. mTLS *is* TLS, there's no need to give it a special name >> for >> marketing(?) purposes. >> >> Having said that, I'd have no problems with a "TLS Profile for xxx", >> which is >> what it really seems to be. >> >> (And I'll add an obligatory comment that what (m)TLS does isn't mutual >> authentication, it's unidirectional authentication in both directions, but >> that boat has long since sailed. If you wanted to have actual mTLS it'd >> have >> to use PSK). >> >> Peter. >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-leave@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org >
- [TLS] Is there any interest in an RFC on how to d… Mark Robinson
- [TLS] Re: Is there any interest in an RFC on how … Salz, Rich
- [TLS] Re: Is there any interest in an RFC on how … John Mattsson
- [TLS] Re: Is there any interest in an RFC on how … Olle E. Johansson
- [TLS] Re: Is there any interest in an RFC on how … Iyer, Sudha E
- [TLS] Re: Is there any interest in an RFC on how … Sean Turner
- [TLS] Re: Is there any interest in an RFC on how … Richard Barnes
- [TLS] Re: Is there any interest in an RFC on how … Joseph Salowey
- [TLS] Re: Is there any interest in an RFC on how … Viktor Dukhovni
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Andrei Popov
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Peter Gutmann
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Mark Robinson
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Viktor Dukhovni
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Richard Barnes
- [TLS] Re: [EXTERNAL] Re: Is there any interest in… Mike Shaver