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

[Sean Turner <[e-mail]>]

Since this is correctly marked as “Editorial” are there any objections to changing the state to “Hold For Document Update”?

spt

> On Aug 23, 2024, at 18:18, Eric Rescorla <[e-mail]> wrote:
> 
> 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
> > 
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]