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