Re: [TLS] Adoption call for TLS Flag - Request mTLS

Eric Rescorla <ekr@rtfm.com> Fri, 05 April 2024 03:07 UTC

Return-Path: <ekr@rtfm.com>
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 07F24C151084 for <tls@ietfa.amsl.com>; Thu, 4 Apr 2024 20:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 QOA6CfrmOigG for <tls@ietfa.amsl.com>; Thu, 4 Apr 2024 20:07:27 -0700 (PDT)
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03022C151069 for <tls@ietf.org>; Thu, 4 Apr 2024 20:07:27 -0700 (PDT)
Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-61461580403so18825797b3.2 for <tls@ietf.org>; Thu, 04 Apr 2024 20:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1712286445; x=1712891245; 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=JUR4uh+OrrE1ymI8KxXgztrqc590Or/1xCVeens1KpQ=; b=xDUa7WWHe96GjKrtt+U+72rmBnpEMsO/iN+VII85rrIC1VLubdGziTST9UX7tSjfjA MdrC/ikR/ocwYETzYG1hB1nZahg9FzlGyIrZVKl4e2/hbjGPGvhsMNuRuRhFI+1lbVnc ZzqQKaRvB73SBQM6b7POqzzqEGOj8h6LY5C2FAbtLQyrGhwaKoOVqTPbql9Q0SEU2NYv AgegNk+y4XNOHXR5aFEzpcK6d4tD+0EKmSSMDF75Cu2DcxE/t0NumQaYCpZOUsEXUZRX 9LvCw8tSMGn61aekuZudKR+UraSJ/rPTxbe7dZ6dpzYf0+JaVja+VxgfeM3xxOSQUt6h O5iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712286445; x=1712891245; 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=JUR4uh+OrrE1ymI8KxXgztrqc590Or/1xCVeens1KpQ=; b=KnexHTqg2nDm7jFokNGk2yKrfStmSVypEs3mfibWcg23k0wPDTGginbXPsjGYbsWrC Lfg1bXFfS0bYBLdM1sFQBovbDKRHcXekUdmEnEh49F4woLeiB7qtxf4RVklap0F3yG30 3Ok8nxshSGvKfgyHhic+v/yaMwdIlY7lxDMQnIbfyGazjahYBgzEKyZqgH2aMayh84xo oFx4HRQuZ78fB2nGD/BVbeGvV4lvkIGUR/nY3Skk5/gJh7iStTtRWsD+1eOChwNbMDi1 falTI1ON1GuwQMe95h6eiiPjbxZ6lBI7qj/kcirhtzRVOMlxgm5cEBCGgbuMsz7XTyWK WbyA==
X-Forwarded-Encrypted: i=1; AJvYcCXDdthVgOvbO+pn0ao3ixIcxK7iUITvKqLdCGzr+PYaPm4P4NssScsXbgAHdflrGXE5V4oe7dKVZNoHORk=
X-Gm-Message-State: AOJu0YwFzrttDbE2d2nnUIkRhea5OwdyzdvAUtk3Ri89Mlvx5cHZR0Rw W+3bbHorYOlggMNORCEqX51C8U5rHPlFLO7vy/zzQZlmk5vaBjK78arQq2g2ljX68N6mJHW2zY9 qlfuFdPmC1aR1LgCDuYopXm086X7APrmJCFLt3Q==
X-Google-Smtp-Source: AGHT+IGaPibfi0+5MOZFFakmjYQtRmwIKgL91JnX225XWQI565ogR6vtzCB+AyHhyxpbKC3eBRQd3VSxVv6MOl2vRpE=
X-Received: by 2002:a0d:d415:0:b0:615:1e67:be88 with SMTP id w21-20020a0dd415000000b006151e67be88mr131074ywd.21.1712286445570; Thu, 04 Apr 2024 20:07:25 -0700 (PDT)
MIME-Version: 1.0
References: <8957179A-14D2-4947-B196-B68988B0E3CA@sn3rd.com> <CAG2Zi20wUSFMFUiySQMoM08hpvLY3eLe_F8sWDG+F7T7=E0SOw@mail.gmail.com> <CABcZeBPgmrDo37sRpRos6pFkeoG6QjMGeLhYkpXCHsEw7GCtYQ@mail.gmail.com> <CACsn0cmP9_2zufm0dmgkQJkpwn=b7Y2cZ13N_zDfhggLYunMRQ@mail.gmail.com> <CABcZeBOJzEWtES9FYp2gvQriK_gsWWE8qrv9xKQZE0aGH+stEg@mail.gmail.com> <SJ0PR22MB3096BA38B9318777E11D19B3DA032@SJ0PR22MB3096.namprd22.prod.outlook.com>
In-Reply-To: <SJ0PR22MB3096BA38B9318777E11D19B3DA032@SJ0PR22MB3096.namprd22.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 04 Apr 2024 20:06:49 -0700
Message-ID: <CABcZeBP4BkxX8hgOhQ_f9WhRbxOjJ5=4FMHJPDhnQLeDVMo6xg@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Watson Ladd <watsonbladd@gmail.com>, Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000057aeb7061550c119"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TeEEL2PHOhi85Hx_-WKIOby8wMk>
Subject: Re: [TLS] Adoption call for TLS Flag - Request mTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2024 03:07:28 -0000

On Thu, Apr 4, 2024 at 7:38 PM Mike Bishop <mbishop@evequefou.be> wrote:

> Ekr, can I ask you to clarify this a little? I fully agree that extensions
> to TLS which support a particular application-layer protocol should be done
> in that protocol’s working group unless and until it’s demonstrated that
> many unrelated applications will need something similar. (At which point,
> it probably makes sense to build the general thing, either in TLS or a new
> WG.) But this isn’t that.
>
>
>
> For something that concerns the TLS exchange itself, the TLS WG does still
> seem like the natural home to me. Where are you suggesting the standards
> work happens instead? Are you suggesting that this should be registered to
> the I-D, or go to a new/different working group? The former path seems like
> it won’t get the review it needs, and I’m not sure any other WGs are
> appropriately chartered for the latter.
>

I'm suggesting it be registered based on the ID.

When you say "get the review it needs", I think that's at the heart of the
question. My position is that the TLS WG (and the IETF generally) should
spend its limited resources on things which are important and likely to
receive wide deployment. Other code points can just be registered and
marked "recommended=N". Of course, they won't get review, but nothing stops
people from registering all kinds of bad ideas without review; that's why
the registries were open.

Here's what would make me interested in seeing the TLS WG spend time on
this: a critical mass of both servers and clients of the type contemplated
here (e.g., search engines or crawlers) who say they would actually use it.

-Ekr


>
>
> Personally, I support adoption for the use case. It sounds like there’s an
> alternative design that might need to be hammered out, but since it appears
> a document may be needed for either path, let’s adopt and argue about that
> later.
>
>
>
> *From:* TLS <tls-bounces@ietf.org> *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, April 3, 2024 10:28 AM
> *To:* Watson Ladd <watsonbladd@gmail.com>
> *Cc:* Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>; TLS
> List <tls@ietf.org>
> *Subject:* Re: [TLS] Adoption call for TLS Flag - Request mTLS
>
>
>
>
>
>
>
> On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>
>
>
> On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
>
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code point assignment?
>
>
>
> Well, don't we want to say how this is supposed to work somewhere?
>
>
>
> Why? The attitude I am trying to get away from is that the TLS WG has to
>
> be involved in every extension to TLS. Rather, we should decide what things
>
> are important and spend time on them and then let others extend TLS
> independently
>
> in areas we don't think are important.
>
>
>
> -Ekr
>
>
>
> I doubt this will take much time.
>
>
>
> -Ekr
>
>
>
> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
> should clearly have
>
> a policy which matches 8447 S 7, which is to say that an I-D is sufficient.
>
>
>
>
>
> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton <cpatton=
> 40cloudflare.com@dmarc.ietf.org> wrote:
>
> I'd like to see this problem solved. There was some discussion about
> whether an I-D is needed or all we needed was to register a code point
> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
> happy to review.
>
>
>
> Chris P.
>
>
>
> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner <sean@sn3rd.com> wrote:
>
> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>