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

Martin Thomson <mt@lowentropy.net> Thu, 04 June 2020 01:07 UTC

Return-Path: <mt@lowentropy.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 705413A0C0A for <tls@ietfa.amsl.com>; Wed, 3 Jun 2020 18:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=QqsUfk8l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vdjShyoR
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 3rRsqoAtcEry for <tls@ietfa.amsl.com>; Wed, 3 Jun 2020 18:07:03 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359793A0C08 for <tls@ietf.org>; Wed, 3 Jun 2020 18:07:03 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 159D8622 for <tls@ietf.org>; Wed, 3 Jun 2020 21:07:02 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 03 Jun 2020 21:07:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=468outCF1ZtACdw1KPINFo2Enhh39c2 gvAdw/ObXgKo=; b=QqsUfk8lwEiGnnF98k8HfIrB0ES1kme6gU6hQ7/R5a+hPkJ tT6M57N+MI63cClYrfA9qKdDaRVVGaTp8Y0bzzHMATcuK62juxOdMjrg38kdc0He i+OPY/Z0yFl+HFd0t8qAeWbZk7RyRsp/MIEjsNnWcf2myFq8t5yXsnvMFGFx3E5R 06ueJx1M3FK5xb/pmmcvVXyQWaxBdiGXcSPYgfGFMsW/bb91pRmXDHfK/+mLS0tg puB61Lf+97hxGD/7zmXFyRo1suRtLBAsuDDSNWcbP6OEB4AvU+0Xqfdf+V5lltJU +oQw7eBa23+AwQ/vq1TkaacV2tCXQET3A1mx0VA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=468out CF1ZtACdw1KPINFo2Enhh39c2gvAdw/ObXgKo=; b=vdjShyoR1CMaEooPs7+970 rr00+ykP6M6JqHTUUglo9hVdb17gpfF6dt82eD4e4NU/TRuvxQ4p6QIGl34X5PQR 6jv8Vw8tMgdgbQDNPSNE4nGMemfOI+GXQL7WOaZ+rnYYxaKbsSqUXmuDM4fZQE1T Qxui4/uyBZ9IJ1UoZvYQpjvVPqIDOZTioFMr2OQudTceBKRR1/twkZ6/bJwg8KNK muUOJftHhLLTCcQJgTWFBA3Q7rHkAQyeAiJtoazc00hMXuqR7syqKDrvGX2rDdnH TKscWgvcSWgphJjmZgmnkyL4vP5kJpk/T8BdsEXuF/eW6fLbUA6i3X9IvCKYWVWw ==
X-ME-Sender: <xms:NUnYXoW-D8ukt2DebvnCkdFlRJ47qfQHK3dcIl3UkKXcYt2paDTfEQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefggfdvgfelveejtdefge dugeelkeeukeffgefggfethedthfejudfhkeegtdeifeenucffohhmrghinhepihgvthhf rdhorhhgpdhrfhgtqdgvughithhorhdrohhrghdpshhprhhinhhgvghrrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:NUnYXsm4cdulNImKZDY9O6ONf8kcxVzDi1fU0CD50cGGUmc8D7Blcg> <xmx:NUnYXsabHDpPT8Q8QecFjgq3zQ4zou_GlLAD-sM6858OB1Mkn93tVA> <xmx:NUnYXnWjjQWrEjIHtk-g-xny6Jdn2tSyWz7YmTcZSIoiDVOV1vGbxQ> <xmx:NUnYXonwWHTBT2PX16I6JloFIgLtHNcsohM0i1nUugF4YYvQp9_dvg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 52A37E00C9; Wed, 3 Jun 2020 21:07:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6
Mime-Version: 1.0
Message-Id: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com>
In-Reply-To: <20200604000011.387A5F4070F@rfc-editor.org>
References: <20200604000011.387A5F4070F@rfc-editor.org>
Date: Thu, 04 Jun 2020 11:06:42 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ovfIlyIUg82vas9lUAk7v12-S9w>
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 01:07:06 -0000

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, [...]


On Thu, Jun 4, 2020, at 10:00, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6204
> 
> --------------------------------------
> Type: Editorial
> Reported by: Chris Wood <caw@heapingbits.net>
> 
> Section: E.1
> 
> Original Text
> -------------
> Implementations MUST NOT combine external PSKs with certificate-based 
> authentication of either the client or the server unless negotiated by 
> some extension.
> 
> Corrected Text
> --------------
> Implementations MUST NOT combine external PSKs with certificate-based 
> authentication of either client or the server. Future specifications 
> MAY provide an extension to permit this. 
> 
> Notes
> -----
> The existing text can be misread as permitting this combination upon 
> negotiation of the "post_handshake_auth" extension, which would be 
> incorrect. [1] describes an attack that can occur based on this 
> misinterpretation. The proposed text aims to make clear that a *new* 
> extension is required for this combination. 
> 
> [1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8446 (draft-ietf-tls-tls13-28)
> --------------------------------------
> Title               : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date    : August 2018
> Author(s)           : E. Rescorla
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>