[TLS] Is client authentication allowed using PSK/SRP suites
Jack Lloyd <jack@randombit.net> Sun, 17 May 2020 11:46 UTC
Return-Path: <jack@randombit.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 202633A0FE7 for <tls@ietfa.amsl.com>; Sun, 17 May 2020 04:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxtZZAert6lx for <tls@ietfa.amsl.com>; Sun, 17 May 2020 04:46:49 -0700 (PDT)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309933A0AFA for <tls@ietf.org>; Sun, 17 May 2020 04:46:49 -0700 (PDT)
Received: from anne.randombit.net (ul [216.57.127.154]) (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 maple.randombit.net (Postfix) with ESMTPS id 461FFA0371 for <tls@ietf.org>; Sun, 17 May 2020 07:46:47 -0400 (EDT)
Received: by anne.randombit.net (sSMTP sendmail emulation); Sun, 17 May 2020 07:46:46 -0400
Date: Sun, 17 May 2020 07:46:46 -0400
From: Jack Lloyd <jack@randombit.net>
To: tls@ietf.org
Message-ID: <20200517114646.GP4294@randombit.net>
Mail-Followup-To: tls@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dwO11ggNjUjO9XJfXBru6ZhKu5o>
Subject: [TLS] Is client authentication allowed using PSK/SRP suites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 17 May 2020 12:19:22 -0000
RFC 5246 sec 7.4.4 states that "non-anonymous" servers can request a client certificate, and otherwise attempting to request a certificate should result in a fatal alert. I would generally think of a handshake using PSK or SRP to not be anonymous but rather the peer identity is implicitly verified via use of the shared secret. But in this context I'm not sure that's the intent. For purpose of 7.4.4 does "non-anonymous" mean: - Anything besides a DH_anon_*/ECDH_anon_* ciphersuite - A ciphersuite which involves the server sending a Certificate message. - Something else? Thanks, Jack