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-edi...@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 <chenwu...@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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to