[TLS][Editorial Errata Reported] RFC6347 (8089)
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
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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS]Consensus call for RFC8773bis Formal Analysis Requirement
In regard to moving RFC 8773 to standards track the formal analysis triage group has provided input on the need for formal analysis which was posted to the list [1]. The authors have published a revision of the draft [2] to address some of this feedback, however the general sentiment of the triage panel was that there should be some additional symbolic analysis done to verify the security properties of the draft and to verify there is no negative impact on TLS 1.3 security properties. The formal analysis is to verify the following properties of the proposal in the draft: - The properties of the handshake defined in Appendix E.1 of RFC8446 [3] remain intact if either the external PSK is not compromised or (EC)DH is unbroken. - The public key certificate authentication works as in TLS 1.3, and this extension adds the condition that the party has possession of the external PSK. The details of external PSK distribution are outside the scope of this extension. This is a consensus call for the working group to determine how to proceed between these two options: 1. Require formal analysis in the symbolic model to verify that the proposal in the document does not negatively impact the security properties of base TLS 1.3 and that the additional security properties cited above are met 2. Proceed with publishing the document without additional formal verification Please respond to the list with a brief reason why you think the document requires formal analysis or not. This call will end on September 16, 2024. Thanks Joe, Deirdre, and Sean [1] https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/ [2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-8773bis-00&url2=draft-ietf-tls-8773bis-02&difftype=--html [3] https://www.rfc-editor.org/rfc/rfc8446.html#appendix-E.1 ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [Editorial Errata Reported] RFC6347 (8089)
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
> 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
>
> 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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
On Fri, 23 Aug 2024, 19:30 Joseph Salowey, wrote: > Please respond to the list with a brief reason why you think the document > requires formal analysis or not. This call will end on September 16, 2024. > What's the goal? Security guarantees: Do the work. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]tls - New Meeting Session Request for IETF 121
A new meeting session request has just been submitted by Deirdre Connolly, a Chair of the TLS Working Group. - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Deirdre Connolly Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 120 Conflicts to Avoid: Chair conflict: wish masque emu mls pearg privacypass dult cfrg wimse Technology overlap: quic lamps lake dnsop dprive cfrg oauth cfrg Key participant conflict: ppm maprg gendispatch privacypass webtrans saag secdispatch httpbis ohai cfrg Can't meet: Friday morning, Friday early afternoon, Friday late afternoon Participants who must be present: Eric Rescorla Resources Requested: Special Requests: Please don't conflict with the WIMSE BOF - ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [Editorial Errata Reported] RFC6347 (8089)
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
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 <
> 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:
> > https://www.rfc-editor.org/errata/eid8089
> >
> > --
> > Type: Editorial
> > Reported by: Kamil Milewski
> >
> > 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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
