Return-Path: 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 981B03A03EA for ; Thu, 4 Jun 2020 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 4GPWnYJrP5_9 for ; Thu, 4 Jun 2020 08:47:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2703A03ED for ; Thu, 4 Jun 2020 08:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE534300B3B for ; Thu, 4 Jun 2020 11:47:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EvwY7h5JmqaK for ; Thu, 4 Jun 2020 11:47:38 -0400 (EDT) Received: from [192.168.1.161] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B29A300670; Thu, 4 Jun 2020 11:47:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> Date: Thu, 4 Jun 2020 11:47:39 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <251D504E-B349-480E-A0D7-2E3B11A612B4@vigilsec.com> References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 15:47:44 -0000 Martin: > I think that this is a useful erratum and it should be approved/HFDU. = The extension to which this text alludes is RFC 8773, not = post_handshake_auth. >=20 > There is one other piece to this that is very confusing, and less = clear. >=20 > "Servers which are authenticating with a PSK MUST NOT send the = CertificateRequest message in the main handshake, though they MAY send = it in post-handshake authentication (see Section 4.6.2) provided that = the client has sent the "post_handshake_auth" extension (see Section = 4.2.6)." >=20 > The motivation is the attack that Sam Scott et. al. found in their = analysis of resumption: = https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ = However, this statement is unclear on whether it applies to external, = resumption, or both types of PSK, but without qualification as it is you = might be forgiven for thinking that it is both. >=20 > However, the document already says: >=20 > "It is unsafe to use certificate-based client authentication when the = client might potentially share the same PSK/key-id pair with two = different endpoints." >=20 > So I think that the right interpretation is that this statement = applies to "a resumption PSK" only. >=20 > If people agree with this interpretation, then I will file another = erratum of the form: >=20 > OLD: > Servers which are authenticating with a PSK MUST NOT send the = CertificateRequest message in the main handshake, [...] > NEW: > Servers which are authenticating with a resumption PSK MUST NOT send = the CertificateRequest message in the main handshake, [...] Works for me too. Russ