Re: [TLS] [Technical Errata Reported] RFC8446 (6123)
Peter Wu <peter@lekensteyn.nl> Fri, 01 May 2020 10:14 UTC
Return-Path: <peter@lekensteyn.nl>
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 CF2033A0E15 for <tls@ietfa.amsl.com>; Fri, 1 May 2020 03:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=lekensteyn.nl
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 hNg5F96nOhDO for <tls@ietfa.amsl.com>; Fri, 1 May 2020 03:14:22 -0700 (PDT)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D643A0E1B for <tls@ietf.org>; Fri, 1 May 2020 03:14:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Rt5v+RM1Fpe63X1dmvYFVnA4w92XMBm26nXFmiB4T0M=; b=o2bN0XygIRrF5YfQJFDg+TMe5cAXvXiOYeNhuQDhfzQXkeJAklUHix8iXqEw9cjHBedjIqAnbh7AfnQn/UzZ48LID/DDOaLdl5IV5s9VUr/HIOt8jHUiOCOru4hgX2HXqGmHTzYuQoU9i8x00sNRDRdSt714LHhN5BMqP7Xa1m4NUEAeMVxi1d3Bqk4TSfhekjtprn5JWwC3rWVQWxbMloSWZdG7+7FLnlhVG1yxYypjTUL4VKDIP/j0b0TxfDdTBR1bEmp54HLqy8UKv1r2kTKwyFykmDrNuNEKfMM3tyBVjO8dJW7A3WZAcqvqhGRzvKWe1h3VYkwI1nyvewAKUg==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <peter@lekensteyn.nl>) id 1jUSg1-0006cQ-8Y; Fri, 01 May 2020 12:13:52 +0200
Date: Fri, 01 May 2020 12:13:47 +0200
From: Peter Wu <peter@lekensteyn.nl>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com, research@bensmyth.com, tls@ietf.org
Message-ID: <20200501101347.GC330395@al>
References: <20200424091522.8669EF40722@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200424091522.8669EF40722@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k6eSIoT6ovF1wl0QedMhg2G3EtE>
Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (6123)
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: Fri, 01 May 2020 10:14:27 -0000
Hi,
Throughout the document, it is pretty clear what optionality refers to:
1. Introduction
[...]
- Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
and from the same Protocol Overview section, 2 pages later:
- Authentication: Authenticate the server (and, optionally, the
client) and provide key confirmation and handshake integrity.
The "optionally authenticate each other" text appears to have been
carried over from TLS 1.2 and before where anonymous key exchanges were
still a thing.
I don't think there is any misinterpretation possible from someone
reading the whole section and I like the current conciseness. A longer,
but technically more accurate version could be:
[..], authenticate the server to the client, optionally authenticate
the client to the server, [..]
I suggest (reluctantly) accepting this ("Held for Document Update") or
rejecting it.
Kind regards,
Peter
On Fri, Apr 24, 2020 at 02:15:22AM -0700, 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/eid6123
>
> --------------------------------------
> Type: Technical
> Reported by: Ben Smyth <research@bensmyth.com>
>
> Section: 2
>
> Original Text
> -------------
> The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material.
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode)
>
> 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
- [TLS] [Technical Errata Reported] RFC8446 (6123) RFC Errata System
- Re: [TLS] [Technical Errata Reported] RFC8446 (61… Peter Wu