Re: [TLS] [Editorial Errata Reported] RFC7919 (7579)
Hi Paul,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata
report 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/).
You may review the report at:
https://www.rfc-editor.org/errata/eid7579
Please see https://www.rfc-editor.org/how-to-verify/ for further
information on how to verify errata reports.
Further information on errata can be found at:
https://www.rfc-editor.org/errata.php.
Thank you.
RFC Editor/rv
> On Jul 31, 2023, at 10:06 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7919,
> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport
> Layer Security (TLS)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7579
>
> --
> Type: Editorial
> Reported by: Tim Geiser
>
> Section: Appendix A
>
> Original Text
> -
> The primes in these finite field groups are all safe primes; that is,
> a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is
> the base of the natural logarithm and square brackets denote the
> floor operation, the groups that initially populate this registry are
> derived for a given bit length b by finding the lowest positive
> integer X that creates a safe prime p where:
>
> p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1
>
>
> Corrected Text
> --
> The primes in these finite field groups are all safe primes; that is,
> a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is
> the base of the natural logarithm and square brackets denote the
> floor operation, the groups that initially populate this registry are
> derived for a given bit length b by finding the lowest positive
> integer X that creates a safe prime p where:
>
> p = 2^b - 2^{b-64} + {[2^{b-130} * e] + X } * 2^64 - 1
>
>
> Notes
> -
> The multiplication sign ('*' in ASCII) is missing in the explanatory
> introduction of Appendix A that describes the equation used for deriving the
> primes. It is correct in all five concrete derivations A.1 through A.5
>
> 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.
>
> --
> RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)
> --
> Title : Negotiated Finite Field Diffie-Hellman Ephemeral
> Parameters for Transport Layer Security (TLS)
> Publication Date: August 2016
> Author(s) : D. Gillmor
> 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
Re: [TLS] [Editorial Errata Reported] RFC8996 (7739)
Greetings, FYI - this report has been deleted as junk (identical text is listed in Original Text, Corrected Text, and Notes, and this text does not even appear in this RFC). Thank you. RFC Editor/rv > On Dec 21, 2023, at 7:02 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8996, > "Deprecating TLS 1.0 and TLS 1.1". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7739 > > -- > Type: Editorial > Reported by: mohamed abdurahman hassan > > 96 > > Original Text > - > > application. The authorization server should take special care when > enabling this grant type and only allow it when other flows are not > viable. > > This grant type is suitable for clients capable of obtaining the > resource owner's credentials (username and password, typically using > an interactive form). It is also used to migrate existing clients > using direct authentication schemes such as HTTP Basic or Digest > authentication to OAuth by converting the stored credentials to an > access token. > > > Corrected Text > -- > > application. The authorization server should take special care when > enabling this grant type and only allow it when other flows are not > viable. > > This grant type is suitable for clients capable of obtaining the > resource owner's credentials (username and password, typically using > an interactive form). It is also used to migrate existing clients > using direct authentication schemes such as HTTP Basic or Digest > authentication to OAuth by converting the stored credentials to an > access token. > > > Notes > - > application. The authorization server should take special care when > enabling this grant type and only allow it when other flows are not > viable. > > This grant type is suitable for clients capable of obtaining the > resource owner's credentials (username and password, typically using > an interactive form). It is also used to migrate existing clients > using direct authentication schemes such as HTTP Basic or Digest > authentication to OAuth by converting the stored credentials to an > access token. > > 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. > > -- > RFC8996 (draft-ietf-tls-oldversions-deprecate-12) > -- > Title : Deprecating TLS 1.0 and TLS 1.1 > Publication Date: March 2021 > Author(s) : K. Moriarty, S. Farrell > Category: BEST CURRENT PRACTICE > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS]Re: [Editorial Errata Reported] RFC9147 (8051)
Hi Paul, We consider the proposed change from "initial handshake” to “handshake” in this erratum report to be above 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/). Also, as the submitter notes, "initial handshake” appears three times in the document (Sections 6.1, 8, and 11). Perhaps this erratum report should be updated to GLOBAL and only include the original and corrected term in the OLD/NEW text rather than sentences from just one of the sections affected. We are happy to make this change if that would be helpful. Just let us know. You may review the report at: https://www.rfc-editor.org/errata/eid8051 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 Thank you, RFC Editor/rv > On Jul 25, 2024, at 10:22 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC9147, > "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8051 > > -- > Type: Editorial > Reported by: David Benjamin > > Section: 6.1 > > Original Text > - > * Epoch value (2) is used for messages protected using keys derived > from [sender]_handshake_traffic_secret. Messages transmitted > during the initial handshake, such as EncryptedExtensions, > CertificateRequest, Certificate, CertificateVerify, and Finished, > belong to this category. Note, however, that post-handshake > messages are protected under the appropriate application traffic > key and are not included in this category. > > Corrected Text > -- > * Epoch value (2) is used for messages protected using keys derived > from [sender]_handshake_traffic_secret. Messages transmitted > during the handshake, such as EncryptedExtensions, > CertificateRequest, Certificate, CertificateVerify, and Finished, > belong to this category. Note, however, that post-handshake > messages are protected under the appropriate application traffic > key and are not included in this category. > > Notes > - > The discussion of "initial handshake" appears to be a remnant of DTLS 1.2, > where a single connection may have multiple handshakes via renegotiation. In > (D)TLS 1.3, there is only one handshake per connection. > > Looking to RFC 8446, the only references to "initial handshake" refer to > resumption, talking about the handshake in the initial connection, vs the > handshake in resumption connections. This reference is not trying to > distinguish initial vs resumption handshakes, so the use of "initial > handshake" is a bit confusing. I believe plain "handshake" is the right > terminology. > > NB: There are two other references to "initial handshake", one in the diagram > in Section 8, and another in Section 11. I believe they too should be > switched to "handshake". > > 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. > > -- > RFC9147 (draft-ietf-tls-dtls13-43) > -- > Title : The Datagram Transport Layer Security (DTLS) Protocol > Version 1.3 > Publication Date: April 2022 > Author(s) : E. Rescorla, H. Tschofenig, 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: [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
