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