[TLS]Re: [Editorial Errata Reported] RFC6347 (8089)

[Eric Rescorla <[e-mail]>]

I don't think this is an erratum. I agree it would be better, but I don't
think that rises to "error".

-Ekr


On Fri, Aug 23, 2024 at 11:17 AM Rebecca VanRheenen <[e-mail]>
wrote:

> Hi Paul,
>
> We are unable to verify this erratum that the submitter marked as
> editorial, so we changed the Type to “Technical”. As Stream Approver,
> please review and set the Status and Type accordingly (see the definitions
> at https://www.rfc-editor.org/errata-definitions/)
>
> Notes:
> * RFC 6347 has been obsoleted by RFC 9147. We see similar blocks of code
> in Section 5.2 and Appendix A.2 of RFC 9147.
> * For information about errata on obsolete RFCs, see #7 in the IESG
> Statement on "IESG Processing of RFC Errata for the IETF Stream” (
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> ).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid8089
>
> Information on how to verify errata reports can be found at:
> https://www.rfc-editor.org/how-to-verify/
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php
>
> Best regards,
> RFC Editor/rv
>
>
> > On Aug 23, 2024, at 6:26 AM, RFC Errata System <
> [e-mail]> 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:
> > https://www.rfc-editor.org/errata/eid8089
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Kamil Milewski <[e-mail]>
> >
> > Section: 4.2.2
> >
> > Original Text
> > -------------
> >   struct {
> >     HandshakeType msg_type;
> >     uint24 length;
> >     uint16 message_seq;                               // New field
> >     uint24 fragment_offset;                           // New field
> >     uint24 fragment_length;                           // New field
> >     select (HandshakeType) {
> >       case hello_request: HelloRequest;
> >       case client_hello:  ClientHello;
> >       case hello_verify_request: HelloVerifyRequest;  // New type
> >       case server_hello:  ServerHello;
> >       case certificate:Certificate;
> >       case server_key_exchange: ServerKeyExchange;
> >       case certificate_request: CertificateRequest;
> >       case server_hello_done:ServerHelloDone;
> >       case certificate_verify:  CertificateVerify;
> >       case client_key_exchange: ClientKeyExchange;
> >       case finished: Finished;
> >     } body;
> >   } Handshake;
> >
> > Corrected Text
> > --------------
> >   struct {
> >     HandshakeType msg_type;
> >     uint24 length;
> >     uint16 message_seq;                               // New field
> >     uint24 fragment_offset;                           // New field
> >     uint24 fragment_length;                           // New field
> >     select (HandshakeType) {
> >       case hello_request: HelloRequest;
> >       case client_hello:  ClientHello;
> >       case server_hello:  ServerHello;
> >       case hello_verify_request: HelloVerifyRequest;  // New field
> >       case certificate:Certificate;
> >       case server_key_exchange: ServerKeyExchange;
> >       case certificate_request: CertificateRequest;
> >       case server_hello_done:ServerHelloDone;
> >       case certificate_verify:  CertificateVerify;
> >       case client_key_exchange: ClientKeyExchange;
> >       case finished: Finished;
> >     } body; } Handshake;
> >
> > Notes
> > -----
> > Change the order of cases inside select field to keep it:
> > 1. In ascending order
> > 2. Consistent with the structure in 4.3.2
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will 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
> > Stream              : IETF
> > Verifying Party     : IESG
> >
>
>