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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Thu, 04 April 2024 10:17 UTC

Return-Path: <jonathan.hoyland@gmail.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 ED173C14F70F for <tls@ietfa.amsl.com>; Thu, 4 Apr 2024 03:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lyvDIQnb4BFO for <tls@ietfa.amsl.com>; Thu, 4 Apr 2024 03:17:49 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 52DDEC14F701 for <tls@ietf.org>; Thu, 4 Apr 2024 03:17:49 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6ecf541e19aso106183b3a.1 for <tls@ietf.org>; Thu, 04 Apr 2024 03:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712225869; x=1712830669; 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=udPddRAxH7+3WxqF2P0hEzdCLpFu4DcVMU+GIevV7yo=; b=DPnnGmJsYz/1LOrbM8wPt17IKcYr6c8B3c06ZCRxft47a5cTneksqRd1z5j49/PRkp Q2iMQCcMKfWEMIz+ntYgGttlpp8g9VWy7uztQEqCLTXLlDoIhAAjOKUJWrp3G6zeh+U6 pTVpUDaNZCGvjZ9bkyYhQHPHSOqzuEvG36FEvNx1T/NbZy/28YDjmLJZ+c7WSFCGJb/l bnH2HrFWz/xElBSiGFWsU7tRjjq7LVMQ8uNxYsinaWZT0j7vtCxcsaGuRMRX+IdR8OLc XxJ2tJ+Uyu/Kzs1UWumeKzG0poanFl6Chw7Hmr5+j5QTVR+ScK/DftI/Om2cMXznlU0N lung==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712225869; x=1712830669; 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=udPddRAxH7+3WxqF2P0hEzdCLpFu4DcVMU+GIevV7yo=; b=f8hgaOtAlmzhIBV36MdVYpfequuOkZD4BrPJAVtVkZQKwCtI2U3+1YUqcMCPYh19yL WK30b6JzSndSljUogChcozC9C3LeJuLobOY4DaqGcc3nbkp5karQkCxfc2Z7atUOfFF2 Eyy7mq2k/AuZ5dT7YeSTbBqxoVTFkLm6m8tqjYpoGhkn+tLnCGLH7yIidIby9InHqNON qHfGVXFUnOGFl+kLBpCMg4kcuLk/EtCzAu+twNLYFyR1kAXMiNJEudQUZWedIuWBxHau DkI63CHXD+ndR6ew3lKAzlIFJA/U6EH8UKALrtfk8oUnqrEveIIXk5Bov0oaHXifmONI DsaA==
X-Forwarded-Encrypted: i=1; AJvYcCUdMFWpUD18T2PtGRL7AmqZkX5ydzYFen58Qxct1JpJQlKNhlAy0D+/r3jIzSSjZUfbYX/Tkb5BtlSPrjg=
X-Gm-Message-State: AOJu0Yy//UP2eZ93hyYjhlFM10Ax/REzT1Ye865m5ojsZs51Ar6A9hXd 5sARqJGUxLKErjpuMbthkiRyBaP+ZuJPIwDwO2jHF8bv84LNhZ6t0W1uHMU9qRclh/l3L4tHCpg lCAJuEsRmaKPcpjw+pI2jdBgtBUs=
X-Google-Smtp-Source: AGHT+IEN1eSaE3F1q7L7/w32UQo+QLc/2kueYtQQo/8AjwS9/4w8SJDfz4lKIE8CnDw+8pxrJ5A1G84RW9C54nD6JQQ=
X-Received: by 2002:a05:6a20:94ca:b0:1a7:34c5:f8d with SMTP id ht10-20020a056a2094ca00b001a734c50f8dmr1820164pzb.38.1712225868626; Thu, 04 Apr 2024 03:17:48 -0700 (PDT)
MIME-Version: 1.0
References: <8957179A-14D2-4947-B196-B68988B0E3CA@sn3rd.com> <1c42a223-8abc-472a-bb8d-a7827f5b0f06@iki.fi> <CAG2Zi20=Azki7Qp2rgi+ixdCojTr8kbrP6wBiYX2J7Xy94b4Jg@mail.gmail.com>
In-Reply-To: <CAG2Zi20=Azki7Qp2rgi+ixdCojTr8kbrP6wBiYX2J7Xy94b4Jg@mail.gmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Thu, 04 Apr 2024 11:17:36 +0100
Message-ID: <CACykbs3V7huBGqUnh5=qcoqHftvdNTsk+Yyc0uJkcOPqZk5bMQ@mail.gmail.com>
To: Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>
Cc: Mohit Sethi <mohit@iki.fi>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000acc248061542a661"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Ou3v2NyE9CuvH2HVL0TVxaTeRM>
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: Thu, 04 Apr 2024 10:17:53 -0000

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there seen to be
two issues. First it changes the semantics of the extension slightly, and
second the RFC explicitly excludes x.509 certs.

IIUC the semantics of the extension are "I have a weird client cert", not
"I have a client cert".

With respect to whether this needs to be a working group item, I'm not
particularly averse to this being an independent document if that's where
the WG thinks it should go.
In my opinion, however, there are two things that it would be good to get
input from the TLS WG on.

One, this is a change from all previous versions of TLS in which the client
cannot induce auth, does enabling this break anyone's assumptions?

Two, I'd like a low flag number because it saves bytes on the wire, but
there is a discussion to be had as to how common this flag will be versus
other flags.
(Non-attack) Bot traffic is very common, but it's not the majority of
traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton, <cpatton=
40cloudflare.com@dmarc.ietf.org> wrote:

> It would be great to here from Jonathan (the author) if RFC 7250 is
> already sufficient for this use case.
>
> On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi <mohit@iki.fi> wrote:
>
>> Please see my earlier comment regarding this draft:
>> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>>
>> In summary: the functionality of this draft is already achievable by
>> using the client_certificate_type extension defined in RFC 7250:
>> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
>> value = 0:
>>
>> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
>> .
>>
>> The table in section 4.2 of RFC8446 even mentions that the extension can
>> be included in the ClientHello:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
>> ensuring that the server sends a CertificateRequest message in response
>> to the ClientHello received.
>>
>> OpenSSL already implements this extension since it was needed for
>> support raw public keys (RPKs).
>>
>> As stated earlier: if it is indeed the case that the
>> client_certificate_type extension is suitable for the use-case, then
>> perhaps it is preferable to not have a separate flag. Otherwise, it
>> would make the state machine at the server more complicated (for
>> example: handling a ClientHello with both the mTLS flag and the
>> client_certificate_type extension.
>>
>> Therefore, like Ekr, I am mildly negative on adopting this document but
>> for different reasons.
>>
>> --Mohit
>>
>> On 4/3/24 00:52, Sean Turner wrote:
>> > At the IETF 119 TLS session there was some interest in the mTLS Flag
>> I-D (
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0)
>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D&reserved=0
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> >
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D&reserved=0
>>
>> _______________________________________________
>> 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
>