Re: [TLS] Servers sending CA names

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 13 April 2023 02:35 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 52C98C1782D7 for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 19:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 eqEJW02VTfda for <tls@ietfa.amsl.com>; Wed, 12 Apr 2023 19:35:55 -0700 (PDT)
Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (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 970D8C1782C4 for <tls@ietf.org>; Wed, 12 Apr 2023 19:35:54 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2240.outbound.protection.outlook.com [104.47.71.240]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-92-KNu_7fN8PQyRiGNqVBBq8g-1; Thu, 13 Apr 2023 12:35:51 +1000
X-MC-Unique: KNu_7fN8PQyRiGNqVBBq8g-1
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SY6PR01MB7551.ausprd01.prod.outlook.com (2603:10c6:10:172::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.28; Thu, 13 Apr 2023 02:35:50 +0000
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::4bfd:5604:b68:1e2e]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::4bfd:5604:b68:1e2e%5]) with mapi id 15.20.6298.030; Thu, 13 Apr 2023 02:35:50 +0000
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Servers sending CA names
Thread-Index: AQHZbX8pwn/3qKB5+0e2MbhfPCZiVq8ohgzg
Date: Thu, 13 Apr 2023 02:35:50 +0000
Message-ID: <SY4PR01MB6251C4EFDC709A6C99160362EE989@SY4PR01MB6251.ausprd01.prod.outlook.com>
References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com>
In-Reply-To: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com>
Accept-Language: en-NZ, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SY4PR01MB6251:EE_|SY6PR01MB7551:EE_
x-ms-office365-filtering-correlation-id: 0f62989a-876b-4657-1c30-08db3bc7cb9c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: wjyKXOGZg8R+2Vfqu7dd7YYzEG0h3xEawSOvt6Uxxdhl+zSnu22ApJ5F3Lh/MywCmK/x5x1Rmrmya5ppKxwgwTbvj+anRH+HNtrMXHjqgwEFBMXZyXSjfh57CLPYDYOMIiQ0SIUoB8E/aFuh7gzCxykZSDez9gsBtCI1kFm68SoDZvUdp/4AOaUwifii+MtDKtJWc6IassnaHUqNfDRYU6LY9xiuP5a65+io0ix0QZcz0MP1nn+MECKmj57vtSgvRVnqs2AZIE02oDTsRLcxCBA6nAElHSV0w9TMNwyEhiu8JzObzyEJQ0BvH5BJ5lRwEii/mZWYzl8yoqcVnMajvlmLmFHEPKu9UByXcDhKrl13ypVD5cs4M3p4Q8zX5A62PJ/vJW2kyn9xAc9Pyz/uLY9YKob72m9dYnzANt9zbT6ZzoMBJAmR5Np0nNIgdpFkPcNN//eBj8D1IDkPcF6AkWo6rKDRZTgUxGHMkDiyMDjqKI3RCC11Kl04gPPPSY5E5ieXxPPQP7aLq7zpglXYZN+EA5Y0fYJ6/LU5nKTjVNIPwGTxl7PeKcXDn9iTd8fvFfdyA/e1HJ0WCv5YqSfRpNeTirs85cCjWFzq3hDInnDwpVJsukikkufHsy2EM5d8
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(346002)(396003)(136003)(366004)(376002)(39860400002)(451199021)(33656002)(83380400001)(3480700007)(107886003)(76116006)(6506007)(7696005)(71200400001)(110136005)(26005)(186003)(9686003)(2906002)(52536014)(38100700002)(5660300002)(316002)(786003)(64756008)(66446008)(66946007)(122000001)(4326008)(66476007)(86362001)(38070700005)(8676002)(8936002)(55016003)(41300700001)(66556008)(478600001); DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ccIjY5piC1Xalc/CeBa3zLXrjl6Augl7r5XJMOc1pKjq+qz9YLbYKnGefsUmJGeAkWs42pEv5HaHpcqOGvf0SsTyrcfRetQoEbg+0hd3pEwW3U2JCpTtAqa2y41CSCUwyP2l1gC0/eiMKzyJjYCb0nRubwbyMEJmkhISeuwzVAnvt0xUBAofRL3D3LxoZR60cyIsdMKH7TIkz0R5urhJu4UnMoyZVD/qbq7Z10/mZ+eV/vaneC22tFyUFS3SRe9lr2anHP/4dDcfEfs5Vk/iP3ibXBDxfTYUDw6yB8/cZEb10W7lyFSZxm3ix5U2Ushe6rii9O/a7DsWg5DjMIANG/m9DhgZeJvTuzuEKp7JpWvrK/+1wVOcT8AfK0wO0MqLzrevr4UaZF/LK3YvU4UljFUH9N4u0y4WK5CStNEIQcgy0Lcch50XzLHOe4ILSLEUFqbqMByz80AMeFZ8+vu7PVMQH1S/bwS910/u4jOLGZrL91AroCQ/eq1ZV2rQZcZEbeUPvBsKsn9p1wN4VLuU6/Wch8/PuYX+yNrcJlt9rzrqqQ2VH+h/iBMTCJOIta8y4caReD8PGxwz3JQ1RwgJb1+ICQwUwcsFyuveOSPWNH4eXJFJHKWPmARqwlN3qxTKmOqmgPGTr6eLf51vSCbRa7vDN7UXqsqBVImDe045VreiYJPeUm8P0laOc88hGfFWuUkl37dWbXdlyh22Ol3Dp9bzwypWibRfoSJzUT090uaxjruOUgfUZJcDrnX0zHaC+hlaAEJZxp4AKX8wo7UOZ+RSNQY0AT8EzWvs0godhLH4s08ubcxrsknAQ7Q4yPs1OsvB0sG+jipR3LoVh8d6UDbpN860cneypdysoVsLOz4saR0ByqaQAT8q447sayOkAnfb+2+iMiLiTelkD7h8mABtzZOOPIHAzHoQ5cbC17TJCDxz5cfrmJBeI91brX/zMQKLqjhb4PUSXJTGv2/AK9qm7QXaZf+SOgM84GV8aYFvd025Mgr4I2kfd00dboZTV3HJVo6NHAk1hSVNvVESeUW6nOcrv3GlSwFpVxRYmzeO0xe+avl39VH/STOTAk8wbaqVi+p5BjRUVi+twt0i3BdZ22JMLhsHKi8e3jgeoKIqU5gIq2q3DMkWprlxEUgfqqcA0X0LS75GoL9DEemRyQljJKxzr6i2twzS0zHYu4+Tdu9MU1gai4PUSzzC14krM4clMCKtoo0SySJLQuy7MNpC/yg1tcQT/kaeGFSyaDkjuTB2QcnEl0H6BIGl4t4EiTTxmiHdV8cDrYI5wkq9vSfZmtgEMYPd70Zd8PJxvN6quj6IB0gSFQ4cXt7kNavyBaCjj+eiBuKGOqoCic5g/Ff5vzj7ygUT9MpXN7JzWv6x9AJvw3LayScVZDHSw1PSUQlcGiRzfOC16U+cMn7sXDJEDfzTuCnA5VpNFRr6Lyavd/EfqhilBRvqZK5Oltcl4PuJriDnG75oB5A69RbNZI9PtKn1HG3BW2ANKvIK3Qe48eYAR4rgMedYCFRicWmlCm6wPkkhaHvbtDhMDt3VkVmKFYvxA55kr3rzjiTLdPgQLLKYLYvFjZNFmhFiv3+G
MIME-Version: 1.0
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f62989a-876b-4657-1c30-08db3bc7cb9c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2023 02:35:50.3317 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3WD46Tl2lGDF/FnZIFvkIkTdON1uIHJg5skeQ2Dblk/3/XSagAlDGLqJdOFp8+/qOQGb5fSw1+B/y660c/kkFJryoiEIE4eH3cNNz41hwE4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY6PR01MB7551
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: cs.auckland.ac.nz
Content-Language: en-NZ
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eUtzagugoYq-dltSJIv4ba6i9aM>
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: Thu, 13 Apr 2023 02:35:57 -0000

Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> writes:

>Is this generally used?  Would things go badly if we stopped sending them?

Just as a data point, in the SCADA world it seems to be universally ignored.
I've seen everything from servers that send a list containing every CA in
existence, so much data in that one field that it overflows the TLS maximum
message size (when queried the server admins asked what a CA name list was,
and what it was used for), to a few random CA names that don't correspond to
anything they'll accept (when queried the server admins asked what a CA name
list was, and what it was used for), to nothing at all.  I've also seen plenty
of servers that send cert requests to the client without actually wanting a
cert (when queried the server admins asked what a cert request was, and what
it was used for).

The behaviour to make things work in this environment is to treat the cert
request as a no-biased boolean:

* No cert request present -> Proceed
* Cert request present, no cert available -> Proceed
* Cert request present, cert available -> Auth with whatever cert you happen
	to have using whatever algorithm it happens to use.

So far this has produced zero complaints about things breaking.  The fact that
they've not received complaints from anyone else either indicates that pretty
much every other implementation is doing something along similar lines.

Peter.