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

Peter Wu <peter@lekensteyn.nl> Fri, 01 May 2020 10:24 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 2F00C3A0E3E for <tls@ietfa.amsl.com>; Fri, 1 May 2020 03:24:44 -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 QVlgwSuqYBXA for <tls@ietfa.amsl.com>; Fri, 1 May 2020 03:24:42 -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 DB38B3A0E3B for <tls@ietf.org>; Fri, 1 May 2020 03:24:41 -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=/vQY6dZuwgTz3AYUx/hKlQQ3p9bLPLSeLLoLR4rYPlc=; b=WAPqepdzUpmC2Kuxr8UEx6kLnHMUumtMV1xO2N1Xc8QSyh6UNTo6Cii1uQxM5i7AQEaMkInhFsEP0GcGsP2tB7GsVKOd9YTwmNOyhg6nP0FT3u16HS43lmt5x2H1ZFcxCMvwRW7kWZ4GUS7A9FgkNnSuAnMKMncllTrs7x4b6w5aTqdNCREPoUz+h8FqLzBceK41nfds+0TS7SJTB4H+MW68K9/gmvD0u7MLpIeIxDgI9/BRFrn+vf4GSD8r3I9pTcxL1ViHM+YUwokNRLCpDmHRucCGDTpaaC5einVyaOgwu7zftK0YJe2awA8RMPN5RD1d05IkstyaokyUoNNOKA==;
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 1jUSqP-00072i-BP; Fri, 01 May 2020 12:24:33 +0200
Date: Fri, 1 May 2020 12:24:32 +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: <20200501102432.GD330395@al>
References: <20200424091839.32D03F40722@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200424091839.32D03F40722@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yuSX1yWNRQuceC59KWcU0j00VzI>
Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6124)
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:24:44 -0000

The change is in "a list of symmetric cipher/HKDF hash pairs" and Ben
suggests changing "HKDF hash" to either "Hash algorithm" or "Hash
algorithm (to be used with HKDF)".

The hash is not just used for the HKDF, but also for Transcript-Hash, so
if this had to be changed, I would vote for "Hash algorithm". Note that
"HKDF hash" is used consistently in one other place, so that might have
to be changed as well.

Additionally, Section 7.1 defined relates both the three "hash"
functions:

    The Hash function used by Transcript-Hash and HKDF is the cipher
    suite hash algorithm.

This is a minor update to a text that was not incorrect. Not sure
whether this was really worth an errata report.

Kind regards,
Peter

On Fri, Apr 24, 2020 at 02:18:39AM -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/eid6124
> 
> --------------------------------------
> Type: Editorial
> Reported by: Ben Smyth <research@bensmyth.com>
> 
> Section: 2
> 
> Original Text
> -------------
>    In the Key Exchange phase, the client sends the ClientHello                  
>    (Section 4.1.2) message, which contains a random nonce                       
>    (ClientHello.random); its offered protocol versions; a list of               
>    symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key         
>    shares (in the "key_share" (Section 4.2.8) extension), a set of              
>    pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
>    extension), or both; and potentially additional extensions.   
> 
> Corrected Text
> --------------
>    In the Key Exchange phase, the client sends the ClientHello                  
>    (Section 4.1.2) message, which contains a random nonce                       
>    (ClientHello.random); its offered protocol versions; a list of               
>    symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key         
>    shares (in the "key_share" (Section 4.2.8) extension), a set of              
>    pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
>    extension), or both; and potentially additional extensions.   
> 
> or
> 
>    In the Key Exchange phase, the client sends the ClientHello                  
>    (Section 4.1.2) message, which contains a random nonce                       
>    (ClientHello.random); its offered protocol versions; a list of               
>    symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key         
>    shares (in the "key_share" (Section 4.2.8) extension), a set of              
>    pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
>    extension), or both; and potentially additional extensions.   
> 
> Notes
> -----
> 
> 
> 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