Re: [TLS] [Technical Errata Reported] RFC6347 (5186)

Eric Rescorla <ekr@rtfm.com> Tue, 28 November 2017 04:01 UTC

MIME-Version: 1.0
In-Reply-To: <20171128034355.CCDBCB80D43@rfc-editor.org>
References: <20171128034355.CCDBCB80D43@rfc-editor.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 27 Nov 2017 20:00:17 -0800
Message-ID: <CABcZeBOJdaJ9vqe49TDZi4BM5CxD39G=VsRu1HQVNa0mFbX=MA@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Nagendra Modadugu <nagendra@cs.stanford.edu>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Joseph Salowey <joe@salowey.net>, sean+ietf@sn3rd.com, chenwumao@hisilicon.com, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043d7d60ff8c6b055f031040"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BlbrFqtxYmXMVlrB1NKhvnm_Pjo>
Subject: Re: [TLS] [Technical Errata Reported] RFC6347 (5186)
Precedence: list

I'm pretty sure record_sequence_number is correct. The MSN is always 0 for
HVR and 1 for SH,

-Ekr


On Mon, Nov 27, 2017 at 7:43 PM, RFC Errata System <
rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6347,
> "Datagram Transport Layer Security Version 1.2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5186
>
> --------------------------------------
> Type: Technical
> Reported by: Chen Wumao <chenwumao@hisilicon.com>
>
> Section: 4.2.4
>
> Original Text
> -------------
> [p17]                                                 In order to avoid
>    sequence number duplication in case of multiple HelloVerifyRequests,
>    the server MUST use the record sequence number in the ClientHello as
>    the record sequence number in the HelloVerifyRequest.
>
> [p17]                  In order to avoid sequence number duplication in
>    case of multiple cookie exchanges, the server MUST use the record
>    sequence number in the ClientHello as the record sequence number in
>    its initial ServerHello.
>
> Corrected Text
> --------------
> [p17]                                                 In order to avoid
>    sequence number duplication in case of multiple HelloVerifyRequests,
>    the server MUST use the message_seq in the ClientHello as
>    the message_seq in the HelloVerifyRequest.
>
> [p17]                  In order to avoid sequence number duplication in
>    case of multiple cookie exchanges, the server MUST use the
>    message_seq in the ClientHello as the message_seq in
>    its initial ServerHello.
>
> Notes
> -----
> the "record sequence number" here should be message_seq.
>
> 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.
>
> --------------------------------------
> RFC6347 (draft-ietf-tls-rfc4347-bis-06)
> --------------------------------------
> Title               : Datagram Transport Layer Security Version 1.2
> Publication Date    : January 2012
> Author(s)           : E. Rescorla, N. Modadugu
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>

[TLS] [Technical Errata Reported] RFC6347 (5186) RFC Errata System
Re: [TLS] [Technical Errata Reported] RFC6347 (51… Eric Rescorla