Re: [TLS] [EXTERNAL] Re: Servers sending CA names

Martin Thomson <mt@lowentropy.net> Thu, 13 April 2023 01:04 UTC

Return-Path: <mt@lowentropy.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 01109C15C288 for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 18:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=lowentropy.net header.b="q66a5NCK"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Lt7GUZa3"
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 Z5G9dmTMbiUa for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 18:04:09 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 E9BB6C1522CD for <tls@ietf.org>; Wed, 12 Apr 2023 18:04:09 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3B15F3200957 for <tls@ietf.org>; Wed, 12 Apr 2023 21:04:07 -0400 (EDT)
Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Wed, 12 Apr 2023 21:04:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1681347846; x=1681434246; bh=7hOCP5dNxZEq+yGFPN10JWx6mYmgl0H4CaP OhbNDQR4=; b=q66a5NCKLFthyIfQ0kZpS2WQoG5eM0qV0ShkgPelGlvTX5RkytY zZmAv0yKHHYoQn/nno3WUbhYhz31RQAKZ4zF7HxtlzWYAOrG4VOBTEr/iZiWkiV9 P2PC603eaxZQ110qTpQb7w+jyZbZbil0biO6ThfOQei+BuzKMT4bNQFMHCNNeYRD dUqEfNkHIFGB5NnGEUwJQYI092pLaLA0kRHUMqiH6ZN8FS20+nfiWNEgucflCjD2 57w7RyUwsTshqq0Ycu6GoeSg1sEf7uVwIkV8t0IzyPoxT/F0aKxuEyGuRkS0NOjA /yUCP/ljV/c2LDuDRyBDDdVG3jxOHtGrQXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1681347846; x= 1681434246; bh=7hOCP5dNxZEq+yGFPN10JWx6mYmgl0H4CaPOhbNDQR4=; b=L t7GUZa3JIa3rdsVh9R8WHHO2p5Rf0rVQhQmRjy0jn54GBJgU5La1hAqrPZz1Ssol yzbLeiIIK32tQK5/xKblHt2fYWd1AfBCG7Bi9WcC116/n8Tj55XFEfNnK2wmhmqY 4tyFVJ41lA3O0ldmIKcI0xxpu8/tVkFhJYUTHDQyeV8shVMhxJ9NZ+1urD2PyFs1 y0OQodN1DN4Y7i+ZpSPsO4mQN1Q8Q3KsA52noPp8hXQUZ8GQVMtMDmWECkxxxaQp QTF01YtQbCAQ8TOfs+o2TREW+FsdjG9oVBKnF8G0Fvz3iE98o1kW/IL/kOjogKDJ HvSQjE9flho/mG1ogkhpw==
X-ME-Sender: <xms:BlU3ZAGKjCLQW8cvyiYiiEcZgEoNIT-4s0hZLxYnzO5hWYLW-hKJyg> <xme:BlU3ZJXEtVhKjEyIUByymiIKV3HDCJf9ief5HiVCr1TdOcjXmTNgJGeR3Ht4jRvY3 f6E1mhlSL2tuZiuXNw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekjedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:BlU3ZKLpvnouhUP89yZ4lE9d2W8zg8882o2bkYHU9OVCeNJWoVZ6xw> <xmx:BlU3ZCFybOu8RRCKwQg3JBEiS-zpM3Vu48Fw3lHYg-qfYhb9chhN4g> <xmx:BlU3ZGUCZrwLPzy3GdDAqFCCNv3Y2EJgkcbhdA7DR54JL22y_-pilA> <xmx:BlU3ZOjTSdvYy_IYFJrNwrMhwaRD565CCzBADLtOEq2upqrwSEJiIQ>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E3EEBC0078; Wed, 12 Apr 2023 21:04:06 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6
Mime-Version: 1.0
Message-Id: <accacacd-2bd6-4c89-8221-0c32b1a25ae3@betaapp.fastmail.com>
In-Reply-To: <BY5PR00MB06757280F69B9C6D55AD2B048C9BA@BY5PR00MB0675.namprd00.prod.outlook.com>
References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com> <ZDcbv4g5-tjN-Mu-@straasha.imrryr.org> <CAF8qwaBaOq1_Ow_vtB=DGjjDkAx+N+CPMpfn1huP=DRsCiFtaA@mail.gmail.com> <BY5PR00MB06757280F69B9C6D55AD2B048C9BA@BY5PR00MB0675.namprd00.prod.outlook.com>
Date: Thu, 13 Apr 2023 11:03:47 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ilMraI50a3eL-rUjrOE2Dd96D5M>
Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names
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, 13 Apr 2023 01:04:15 -0000

I think that is also true for NSS, though my experience of this is not thorough.  As David notes, client certificates are something of a mess once you step outside a context where the client already knows what it should be sending.

On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote:
> Windows TLS stack uses them (when available) for certificate selection. 
> Schannel-based TLS servers don’t send CA names by default, but can be 
> configured to do so.
>
> 
> Cheers,
> 
> Andrei
> 
> *From:* TLS <tls-bounces@ietf.org> *On Behalf Of * David Benjamin
> *Sent:* Wednesday, April 12, 2023 2:16 PM
> *To:* tls@ietf.org
> *Subject:* [EXTERNAL] Re: [TLS] Servers sending CA names
> 
> Chrome also uses this to filter the set of client certificates when 
> asking the user to pick one. We also sometimes use this to figure out 
> what intermediates to send, in cases where the server does not already 
> have all its intermediates available. (Though this is not very reliable 
> and OS-dependent. Client certificate deployments are a bit of a mess.)
> 
> Omitting it may be fine in contexts where you expect clients to only 
> have one possible certificate chain and that they have a priori 
> knowledge to only send that one. That can make sense in 
> machine-to-machine communication, and makes less sense when the client 
> is a human that needs to make decisions about identities to use.
> 
> I agree with Viktor that this isn't any more optional in TLS 1.2 than 
> TLS 1.3. Optional and non-empty if present vs. mandatory but may be 
> empty express the same set of states. It's just an encoding difference, 
> motivated by extensibility and client/server symmetry, not changing 
> client certificate expectations.
> 
> On Wed, Apr 12, 2023 at 4:59 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> On Wed, Apr 12, 2023 at 08:41:31PM +0000, Salz, Rich wrote:
>> 
>> > Is this generally used?  Would things go badly if we stopped sending them?
>> 
>> I take you mean sending CA names as part of a certificate request.
>> 
>>     https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
>>     https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4
>> 
>> Yes, many servers send a non-empty list of CA names as part of
>> certificate request, and some clients (notably some Java-based clients)
>> fail to complete the handshake if the request does not list an issuer
>> associated with any of the client's available certificates.
>> 
>> So servers historically have been able to get away with an empty list,
>> hoping that the client will then send the only/default certificate it
>> typically has on hand (or not send any, but still continue the
>> handshake).
>> 
>> It looks perhaps like CA name lists are "more optional" in TLS 1.3 than
>> they were in TLS 1.2, but this impression may be just an artefact of the
>> separation of the CA names to a separate extension, rather than an
>> actual change of expected client behaviour.
>> 
>> -- 
>>     Viktor.
>> 
>> _______________________________________________
>> 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