Re: [TLS] Servers sending CA names

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 12 April 2023 20:59 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2CEA4C1516EB for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 13:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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
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 RXyiXy3mp3sQ for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 13:59:45 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 1771FC15153C for <tls@ietf.org>; Wed, 12 Apr 2023 13:59:44 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3D417121EDD; Wed, 12 Apr 2023 16:59:43 -0400 (EDT)
Date: Wed, 12 Apr 2023 16:59:43 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <ZDcbv4g5-tjN-Mu-@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WU2mvVI_L56qaenRv2hD6cjCP60>
Subject: Re: [TLS] 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: Wed, 12 Apr 2023 20:59:46 -0000

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.