Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Russ Housley <housley@vigilsec.com> Thu, 04 June 2020 15:47 UTC

Return-Path: <housley@vigilsec.com>
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; 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 <tls@ietf.org>; 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 <tls@ietf.org>; 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 <housley@vigilsec.com>
In-Reply-To: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com>
Date: Thu, 4 Jun 2020 11:47:39 -0400
Cc: IETF TLS <tls@ietf.org>
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 <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eZheF-Dx2Z7tQtCa82U05nOKhGI>
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." <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, 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.
> 
> There is one other piece to this that is very confusing, and less clear.
> 
> "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)."
> 
> 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.
> 
> However, the document already says:
> 
> "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."
> 
> So I think that the right interpretation is that this statement applies to "a resumption PSK" only.
> 
> If people agree with this interpretation, then I will file another erratum of the form:
> 
> 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