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

Mark Robinson <mark@markrobinson.io> Sat, 14 September 2024 03:08 UTC

Return-Path: <mark@mrobinson.ca>
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 69C34C14F6F3 for <tls@ietfa.amsl.com>; Fri, 13 Sep 2024 20:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level:
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=markrobinson.io
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 2Zjm-P-YZUaB for <tls@ietfa.amsl.com>; Fri, 13 Sep 2024 20:08:25 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 6FDB3C180B40 for <tls@ietf.org>; Fri, 13 Sep 2024 20:08:24 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5c42c3aac99so124999a12.1 for <tls@ietf.org>; Fri, 13 Sep 2024 20:08:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=markrobinson.io; s=google; t=1726283303; x=1726888103; 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=vE+ZPXTXgm7utfTJZHZ6IZrtjmiIINPNL1qXxEiU1Ho=; b=gL8igk7DEH8GtY0SxuqQ/vlgIl0HQbjsh3Q30sdX/+lMs8UzL75PfRBm+FZmZJT9Jl OeBlzd5mi2Gufb+4FPnv4oGTkxqFwDlfusmBPrtHqiEguODCMVXrVE11PwH+m0ACyfhE RFvtZqYOVvDORunwcRpUnmJfKw8PEgqpz9p3alc7EAr+nxa48XppipIxtM5uaN473eUJ Pjb7NZc6d9J3b67V5PDsEUjeR8Z0WmepVtoCBa3S9HQKf+mcPBqCS8wJRle6Bj5LylJ8 YdT9tiK7Cw8Tg/0dFVwEC8hUIC8yRPokD6zeOAuRYrrbtGNxwroj86YQHchvOmaPudKW K3Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726283303; x=1726888103; 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=vE+ZPXTXgm7utfTJZHZ6IZrtjmiIINPNL1qXxEiU1Ho=; b=euK4KjZWPcKCv3ZgBrjkMX7B1eWm96aqojtMMdHED9jIPPOvOydOq8LjnZYEa+WG8P Nd9hPPiKry5HWBl0JcEQzlamla3eAA2lJNPwOWsSTwNDuhRU28cHRoRrq3qBIp09ziiX xHT7TJLVw0Z5KvW7+3OpjW4rU3ZxmFSu2GcDVtKZ2cctk4MpGhXX1j5lfrPBu6ICZKUk i5QYVb38TlOOtAuxKto6+L3Ih/qpMF1yb3CBRo6h0kClRuFRsp43SS8ECYNvk/AId2VO YcID/Vnw+WDjDIx+SQHNpsBBuJc1LRwmz5edPCbg98QTYbnGImee7hsPMJcu8r5j32QT 9SPA==
X-Forwarded-Encrypted: i=1; AJvYcCWEMEIFkAzkoGDF9EyIswVR2Je1Ligwv/07sPT0JhiDDMPxItmN8cxoMGQKRqoeVS97hgc=@ietf.org
X-Gm-Message-State: AOJu0YzmiC1l6Y0Z0dM9Z/6Jui/89c8vEOOMNs8L1TBS9hBu01LVgnpn dU5yYNm/x9Fgj0/gGbMyrHeNTZAhm+7IKPRxNRm3PB8Z84bpWyxvcph1/V2fvMqDAUFT5zybQrq 6JxahrNOzGZo2XUmTWcMe9l+tDidfnu9li6uivm2rTI0rtmPn
X-Google-Smtp-Source: AGHT+IFblhemuXTH1sBPoQBRdbDZCQPUQ6M6PNITHep9vpBiq9WoIZYx7OlntxCP10l7BGLTExZP27e1EDpKoAu4fCI=
X-Received: by 2002:a05:6402:278e:b0:5c3:d0f5:86f3 with SMTP id 4fb4d7f45d1cf-5c41dea6befmr5195449a12.3.1726283303109; Fri, 13 Sep 2024 20:08:23 -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>
In-Reply-To: <ME0P300MB07131C6E3D10A9E7188A7CE8EE9B2@ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM>
From: Mark Robinson <mark@markrobinson.io>
Date: Fri, 13 Sep 2024 20:08:12 -0700
Message-ID: <CAHaGKydXtgVdKBEd0A5J+tti_kUA2dhNr7CZ5vGZi42jrft29g@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="0000000000001064af06220ba752"
Message-ID-Hash: 737MMPML3BZYTJRUH5LMA5UCUYQQAJQV
X-Message-ID-Hash: 737MMPML3BZYTJRUH5LMA5UCUYQQAJQV
X-MailFrom: mark@mrobinson.ca
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/JsPdQgEziJLS1WHO2CPID6P8UNI>
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 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
>