IETF Logo Mail Archive

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

"Olle E. Johansson" <oej@edvina.net> Tue, 10 September 2024 07:31 UTC

Return-Path: <oej@edvina.net>
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 D37A2C1519B4; Tue, 10 Sep 2024 00:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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=unavailable autolearn_force=no
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 V9ddZAiUgxvq; Tue, 10 Sep 2024 00:31:56 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E212C1519AB; Tue, 10 Sep 2024 00:31:51 -0700 (PDT)
Received: from smtpclient.apple (h-176-10-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 93BDE2185; Tue, 10 Sep 2024 09:31:45 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <30EEB40B-6151-4577-A55D-ABBD3FCA4736@edvina.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7492B057-1858-4B3A-8DE9-623FDDCDCC98"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Date: Tue, 10 Sep 2024 09:31:39 +0200
In-Reply-To: <GVXPR07MB9678C0193D148ABBEA7FAD4B899A2@GVXPR07MB9678.eurprd07.prod.outlook.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
References: <CAHaGKyeSBGD4AAbnddiWtG7kEvh3Y6mbTyAgw485UfJZhFKXkw@mail.gmail.com> <02100E15-44A3-41FF-B81C-B81FCC94AAE7@akamai.com> <GVXPR07MB9678C0193D148ABBEA7FAD4B899A2@GVXPR07MB9678.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3776.700.51)
Message-ID-Hash: 47EZ2ONY6MWZOART2VGW7PIHIIV3ISDX
X-Message-ID-Hash: 47EZ2ONY6MWZOART2VGW7PIHIIV3ISDX
X-MailFrom: oej@edvina.net
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: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Mark Robinson <mark@markrobinson.io>, "tls@ietf.org" <tls@ietf.org>, "uta@ietf.org" <uta@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS] 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/_jhxGKtnOHCAxk5wPXHip-k7J9c>
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 agree here. The term “mTLS” is used more and more and there’s no specification. If we could document a few profiles for it, like internal use in a system, cross-organisation etc that would
be beneficial.

/O

> On 10 Sep 2024, at 09:16, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> I would be very supportive of such approach. I think the scope should cover mTLS in general, not just cross-organization. The term mTLS is not even defined in IETF, in fact the TLS WG has previously used mTLS for at two other things. It would be good to a document to refer to for implementation requirements. A lot of tls implementations are not at all suitable for mTLS. I have seen a lot of cases where people assume that any product supporting TLS will be suitable for mTLS. But often they are very limited and don’t support client certs, don’t support revocation, don’t support extracting certificates from the handshake, etc….
> 
> I think it would also be very good to have a mTLS RFC when TLS 1.4 is done sometime in the future. TLS 1.3 removed a lot of functionality that was important to a lot of mTLS deployements like a forth handshake message, ephemeral ECDHE during a connection, reauthentication, and moved external psk identifiers to a message where there is no identity protection. It is not the TLS WGs fault if nobody was there to argue for the need of these things, but it would be good with a document documenting these things in the future. Note that mTLS deployments are very different and might require different things.
> 
> Cheers,
> John
> 
> From: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org <mailto:rsalz=40akamai.com@dmarc.ietf.org>>
> Date: Monday, 9 September 2024 at 22:30
> To: Mark Robinson <mark@markrobinson.io <mailto:mark@markrobinson.io>>, tls@ietf.org <mailto:tls@ietf.org><tls@ietf.org <mailto:tls@ietf.org>>
> Subject: [TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
> 
> Would it be appropriate to write an RFC on how to make cross-organization mTLS work reliably and at scale? Would this group/mailing list be the right people to work with to make that happen?
>  
> You should also ask the UTA working group if they are interested.
> _______________________________________________
> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
> To unsubscribe send an email to tls-leave@ietf.org <mailto:tls-leave@ietf.org>

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