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

"Martin Thomson" <mt@lowentropy.net> Fri, 03 May 2019 01:56 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 CC1F0120153 for <tls@ietfa.amsl.com>; Thu, 2 May 2019 18:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=0azr0WAT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wgr6VaCI
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 ypbt80aaQ0NU for <tls@ietfa.amsl.com>; Thu, 2 May 2019 18:56:36 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C473912004D for <tls@ietf.org>; Thu, 2 May 2019 18:56:35 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F30A522C10 for <tls@ietf.org>; Thu, 2 May 2019 21:56:34 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 May 2019 21:56:34 -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=DiS0VSceAkRFbjKRvWATG+VUTcT7vuh nanxTzgY5CzA=; b=0azr0WATfxhHELQOimtSZuHZosVhuhwIHOhfYBRGeV4IhM/ SjHKiFaF92xXISsNGnq3ofrmPQmX4hmrAAhV0+nv+ChcN0ZuiPKAp2Wa5D45C3Dg F+I1X24zj3zx+tQbzeDQfgwJMjkpKdLh8I/qWRTaZzTMUU3+vY007std2c/oa0Rh 8VbUqfdOTgIJB/VvJiF+/twnNfYqtg+/ixjWGdKkcAPBjOB1nc+oNedPCDTLqsM5 DNxcs7xWIrnYsrXTbcKorGNPVfHT0yhkldroKA0DqWR75fjlVVQwGzpLok2PzjN2 FCxN41u15C7VPchtcTk9OVD7zNzAflRJ9TjwhRA==
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=DiS0VS ceAkRFbjKRvWATG+VUTcT7vuhnanxTzgY5CzA=; b=wgr6VaCI4ZmZdrepu5Nsbt 8j015i6fX+5QFfDSg9XYVSNA5hIY5/O/u20GfcAMXOrAL0YbFCQYZFwxcVliQ4FQ rMjlg5TkBJiNzDc74TH2W1p/NmBl/5GWL2vqwAT1y6dbTwqkzi2UIzX5Lhqsi759 FT2QmuRhyFG9OmNznql4IMcaAf9tXhvVMVaImQQGmI7/Y8xjSHZaM9ju8gkcwnVh f1Rt2xn1Dn4616fdAcBltfzhsWXheMHixwVJY0bZt2LO9HjU82ZmKroOLMiYpqEQ 8nQ41Nhb2/TCD7aLgr/jaiLC1FzBVgXQ239m57TAonqxAZr0gzb/Rp1UL3ozcN8Q ==
X-ME-Sender: <xms:0p_LXB8cRZ6FuG_R3lJGfqb33zce3Cxtbo0Z9sLi2RKhv7KYzUBVBQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrgh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:0p_LXDGrYqUfBoFVqk6d8BAdsbN0otsr4jd9GviMnMbT3EJ1vdTzDA> <xmx:0p_LXGVh_ziBti6fItWuOGlbHLJsXtWuiw5u5z13GDyaBsL_y5gDnQ> <xmx:0p_LXP-eGakXFhuJ3zf7WSTvKBkBuwFZxvDLX2FsKm9ETnP0zzW7WQ> <xmx:0p_LXP8BzA7u1wyzvLv5gBBoRa4gQ49ilf0A-ieUSnJuM4mRMvV5uA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7168B7C6D9; Thu, 2 May 2019 21:56:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1
Mime-Version: 1.0
Message-Id: <1079aa6b-7f8d-4855-aac6-d5ea99f07ee7@www.fastmail.com>
In-Reply-To: <20190503010413.1B044B81E0A@rfc-editor.org>
References: <20190503010413.1B044B81E0A@rfc-editor.org>
Date: Thu, 02 May 2019 21:56:36 -0400
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PB2AWcbjTLzKmBlhOTp3Cl97Z1Y>
Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5717)
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, 03 May 2019 01:56:38 -0000

Two fixes required, but then I think HFDU is appropriate:

1. Misspelling of names.

2. The pre_shared_key extension requires the use of the psk_key_exchange_modes extension.

On Fri, May 3, 2019, at 11:04, 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:
> http://www.rfc-editor.org/errata/eid5717
> 
> --------------------------------------
> Type: Editorial
> Reported by: Daniel Migault <daniel.migault@ericsson.com>
> 
> Section: 2.2.
> 
> Original Text
> -------------
> 
>  Figure 3 shows a pair of handshakes in which the first handshake
>    establishes a PSK and the second handshake uses it:
>  
>           Client                                               Server
>  
>    Initial Handshake:
>           ClientHello
>           + key_share               -------->
>                                                           ServerHello
>                                                           + key_share
>                                                 {EncryptedExtensions}
>                                                 {CertificateRequest*}
>                                                        {Certificate*}
>                                                  {CertificateVerify*}
>                                                            {Finished}
>                                     <--------     [Application Data*]
>           {Certificate*}
>           {CertificateVerify*}
>           {Finished}                -------->
>                                     <--------      [NewSessionTicket]
>           [Application Data]        <------->      [Application Data]
>  
>  
>    Subsequent Handshake:
>           ClientHello
>           + key_share*
>           + pre_shared_key          -------->
>                                                           ServerHello
>                                                      + pre_shared_key
>                                                          + key_share*
>                                                 {EncryptedExtensions}
>                                                            {Finished}
>                                     <--------     [Application Data*]
>           {Finished}                -------->
>           [Application Data]        <------->      [Application Data]
>  
>                Figure 3: Message Flow for Resumption and PSK
> 
> 
> Corrected Text
> --------------
> 
>  Figure 3 shows a pair of handshakes in which the first handshake
>    establishes a PSK and the second handshake uses it:
>  
>           Client                                               Server
>  
>    Initial Handshake:
>           ClientHello
>           + key_share               -------->
>                                                           ServerHello
>                                                           + key_share
>                                                 {EncryptedExtensions}
>                                                 {CertificateRequest*}
>                                                        {Certificate*}
>                                                  {CertificateVerify*}
>                                                            {Finished}
>                                     <--------     [Application Data*]
>           {Certificate*}
>           {CertificateVerify*}
>           {Finished}                -------->
>                                     <--------      [NewSessionTicket]
>           [Application Data]        <------->      [Application Data]
>  
>  
>    Subsequent Handshake:
>           ClientHello
>           + key_share*
>           + psk_key_exchange_modes        
>           + pre_shared_key          -------->
> 
>                                                           ServerHello
>                                                      + pre_shared_key
>                                                          + key_share*
>                                                 {EncryptedExtensions}
>                                                            {Finished}
>                                     <--------     [Application Data*]
>           {Finished}                -------->
>           [Application Data]        <------->      [Application Data]
>  
>                Figure 3: Message Flow for Resumption and PSK
> 
> 
> Notes
> -----
> The pre_shared_key requires the pre_share_key extension. As mentioned 
> by Martin Thompson figures do not necessarily guarantee all extensions 
> to be mentioned. However in this case, that would be clarifying to have 
> both extensions mentioned on the figure.
> 
> 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
>