[TLS] [Errata Verified] RFC8773 (7598)

[RFC Errata System]

The following errata report has been verified for RFC8773,
"TLS 1.3 Extension for Certificate-Based Authentication with an External 
Pre-Shared Key". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7598

--
Status: Verified
Type: Editorial

Reported by: Russ Housley 
Date Reported: 2023-08-11
Verified by: RFC Editor  

Section: 5.1

Original Text
-
When the "psk_key_exchange_modes" extension is included in the
ServerHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

Corrected Text
--
When the "psk_key_exchange_modes" extension is included in the
ClientHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

Notes
-
According to RFC 8446, the "psk_key_exchange_modes" extension only appears in 
the ClientHello message. Further, the slides presented on this topic at IETF 
101show the "psk_key_exchange_modes" extension in the ClientHello message and 
no other place.  It is pretty clear that this is an editorial error.


--
RFC8773 (draft-ietf-tls-tls13-cert-with-extern-psk-07)
--
Title   : TLS 1.3 Extension for Certificate-Based Authentication 
with an External Pre-Shared Key
Publication Date: March 2020
Author(s)   : R. Housley
Category: EXPERIMENTAL
Source  : Transport Layer Security
Stream  : IETF

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6820)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6820

--
Status: Held for Document Update
Type: Technical

Reported by: Leander Schwarz 
Date Reported: 2022-01-21
Held by: Paul Wouters (IESG)

Section: 6.2

Original Text
-
unsupported_extension:  Sent by endpoints receiving any handshake
  message containing an extension known to be prohibited for
  inclusion in the given handshake message, or including any
  extensions in a ServerHello or Certificate not first offered in
  the corresponding ClientHello or CertificateRequest. 

Corrected Text
--
unsupported_extension:  Sent by endpoints receiving any handshake
  message containing an extension in a ServerHello or Certificate
  not first offered in the corresponding ClientHello or 
  CertificateRequest.

Notes
-
The definition of the unsupported_extension alert in section 6.2 contradicts 
the statements in section 4.2:

If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears, it MUST abort the handshake with an
   "illegal_parameter" alert.

While this might not be inconsistent due to the "abort the handshake with an X 
alert" specification at the beginning of section 6.2, it might lead to 
confusion. (see 
https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).

Paul Wouters(AD): Currently discussed at:

https://github.com/tlswg/tls13-spec/issues/1352
https://github.com/tlswg/tls13-spec/pull/1353

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (5874)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5874

--
Status: Held for Document Update
Type: Technical

Reported by: Mr Laurie Perrin 
Date Reported: 2019-10-12
Held by: Paul Wouters (IESG)

Section: 5.1

Original Text
-
...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

Corrected Text
--
...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes
-
In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning 
zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.

Paul Wouters(AD): Currently discussed at:

https://github.com/tlswg/tls13-spec/issues/1346
https://github.com/tlswg/tls13-spec/pull/1347

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (5717)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5717

--
Status: Held for Document Update
Type: Editorial

Reported by: Daniel Migault 
Date Reported: 2019-05-03
Held by: Paul Wouters (IESG)

Section: 2.2.

Original Text
-
 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
  Client   Server
 
   Initial Handshake:
  ClientHello
  + key_share   >
  ServerHello
  + key_share
{EncryptedExtensions}
{CertificateRequest*}
   {Certificate*}
 {CertificateVerify*}
   {Finished}
< [Application Data*]
  {Certificate*}
  {CertificateVerify*}
  {Finished}>
<  [NewSessionTicket]
  [Application Data]<--->  [Application Data]
 
 
   Subsequent Handshake:
  ClientHello
  + key_share*
  + pre_shared_key  >
  ServerHello
 + pre_shared_key
 + key_share*
{EncryptedExtensions}
   {Finished}
< [Application Data*]
  {Finished}>
  [Application Data]<--->  [Application Data]
 
   Figure 3: Message Flow for Resumption and PSK


Corrected Text
--
 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
  Client   Server
 
   Initial Handshake:
  ClientHello
  + key_share   >
  ServerHello
  + key_share
{EncryptedExtensions}
{CertificateRequest*}
   {Certificate*}
 {CertificateVerify*}
   {Finished}
< [Application Data*]
  {Certificate*}
  {CertificateVerify*}
  {Finished}>
<  [NewSessionTicket]
  [Application Data]<--->  [Application Data]
 
 
   Subsequent Handshake:
  ClientHello
  + key_share*
  + psk_key_exchange_modes
  + pre_shared_key  >

  ServerHello
 + pre_shared_key
 + key_share*
{EncryptedExtensions}
   {Finished}
< [Application Data*]
  {Finished}>
  [Application Data]<--->  [Application Data]
 
   Figure 3: Message Flow for Resumption and PSK


Notes
-
The pre_shared_key requires the pre_share_key extension.

This Issue and PR should address this erratum:
https://github.com/tlswg/tls13-spec/issues/1344
https://github.com/tlswg/tls13-spec/pull/1345


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6204)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6204

--
Status: Held for Document Update
Type: Editorial

Reported by: Chris Wood 
Date Reported: 2020-06-03
Held by: Paul Wouters (IESG)

Section: E.1

Original Text
-
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either the client or the server unless negotiated by some 
extension.

Corrected Text
--
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either client or the server. Future specifications MAY 
provide an extension to permit this. 

Notes
-
The existing text can be misread as permitting this combination upon 
negotiation of the "post_handshake_auth" extension, which would be incorrect. 
[1] describes an attack that can occur based on this misinterpretation. The 
proposed text aims to make clear that a *new* extension is required for this 
combination. 

Paul Wouters(AD): See 
https://mailarchive.ietf.org/arch/msg/tls/uDjERicvcTimiecyhiSrYA0H1Sc/
[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6139)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6139

--
Status: Verified
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Verified by: Paul Wouters (IESG)

Section: 4.4.2.2.

Original Text
-
As servers MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable.

Corrected Text
--
As servers MAY require the presence of the "server_name" extension, client
SHOULD send this extension.

Notes
-
Since it is unclear when it is applicable for a server to send the extension, 
dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.

Paul Wouters(AD): Resolved with alternative Corrected Text:

As servers MAY require the presence of the "server_name" extension, clients 
SHOULD send this extension when the server is identified by name.


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (7250)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7250

--
Status: Verified
Type: Technical

Reported by: Alan DeKok 
Date Reported: 2022-11-14
Verified by: Paul Wouters (IESG)

Section: 4.6.1

Original Text
-
   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).

Corrected Text
--
(to add)

  Where the client does not support session tickets, this extension MUST be 
ignored.

Notes
-
I've seen a TLS implementation which doesn't implement session tickets.  That's 
fine, but the implementation doesn't *ignore* session tickets it receives.  
Instead, it treats reception of the ticket as un recoverable error, and drops 
the TLS connection.

It's also worth adding a note to section 4.2 at the bottom of page 38.  To note 
that in general, f an extension isn't supported AND doesn't materially affect 
the TLS exchange, THEN it should be ignored.

i.e. there's nothing in the spec which mentions Postel's law "be conservative 
in what you send, be liberal in what you accept".  So implementors reading this 
document are free to do all kinds of odd things.

In addition, the text in Section 4.2 at the bottom of page 38 says:

"
  Designers
  and implementors should be aware of the fact that until the
  handshake has been authenticated, active attackers can modify
  messages and insert, remove, or replace extensions.
"

The implicit conclusion here is that an implementation receiving extensions 
must sanity check them.  e.g. an attacker adding an undefined / unknown 
extension should not cause the entire session to be torn down.

Paul Wouters(AD): Resolved but with the Corrected Text:

The client MAY use this PSK for future handshakes by including the ticket value 
in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Clients 
which receive a NewSessionTicket message but do not support resumption MUST 
silently ignore this message.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (7303)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7303

--
Status: Verified
Type: Technical

Reported by: Eric Lawrence 
Date Reported: 2023-01-12
Verified by: Paul Wouters (IESG)

Section: 6.1

Original Text
-
This alert notifies the recipient that the sender will not send any more 
messages on this connection. 

Corrected Text
--
This alert notifies the recipient that the sender will not send any more 
messages on this connection. close_notify alerts should be sent with a severity 
level of WARNING.

Notes
-
Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but 
this text got lost somewhere along the way. 
https://github.com/pion/dtls/issues/195

OpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL 
have encountered compatibility problems with clients which treat FATAL alerts 
differently than WARNING alerts: e.g. 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record=chromium%2Fchromium%2Fsrc

Paul Wouters(AD): Resolved but with the following Corrected Text:

close_notify:  This alert notifies the recipient that the sender will not send 
any more messages on this connection.  Any data received after a closure alert 
has been received MUST be ignored. This alert MUST be sent with 
AlertLevel=warning.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6123)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6123

--
Status: Verified
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Verified by: Paul Wouters (IESG)

Section: 2

Original Text
-
The handshake protocol allows peers to negotiate a protocol version, select 
cryptographic algorithms, optionally authenticate each other, and establish 
shared secret keying material.

Corrected Text
--


Notes
-
Only client authentication is optional (albeit, server authentication is 
implicit for PSK-only key exchange mode)

Paul Wouters(AD): corrected with the following text:

The handshake protocol allows peers to negotiate a protocol version, select 
cryptographic algorithms, authenticate each other (with client authentication 
being optional), and establish shared secret keying material.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (5483)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5483

--
Status: Verified
Type: Technical

Reported by: Patrick Kelsey 
Date Reported: 2018-08-28
Verified by: Paul Wouters (IESG)

Section: 4.2.8.2

Original Text
-
For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

Corrected Text
--
For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes
-
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs 
to the corresponding ECDH scalar multiplication function are the private key 
and the u-coordinate of the standard public base point, the former of which of 
course must not be transmitted and the latter of which is a known constant.

Paul Wouters (AD): Resolved but with the following Corrected Text:

For X25519 and X448, the contents of the public value is the K_A or
K_B value described in Section 6 of [RFC7748].  This is 32 bytes for
X25519 and 56 bytes for X448.

>From another perspective, including the byte string inputs in the contents of 
>the public value would contradict the resulting content sizes given at the end 
>of the cited paragraph as well as the statement in Section 7.4.2 that the 
>public key put into the KeyShareEntry is the output of ECDH scalar 
>multiplication function.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6401)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6401

--
Status: Held for Document Update
Type: Technical

Reported by: Eric Covener 
Date Reported: 2021-01-20
Held by: Paul Wouters (IESG)

Section: 4.6.2

Original Text
-
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

Corrected Text
--
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  



Notes
-
4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) 
client 
authentication when the client has sent  the "post_handshake_auth" extension. I 
think 
the language would be stronger if it were really forbidden, and openssl 
s_server permits 
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped 
as 
"handshake" is not ambiguous in 1.3 due to no renegotiation.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC5246 (6244)

[RFC Errata System]

The following errata report has been held for document update 
for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6244

--
Status: Held for Document Update
Type: Editorial

Reported by: Victor S. Osipov 
Date Reported: 2020-07-29
Held by: Paul Wouters (IESG)

Section: 6.2.3.2

Original Text
-
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.

Corrected Text
--
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_length.

Notes
-
This is an error here. The structure SecurityParameters hasn't the element 
block_size.
It has the element block_length.
See in section 6.1:
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;


Paul Wouters (AD): Note this RFC is obsoleted and all of this text already got 
removed

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Rejected] RFC5246 (6572)

[RFC Errata System]

The following errata report has been rejected for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6572

--
Status: Rejected
Type: Technical

Reported by: Johannes Görlich 
Date Reported: 2021-05-05
Rejected by: Paul Wouters (IESG)

Section: 9

Original Text
-
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

Corrected Text
--
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).

Notes
-
A must-be-implement cipher suite should not relay on a bulk encryption 
algorithm which is vulnerable to plain-text attacks or on a secure hash 
algorithm which has been proven to be insecure.
 --VERIFIER NOTES-- 
errata is not the right process for a change such as proposed.
See also: https://mailarchive.ietf.org/arch/msg/tls/2mKIkvRoQNMEMkT04JAqBifEJSo/

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Rejected] RFC7301 (5176)

[RFC Errata System]

The following errata report has been rejected for RFC7301,
"Transport Layer Security (TLS) Application-Layer Protocol Negotiation 
Extension".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5176

--
Status: Rejected
Type: Technical

Reported by: Ilya Grigorik 
Date Reported: 2017-11-02
Rejected by: Paul Wouters (IESG)

Section: 6

Original Text
-
IANA Considerations

Corrected Text
--
+Protocol:  HTTP/1.0
+Protocol:  HTTP/0.9

Notes
-
RFC does not register ALPN identifiers for http/0.9 or http/1.0.
 --VERIFIER NOTES-- 
Errata is not the method for modifying requests to IANA 

See also: https://mailarchive.ietf.org/arch/msg/tls/j_A2WszoHniWzD609Cal5lFslxw/

--
RFC7301 (draft-ietf-tls-applayerprotoneg-05)
--
Title   : Transport Layer Security (TLS) Application-Layer Protocol 
Negotiation Extension
Publication Date: July 2014
Author(s)   : S. Friedl, A. Popov, A. Langley, E. Stephan
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC7919 (7579)

[RFC Errata System]

The following errata report has been verified 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

--
Status: Verified
Type: Technical

Reported by: Tim Geiser 
Date Reported: 2023-07-31
Verified by: Paul Wouters (IESG)

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

--
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
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6141)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6141

--
Status: Verified
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Verified by: Paul Wouters (IESG)

Section: 4.4.3

Original Text
-
   -  The context string

Corrected Text
--
   -  The context string (defined below)

Notes
-


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6122)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6122

--
Status: Verified
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Verified by: Paul Wouters (IESG)

Section: 1.2

Original Text
-
The key derivation functions have been redesigned.

Corrected Text
--
The key derivation function has been redesigned.

Notes
-


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6146)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6146

--
Status: Verified
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Verified by: Paul Wouters (IESG)

Section: 4.2.10.

Original Text
-
The TLS version number

Corrected Text
--
The selected TLS version number

Notes
-


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (6142)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6142

--
Status: Verified
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Verified by: Paul Wouters (IESG)

Section: 4.6.1.

Original Text
-
Clients MUST NOT cache tickets for longer than 7 days

Corrected Text
--
Clients MUST NOT use tickets for longer than 7 days

Notes
-
"MUST NOT cache" is surely overly zealous and may unnecessarily result in 
non-compliant implementations

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8446 (5868)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5868

--
Status: Verified
Type: Technical

Reported by: Hubert Kario 
Date Reported: 2019-10-02
Verified by: Paul Wouters (IESG)

Section: 4.2.3

Original Text
-
   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
  [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
  and FIPS 186-4 [DSS], and the corresponding hash algorithm as
  defined in [SHS].  The signature is represented as a DER-encoded
  [X690] ECDSA-Sig-Value structure.

Corrected Text
--
   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
  [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
  and FIPS 186-4 [DSS], and the corresponding hash algorithm as
  defined in [SHS].  The signature is represented as a DER-encoded
  [X690] ECDSA-Sig-Value structure as defined in [RFC4492].

Notes
-
There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting 
definitions in authoritative standards. TLS always used the following (see 
RFC4492):

   ECDSA-Sig-Value ::= SEQUENCE {
 r  INTEGER,
 s  INTEGER
   }

but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) 
defines it like this:

ECDSA-Sig-Value ::= SEQUENCE {
 r INTEGER,
 s INTEGER,
 a INTEGER OPTIONAL,
 y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}

I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, 
but the former is not an existing reference, so we would need to update section 
12 also.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6138)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6138

--
Status: Held for Document Update
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-28
Held by: Paul Wouters (IESG)

Section: 4.2.10

Original Text
-
   For externally  
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the
   connection which established the PSK.  

   ...

   For externally established 
   PSKs, the associated values are those provisioned along with the key.
   For PSKs established via a NewSessionTicket message, the associated  
   values are those negotiated in the connection during which the ticket
   was established. 

Corrected Text
--
   For externally  
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the
   connection which established the PSK.  

Notes
-
Drop largely verbatim duplicated text

Paul Wouters (AD):  This got incorporated into the bis document, but not 
exactly as suggested.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6135)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6135

--
Status: Held for Document Update
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-28
Held by: Paul Wouters (IESG)

Section: Global

Original Text
-
list, series, set, and vector are seemingly used as synonyms. 

Corrected Text
--
Using list, series, set, xor vector would help at least one reader. 


Notes
-
Additionally, consistent usage is desirable, e.g., page 31 uses "A list of 
extensions" whereas "A set of 
extensions" is used on page 60. Elsewhere inconsistently usage causes 
confusion, e.g., 
Page 48:

   client_shares:  A list of offered KeyShareEntry values in descending
  order of client preference.

   This vector MAY be empty if the client is requesting a

(Replace "vector" with "list", or vice versa.)

Paul Wouters (AD):  This got incorporated into the bis document, but not 
exactly as suggested.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6128)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6128

--
Status: Held for Document Update
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Held by: Paul Wouters (IESG)

Section: GLOBAL

Original Text
-
terminate and abort are used interchangeable, but this isn't explained until 
after such use.

In Section 6.2, we have: In the rest of this specification, when the phrases 
"terminate the connection" and "abort the handshake" are used without a 
specific alert it means that the implementation SHOULD send the alert indicated 
by the
descriptions below.  

Corrected Text
--
Perhaps explain terminology earlier. At the very least, in Section 6.2, open 
the above sentence with "Throughout this specification"



Notes
-
 This got incorporated into the bis document, but not exactly as suggested.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC8446 (6125)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6125

--
Status: Held for Document Update
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Held by: Paul Wouters (IESG)

Section: GLOBAL

Original Text
-
PSKs are referred to as out-of-band and external

Corrected Text
--
Referring to PSKs as either out-of-band xor external would help at least one 
reader

Notes
-
 This got incorporated into the bis document, but not exactly as suggested.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC6176 (5536)

[RFC Errata System]

The following errata report has been verified for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5536

--
Status: Verified
Type: Technical

Reported by: Eugene Adell 
Date Reported: 2018-10-19
Verified by: Paul Wouters (IESG)

Section: 1

Original Text
-
   RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned
   implementers that the "ability to send version 2.0 CLIENT-HELLO
   messages will be phased out with all due haste".  This document
   accomplishes this by updating the backward compatibility sections
   found in TLS [TLS1.0][TLS1.1][TLS1.2].

Corrected Text
--
   RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246
   [TLS1.2] explicitly warned implementers that the "ability to send
   version 2.0 CLIENT-HELLO messages will be phased out with all due
   haste". This document accomplishes this by updating the backward
   compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2].

Notes
-
The warning on the version 2.0 Client Hello is as old as the first TLS version 
(RFC 2246 Appendix E). That's what the authors meant and wanted to highlight by 
listing two of the three RFCs containing this warning. This is confirmed by 
their last sentence. It looks like a small mistake without concrete effects, I 
push this errata considering "IESG Processing of RFC Errata for the IETF Stream 
rule 6"

--
RFC6176 (draft-ietf-tls-ssl2-must-not-04)
--
Title   : Prohibiting Secure Sockets Layer (SSL) Version 2.0
Publication Date: March 2011
Author(s)   : S. Turner, T. Polk
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Rejected] RFC5246 (5036)

[RFC Errata System]

The following errata report has been rejected for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5036

--
Status: Rejected
Type: Technical

Reported by: Stefan Goeman 
Date Reported: 2017-06-09
Rejected by: Paul Wouters (IESG)

Section: 7.4.1.2

Original Text
-
The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a "Session 
ID Length" field, either with value 0 or value 32

Corrected Text
--
In the ClientHello structure and ServerHello structure, include 
a 1 byte "Session ID Length" field.

Notes
-
The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a 
"Session ID Length" field, either with value 0 or value 32.
 --VERIFIER NOTES-- 
This erratum is incorrect.

Here is the definition of SessionID:
  opaque SessionID<0..32>;

The angle brackets mean that it is variable length and the 0..32 means that 
there is
a one-byte length field.

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC7905 (5251)

[RFC Errata System]

The following errata report has been held for document update 
for RFC7905, "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security 
(TLS)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5251

--
Status: Held for Document Update
Type: Technical

Reported by: Xavier Bonnetain 
Date Reported: 2018-02-01
Held by: Paul Wouters (IESG)

Section: 4. Security

Original Text
-
   Poly1305 is designed to ensure that forged messages are rejected with
   a probability of 1-(n/2^107), where n is the maximum length of the
   input to Poly1305.  In the case of (D)TLS, this means a maximum
   forgery probability of about 1 in 2^93.

Corrected Text
--
   Poly1305 is designed to ensure that forged messages are rejected with
   a probability of 1-(n/2^106), where n is the maximum length of the
   input to Poly1305.  In the case of (D)TLS, this means a maximum
   forgery probability of about 1 in 2^92.

Notes
-
The security claimed on poly1305 is slightly beyond what was proven by the 
designer (see https://cr.yp.to/mac/poly1305-20050329.pdf), and the trivial 
forgery attempt with a message of length 1 succeeds with probability 2^{-106}.

Paul Wouters(AD): See 
https://mailarchive.ietf.org/arch/msg/tls/dBMIsLsaA7XevXpd9hzJ6skMqE4/

--
RFC7905 (draft-ietf-tls-chacha20-poly1305-04)
--
Title   : ChaCha20-Poly1305 Cipher Suites for Transport Layer 
Security (TLS)
Publication Date: June 2016
Author(s)   : A. Langley, W. Chang, N. Mavrogiannopoulos, J. 
Strombergson, S. Josefsson
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Verified] RFC8996 (7796)

[RFC Errata System]

The following errata report has been verified for RFC8996,
"Deprecating TLS 1.0 and TLS 1.1". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7796

--
Status: Verified
Type: Editorial

Reported by: Gaëtan Leurent 
Date Reported: 2024-02-03
Verified by: RFC Editor  

Section: 10.2

Original Text
-
[Bhargavan2016] Bhargavan, K. and G. Leuren,

Corrected Text
--
[Bhargavan2016] Bhargavan, K. and G. Leurent,

Notes
-
The last name "Leurent" is misspelt is the references.

--
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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Editorial Errata Reported] RFC8996 (7796)

[RFC Errata System]

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/eid7796

--
Type: Editorial
Reported by: Gaëtan Leurent 

Section: 10.2

Original Text
-
[Bhargavan2016] Bhargavan, K. and G. Leuren,

Corrected Text
--
[Bhargavan2016] Bhargavan, K. and G. Leurent,

Notes
-
The last name "Leurent" is misspelt is the references.

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] [Errata Verified] RFC8446 (7774)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7774

--
Status: Verified
Type: Editorial

Reported by: Rebecca VanRheenen 
Date Reported: 2024-01-22
Verified by: RFC Editor  

Section: 4.1.3

Original Text
-
ServerHello.Random

Corrected Text
--
ServerHello.random

Notes
-
Lowercase "random".

This report was created/verified per Paul Wouter's note at 
https://www.rfc-editor.org/errata/eid7769.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Editorial Errata Reported] RFC8446 (7774)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7774

--
Type: Editorial
Reported by: Rebecca VanRheenen 

Section: 4.1.3

Original Text
-
ServerHello.Random

Corrected Text
--
ServerHello.random

Notes
-
Lowercase "random".

This report was created per https://www.rfc-editor.org/errata/eid7769.

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.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Errata Held for Document Update] RFC7919 (4908)

[RFC Errata System]

The following errata report has been held for document update 
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/eid4908

--
Status: Held for Document Update
Type: Technical

Reported by: Martin Thomson 
Date Reported: 2017-01-16
Held by: Paul Wouters (IESG)

Section: 4

Original Text
-
   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.  If the extension is present
   with FFDHE groups, none of the client's offered groups are acceptable
   by the server, and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server, the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71).

Corrected Text
--
   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.

Notes
-
The text is overly prescriptive about the alert code that needs to used if 
there are no acceptable cipher suites available.  If the server is unable to 
pick a cipher suite, it can send a handshake_failure(40) alert, which this text 
would prohibit.  handshake_failure is at least equally valid in practice.

This eliminates the prescriptive text about the alert type.

Servers eliminate cipher suites from considerations in numerous ways.  Being 
able to definitively identify the reason as a (perceived) shortcoming in the 
strength of the offered security is actually quite challenging in practice.

It's true that insufficient_security is perhaps a more desirable code to use in 
this case, but it's not generically possible to determine that the server 
configuration is "more secure" than the combinations on offer by the client.  
Consider also the possibility that it's the server that is insecure because it 
doesn't some of the options offered by the client.  That's a general criticism 
of the value of insufficient_security, but it should at least motivate why 
insufficient_security should never be mandated in this way.

Paul Wouters(AD): After discussion with Martin, we propose that the correction 
required is only the removal of "of type insufficient_security(71).".

As Martin explains: 

Having a MUST on this is not appropriate in that sense.  What would be 
acceptable is:

   [...] the server terminates the connection according to Section 4.1.1 of 
[RFC8446].

Of course, that would depend on time travel in the sense that RFC 7919 
pre-dates TLS 1.3 by a fair bit and so it can't really refer to it like that.


--
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

[TLS] [Errata Held for Document Update] RFC8446 (5682)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5682

--
Status: Held for Document Update
Type: Technical

Reported by: Richard Barnes 
Date Reported: 2019-04-01
Held by: Paul Wouters (IESG)

Section: 4.3.2, B.3.2

Original Text
-
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
 
   struct {
   opaque certificate_request_context<0..2^8-1>;
-  Extension extensions<2..2^16-1>;
+  Extension extensions<0..2^16-1>;
   } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
   struct {
   opaque certificate_request_context<0..2^8-1>;
-  Extension extensions<2..2^16-1>;
+  Extension extensions<0..2^16-1>;
   } CertificateRequest;
 
 


Corrected Text
--
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
 
   struct {
   opaque certificate_request_context<0..2^8-1>;
-  Extension extensions<2..2^16-1>;
+  Extension extensions<0..2^16-1>;
   } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
   struct {
   opaque certificate_request_context<0..2^8-1>;
-  Extension extensions<2..2^16-1>;
+  Extension extensions<0..2^16-1>;
   } CertificateRequest;
 
 


Notes
-
The length of this vector can never 2.  It is either 0, if the vector is empty, 
or >=4, if the vector has at least one extension.  Nothing elsewhere in the 
spec requires a non-zero number of extensions here, so this syntax should allow 
a zero-length vector.

Paul Wouters (AD): Richard meant the diff to be the fix, not the 
original/corrected text. The diff is not in the RFC itself. There are two 
places in the mentioned sections that need this one liner fix.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Errata Held for Document Update] RFC8422 (5468)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport 
Layer Security (TLS) Versions 1.2 and Earlier". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5468

--
Status: Held for Document Update
Type: Editorial

Reported by: Masato Gosui 
Date Reported: 2018-08-17
Held by: Paul Wouters (IESG)

Section: 5.4

Original Text
-
   namedCurve: Specifies a recommended set of elliptic curve domain

Corrected Text
--
   namedcurve: Specifies a recommended set of elliptic curve domain

Notes
-
This fixes mismatched names of the variable "namedcurve" in the "Structure of 
this message" paragraph.

--
RFC8422 (draft-ietf-tls-rfc4492bis-17)
--
Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Publication Date: August 2018
Author(s)   : Y. Nir, S. Josefsson, M. Pegourie-Gonnard
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

[TLS] [Errata Verified] RFC8996 (7103)

[RFC Errata System]

The following errata report has been verified for RFC8996,
"Deprecating TLS 1.0 and TLS 1.1". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7103

--
Status: Verified
Type: Editorial

Reported by: Martin Thomson 
Date Reported: 2022-08-24
Verified by: Paul Wouters (IESG)

Section: GLOBAL

Original Text
-
https://www.rfc-editor.org/rfc/rfc%E2%80%8B%204162;
class="eref">​ 4162

Corrected Text
--
https://www.rfc-editor.org/rfc/rfc4162;
class="eref">​4162

Notes
-
(Note: the line wrapping here is mine; the errata tool assumes that this is 
text, so it won't accept long lines.)

The text for this specification is OK, but the HTML rendering has some 
hard-to-notice errors in the "Updates" field in the metadata block that is 
being caused by errors in the XML source.

The XML source includes a number of Unicode zero width space characters 
(U+200B) after commas in the rfc@updates attribute.  xml2rfc is unable to 
handle these characters correctly, treating them - and the space that follows - 
as part of the RFC number.  It generates the bad link as you see above.

This can be addressed in xml2rfc, maybe, but this is probably not XML we want 
to permit.

Paul Wouters (AD): Verified, as this RFC won't get any updates.

--
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] [Errata Held for Document Update] RFC8996 (7769)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8996, "Deprecating TLS 1.0 and TLS 1.1". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7769

--
Status: Held for Document Update
Type: Editorial

Reported by: Martin Thomson 
Date Reported: 2021-03-23
Held by: Paul Wouters (IESG)

Section: 1.1

Original Text
-
ServerHello.Random

Corrected Text
--
ServerHello.random 

Notes
-
Very pedantic, but RFC 8446 uses all lowercase for "random" to match the 
grammar.

Paul Wouters (AD): RFC 8446 itself actually also has this problem once in 
Section 4.1.3

--
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] [Errata Held for Document Update] RFC8446 (6205)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6205

--
Status: Held for Document Update
Type: Editorial

Reported by: Martin Thomson 
Date Reported: 2020-06-04
Held by: Paul Wouters (IESG)

Section: 4.3.2

Original Text
-
   Servers which are authenticating with a PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).

Corrected Text
--
   Servers which are authenticating with a resumption PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).  Servers which are authenticating with an external PSK
   MUST NOT send the CertificateRequest message either in the main handshake
   or request post-handshake authentication. Future specifications MAY
   provide an extension to permit this. 

Notes
-
The lack of qualification on "authenticating with a PSK" implies that the 
statement applies equally to both external and resumption PSKs.  However, there 
are two conditions being governed: whether a certificate can be requested 
during the handshake, and whether a certificate can be requested 
post-handshake.  The latter of these requires different rules depending on the 
type of PSK.

We know from the analysis of resumption (see 
https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that 
combining a PSK handshake of either type with a client certificate is not safe. 
 Thus, the prohibition on CertificateRequest during the handshake applies 
equally to both resumption and external PSKs.

For post-handshake, Appendix E.1 already discusses the risks of combining PSKs 
with certificates, citing the same analysis as above.

   [...]  It is unsafe to use certificate-based client
   authentication when the client might potentially share the same
   PSK/key-id pair with two different endpoints.

For this reason an external PSK is not safe to use with post-handshake 
authentication.  A resumption PSK does not have this property, so the same 
prohibition doesn't apply.

Splitting the requirements as proposed makes this split clearer.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Errata Verified] RFC5246 (4912)

[RFC Errata System]

The following errata report has been verified for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4912

--
Status: Verified
Type: Technical

Reported by: Nikolai Malykh 
Date Reported: 2017-01-18
Verified by: Paul Wouters (IESG)

Section: A.4.1

Original Text
-
   SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>;


Corrected Text
--
   SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;


Notes
-
Error in last sentence. See errata ID 2865.

Paul Wouters (AD): From errata ID 2865: The supported_signature_algorithms 
field is a variable length array. As such ceiling and floor should be 
specified, and they should be multiple of the base type (which is two bytes 
long in this case). See section 7.4.1.4.1 for a valid definition of this field.
This is already fixed in TLS 1.3 RFC8446

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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

[TLS] [Errata Verified] RFC5246 (4750)

[RFC Errata System]

The following errata report has been verified for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4750

--
Status: Verified
Type: Technical

Reported by: Adrien de Croy 
Date Reported: 2016-07-27
Verified by: Paul Wouters (IESG)

Section: 4.3 Vectors

Original Text
-
The length of
   an encoded vector must be an even multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Corrected Text
--
The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes
-
Original text implies vectors can only contain even (0,2,4,6,8...) numbers of 
elements.  The example does not resolve this but indicates the intent is that 
parts of elements are not allowed. It is clear from other examples that odd 
numbers of elements are permitted.

Paul Wouters (AD): As TLS 1.2 is obsoleted by TLS 1.3, this errata is closed as 
Verified. In TLS 1.3 in RFC 8447 the text states more clearly:  Here, T' 
occupies n bytes in the data stream, where n is a multiple of the size of T. 



--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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

[TLS] [Errata Verified] RFC5246 (4507)

[RFC Errata System]

The following errata report has been verified for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4507

--
Status: Verified
Type: Technical

Reported by: Benjamin Kaduk 
Date Reported: 2015-10-19
Verified by: Paul Wouters (IESG)

Section: 7.4.1.2

Original Text
-
After sending the ClientHello message, the client waits for a
ServerHello message.  Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error.


Corrected Text
--
After sending the ClientHello message, the client waits for a
ServerHello message.  Any other handshake message returned by the
server, except for a HelloRequest, is treated as a fatal error.

Notes
-
A ServerHello received after a ClientHello should not be treated as a fatal 
error.

Paul Wouters (AD): TLS 1.2 has been obsoleted by TLS 1.3 RFC8446. The language 
in that RFC does not contain the same issue (see 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2). As such, this is 
marked as Verified.

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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

[TLS] [Errata Verified] RFC5054 (4546)

[RFC Errata System]

The following errata report has been verified for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4546

--
Status: Verified
Type: Technical

Reported by: Rick van Rein 
Date Reported: 2015-11-30
Verified by: Paul Wouters (IESG)

Section: 2.6

Original Text
-
B = k*v + g^b % N

Corrected Text
--
B = ( k*v + g^b ) % N

Notes
-
The customary binding is that + has lower priority than % and so the default 
reading of the expression would be 
B = k*v + ( g^b % N )
That is inconsistent with the existence of PAD(B) and the size of B in the test 
vectors, so the context hints at proper brackets, but this may still lead to 
implementation errors (of which I actually ran into an example).

Paul Wouters (AD): This errata is correct, but note that this RFC is applicable 
only for TLS < 1.3. For TLS 1.3, one needs to use a PAKE as replacement, such 
as those defined in RFC8492. As such, this errata is left as Verified as there 
won't be a document update for this document.

--
RFC5054 (draft-ietf-tls-srp-14)
--
Title   : Using the Secure Remote Password (SRP) Protocol for TLS 
Authentication
Publication Date: November 2007
Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
Category: INFORMATIONAL
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] [Errata Held for Document Update] RFC2712 (5432)

[RFC Errata System]

The following errata report has been held for document update 
for RFC2712, "Addition of Kerberos Cipher Suites to Transport Layer Security 
(TLS)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5432

--
Status: Held for Document Update
Type: Technical

Reported by: Eugene Adell 
Date Reported: 2018-07-20
Held by: Paul Wouters (IESG)

Section: Appendix

Original Text
-


Corrected Text
--
Appendix

   RFC 2712 introduces new cipher suites values, starting with the
   cipher value { 0x00, 0x1E }.
   This cipher value was earlier known as a Fortezza cipher suite,
   and this could lead to a conflict.

Notes
-
Errata 5409 was rejected and I was suggested to post another one at this place.

RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in 
its Draft 01 version introduces new cipher suites values, among them three are 
colliding with the Fortezza cipher suites. The Draft 02 version partially 
corrects that, by shifting all of the Kerberos cipher suites values by two.
This omission of the third Fortezza cipher suite has never been corrected, and 
this remains in the same state in the final RFC 2712. As a result, the cipher 
suite value { 0x00, 0x1E } is now officially known as a Kerberos one.

Although not documented themselves by any RFC, the two non conflicting Fortezza 
cipher suites are mentioned in the same note in the TLS protocol RFC (2246, 
4346, 5246). This gives an explanation on how the Kerberos cipher suite values 
were chosen.

--
RFC2712 (draft-ietf-tls-kerb-cipher-suites-04)
--
Title   : Addition of Kerberos Cipher Suites to Transport Layer 
Security (TLS)
Publication Date: October 1999
Author(s)   : A. Medvinsky, M. Hur
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

[TLS] [Editorial Errata Reported] RFC8996 (7739)

[RFC Errata System]

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] [Errata Verified] RFC5054 (7538)

[RFC Errata System]

The following errata report has been verified for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7538

--
Status: Verified
Type: Technical

Reported by: Mingye Wang 
Date Reported: 2023-06-07
Verified by: Paul Wouters (IESG)

Section: 2.1

Original Text
-
 The version of SRP used here is sometimes referred to as "SRP-6"
   [SRP-6].

Corrected Text
--
 The version of SRP used here is sometimes referred to as "SRP-6a"
   [SRP-6a].


 [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, 
http://srp.stanford.edu/design.html

Notes
-
The protocol described uses a non-constant k, which is an innovation of SRP-6a 
-- never published formally in a technical report (until this RFC) and dating 
to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a 
constant k = 3.

Reference to the [SRP-6] text is still valuable for rationale, but is not 
accurate. Confusion between these two versions is harmful and may impeded 
interoperability.

--
RFC5054 (draft-ietf-tls-srp-14)
--
Title   : Using the Secure Remote Password (SRP) Protocol for TLS 
Authentication
Publication Date: November 2007
Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
Category: INFORMATIONAL
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] [Editorial Errata Reported] RFC9257 (7643)

[RFC Errata System]

The following errata report has been submitted for RFC9257,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7643

--
Type: Editorial
Reported by: Heikki Vatiainen 

Section: 6.1. Stack Interface

Original Text
-
   *  OpenSSL and BoringSSL: Applications can specify support for
  external PSKs via distinct ciphersuites in TLS 1.2 and below.
  Also, they can then configure callbacks that are invoked for PSK
  selection during the handshake.  These callbacks must provide a
  PSK identity and key.  The exact format of the callback depends on
  the negotiated TLS protocol version, with new callback functions
  added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
  The PSK length is validated to be between 1-256 bytes (inclusive).
  The PSK identity may be up to 128 bytes long.

Corrected Text
--
   *  OpenSSL and BoringSSL: Applications can specify support for
  external PSKs via distinct ciphersuites in TLS 1.2 and below.
  Also, they can then configure callbacks that are invoked for PSK
  selection during the handshake.  These callbacks must provide a
  PSK identity and key.  The exact format of the callback depends on
  the negotiated TLS protocol version, with new callback functions
  added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
  The PSK length is validated to be between 1-256 bytes (inclusive).
  The PSK identity may be up to 128 bytes long. OpenSSL 3.0
  increased PSK maximum length to 512 bytes and PSK identity maximum
  length to 256 bytes to match existing implementations and
  specifications.

Notes
-
OpenSSL PSK length and PSK identity length were increased to 256 and 512 
octets, respectively, for OpenSSL 3.0. There appear to be implementations and 
specifications that require these longer lengths. See here for more information:
https://github.com/openssl/openssl/pull/12777
https://github.com/openssl/openssl/pull/12771

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. 

--
RFC9257 (draft-ietf-tls-external-psk-guidance-06)
--
Title   : Guidance for External Pre-Shared Key (PSK) Usage in TLS
Publication Date: July 2022
Author(s)   : R. Housley, J. Hoyland, M. Sethi, C. A. Wood
Category: INFORMATIONAL
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] [Technical Errata Reported] RFC8446 (7620)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7620

--
Type: Technical
Reported by: Ben Smyth 

Section: 6.1

Original Text
-
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This does not have any effect on its read side of the connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

Corrected Text
--
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This SHOULD NOT have any effect on the read side of the sender's connection;
parties SHOULD receive a "close_notify" alert before closing the read side of 
their connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which receivers were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

Notes
-
As-is there's a specification-level vulnerability: Specification-compliant 
implementations may be vulnerable to truncation attacks.

I suggest using SHOULD NOT & SHOULD for better signposting and to avoid 
specification-level vulnerability.

I also suggest minor tweaks for readability.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8773 (7598)

[RFC Errata System]

The following errata report has been submitted for RFC8773,
"TLS 1.3 Extension for Certificate-Based Authentication with an External 
Pre-Shared Key".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7598

--
Type: Editorial
Reported by: Russ Housley 

Section: 5.1

Original Text
-
When the "psk_key_exchange_modes" extension is included in the
ServerHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

Corrected Text
--
When the "psk_key_exchange_modes" extension is included in the
ClientHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

Notes
-
According to RFC 8446, the "psk_key_exchange_modes" extension only appears in 
the ClientHello message. Further, the slides presented on this topic at IETF 
101show the "psk_key_exchange_modes" extension in the ClientHello message and 
no other place.  It is pretty clear that this is an editorial error.

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. 

--
RFC8773 (draft-ietf-tls-tls13-cert-with-extern-psk-07)
--
Title   : TLS 1.3 Extension for Certificate-Based Authentication 
with an External Pre-Shared Key
Publication Date: March 2020
Author(s)   : R. Housley
Category: EXPERIMENTAL
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] [Editorial Errata Reported] RFC7919 (7579)

[RFC Errata System]

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

[TLS] [Editorial Errata Reported] RFC5054 (7538)

[RFC Errata System]

The following errata report has been submitted for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7538

--
Type: Editorial
Reported by: Mingye Wang 

Section: 2.1

Original Text
-
 The version of SRP used here is sometimes referred to as "SRP-6"
   [SRP-6].

Corrected Text
--
 The version of SRP used here is sometimes referred to as "SRP-6a"
   [SRP-6a].


 [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, 
http://srp.stanford.edu/design.html

Notes
-
The protocol described uses a non-constant k, which is an innovation of SRP-6a 
-- never published formally in a technical report (until this RFC) and dating 
to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a 
constant k = 3.

Reference to the [SRP-6] text is still valuable for rationale, but is not 
accurate. Confusion between these two versions is harmful and may impeded 
interoperability.

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. 

--
RFC5054 (draft-ietf-tls-srp-14)
--
Title   : Using the Secure Remote Password (SRP) Protocol for TLS 
Authentication
Publication Date: November 2007
Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
Category: INFORMATIONAL
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] [Technical Errata Reported] RFC7465 (7476)

[RFC Errata System]

The following errata report has been submitted for RFC7465,
"Prohibiting RC4 Cipher Suites".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7476

--
Type: Technical
Reported by: Rajeev Kumar Surroach 

Section: 7465

Original Text
-
7465

Corrected Text
--
7465

Notes
-
Solve the issue

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. 

--
RFC7465 (draft-ietf-tls-prohibiting-rc4-01)
--
Title   : Prohibiting RC4 Cipher Suites
Publication Date: February 2015
Author(s)   : A. Popov
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

[TLS] [Technical Errata Reported] RFC8446 (7303)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7303

--
Type: Technical
Reported by: Eric Lawrence 

Section: 6.1

Original Text
-
This alert notifies the recipient that the sender will not send any more 
messages on this connection. 

Corrected Text
--
This alert notifies the recipient that the sender will not send any more 
messages on this connection. close_notify alerts should be sent with a severity 
level of WARNING.

Notes
-
Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but 
this text got lost somewhere along the way. 
https://github.com/pion/dtls/issues/195

OpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL 
have encountered compatibility problems with clients which treat FATAL alerts 
differently than WARNING alerts: e.g. 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record=chromium%2Fchromium%2Fsrc

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (7250)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7250

--
Type: Technical
Reported by: Alan DeKok 

Section: 4.6.1

Original Text
-
   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).

Corrected Text
--
(to add)

  Where the client does not support session tickets, this extension MUST be 
ignored.

Notes
-
I've seen a TLS implementation which doesn't implement session tickets.  That's 
fine, but the implementation doesn't *ignore* session tickets it receives.  
Instead, it treats reception of the ticket as un recoverable error, and drops 
the TLS connection.

It's also worth adding a note to section 4.2 at the bottom of page 38.  To note 
that in general, f an extension isn't supported AND doesn't materially affect 
the TLS exchange, THEN it should be ignored.

i.e. there's nothing in the spec which mentions Postel's law "be conservative 
in what you send, be liberal in what you accept".  So implementors reading this 
document are free to do all kinds of odd things.

In addition, the text in Section 4.2 at the bottom of page 38 says:

"
  Designers
  and implementors should be aware of the fact that until the
  handshake has been authenticated, active attackers can modify
  messages and insert, remove, or replace extensions.
"

The implicit conclusion here is that an implementation receiving extensions 
must sanity check them.  e.g. an attacker adding an undefined / unknown 
extension should not cause the entire session to be torn down.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8996 (7103)

[RFC Errata System]

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/eid7103

--
Type: Editorial
Reported by: Martin Thomson 

Section: GLOBAL

Original Text
-
https://www.rfc-editor.org/rfc/rfc%E2%80%8B%204162;
class="eref">​ 4162

Corrected Text
--
https://www.rfc-editor.org/rfc/rfc4162;
class="eref">​4162

Notes
-
(Note: the line wrapping here is mine; the errata tool assumes that this is 
text, so it won't accept long lines.)

The text for this specification is OK, but the HTML rendering has some 
hard-to-notice errors in the "Updates" field in the metadata block that is 
being caused by errors in the XML source.

The XML source includes a number of Unicode zero width space characters 
(U+200B) after commas in the rfc@updates attribute.  xml2rfc is unable to 
handle these characters correctly, treating them - and the space that follows - 
as part of the RFC number.  It generates the bad link as you see above.

This can be addressed in xml2rfc, maybe, but this is probably not XML we want 
to permit.

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. 

--
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] [Technical Errata Reported] RFC8446 (7073)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7073

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.4

Original Text
-
These messages are encrypted under keys derived from the 
[sender]_handshake_traffic_secret.

Corrected Text
--
These messages are encrypted under keys derived from the 
[sender]_handshake_traffic_secret, except for post-handshake authentication

Notes
-
There's an exception

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (7003)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7003

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.6.1.

Original Text
-
At any time after the server has received the client Finished message, it MAY 
send a NewSessionTicket message.

Corrected Text
--
At any time after the server has received both a "psk_key_exchange_modes" 
extension and a Finished message, it MAY send a NewSessionTicket message.



Notes
-
Section 4.2.9. demands 

In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" 
extension.

Hence, an additional restriction is needed in Section 4.6.1.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC7507 (6912)

[RFC Errata System]

The following errata report has been submitted for RFC7507,
"TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 
Downgrade Attacks".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6912

--
Type: Technical
Reported by: Jesus Alvarado 

Section: 7507

Original Text
-
RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
   Suite Value (SCSV) for Preventing Protocol Downgrade
   Attacks", RFC 7507, April 2015.
It should say:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
   Suite Value (SCSV) for Preventing Protocol Downgrade
   Attacks", RFC 7507, April 2015,
   .


Corrected Text
--
7.2

Original Text:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
   Suite Value (SCSV) for Preventing Protocol Downgrade
   Attacks", RFC 7507, April 2015.

Corrected Text:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
   Suite Value (SCSV) for Preventing Protocol Downgrade
   Attacks", RFC 7507, April 2015,
   .

Notes:

The original text lacks the link to the RFC7507 information page.

Notes
-
On this text the person he pushed something through with 128 bit encryption for 
each federal office that I had 2 out of three approved on the senators 
transfers and everyone that put in for payment never where full approved and 
people did have to stop and come talk in person.
Jesus Alvarado 1(541)3995030

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. 

--
RFC7507 (draft-ietf-tls-downgrade-scsv-05)
--
Title   : TLS Fallback Signaling Cipher Suite Value (SCSV) for 
Preventing Protocol Downgrade Attacks
Publication Date: April 2015
Author(s)   : B. Moeller, A. Langley
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

[TLS] [Technical Errata Reported] RFC7507 (6901)

[RFC Errata System]

The following errata report has been submitted for RFC7507,
"TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 
Downgrade Attacks".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6901

--
Type: Technical
Reported by: Jesus Alvarado 

Section: 1507

Original Text
-
Strength and….. a digital number off the field.

Corrected Text
--
Hybrid portal azure hit my stuff like 2012 jul 

Notes
-
I do know the set sober and California fcc airwave was moved to almost a liner 
of gateway and someone trying to hold me on router hybrid portal or company 
portal for office admin.

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. 

--
RFC7507 (draft-ietf-tls-downgrade-scsv-05)
--
Title   : TLS Fallback Signaling Cipher Suite Value (SCSV) for 
Preventing Protocol Downgrade Attacks
Publication Date: April 2015
Author(s)   : B. Moeller, A. Langley
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

[TLS] [Errata Verified] RFC6520 (6825)

[RFC Errata System]

The following errata report has been verified for RFC6520,
"Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 
Heartbeat Extension". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6825

--
Status: Verified
Type: Editorial

Reported by: Shawna Fonua 
Date Reported: 2022-01-30
Verified by: RFC Editor  

Section: Overview

Original Text
-
HeartbeartResponse

Corrected Text
--
HeartbeatResponse

Notes
-
There is a typo of an extra 'r' in "HeartbeatReponse"

--
RFC6520 (draft-ietf-tls-dtls-heartbeat-04)
--
Title   : Transport Layer Security (TLS) and Datagram Transport 
Layer Security (DTLS) Heartbeat Extension
Publication Date: February 2012
Author(s)   : R. Seggelmann, M. Tuexen, M. Williams
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Editorial Errata Reported] RFC6520 (6825)

[RFC Errata System]

The following errata report has been submitted for RFC6520,
"Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 
Heartbeat Extension".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6825

--
Type: Editorial
Reported by: Shawna Fonua 

Section: Overview

Original Text
-
HeartbeartResponse

Corrected Text
--
HeartbeatResponse

Notes
-
There is a typo of an extra 'r' in "HeartbeatReponse"

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. 

--
RFC6520 (draft-ietf-tls-dtls-heartbeat-04)
--
Title   : Transport Layer Security (TLS) and Datagram Transport 
Layer Security (DTLS) Heartbeat Extension
Publication Date: February 2012
Author(s)   : R. Seggelmann, M. Tuexen, M. Williams
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

[TLS] [Editorial Errata Reported] RFC8446 (6820)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6820

--
Type: Editorial
Reported by: Leander Schwarz 

Section: 6.2

Original Text
-
unsupported_extension:  Sent by endpoints receiving any handshake
  message containing an extension known to be prohibited for
  inclusion in the given handshake message, or including any
  extensions in a ServerHello or Certificate not first offered in
  the corresponding ClientHello or CertificateRequest. 

Corrected Text
--
unsupported_extension:  Sent by endpoints receiving any handshake
  message containing an extension in a ServerHello or Certificate
  not first offered in the corresponding ClientHello or 
  CertificateRequest.

Notes
-
The definition of the unsupported_extension alert in section 6.2 contradicts 
the statements in section 4.2:

If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears, it MUST abort the handshake with an
   "illegal_parameter" alert.

While this might not be inconsistent due to the "abort the handshake with an X 
alert" specification at the beginning of section 6.2, it might lead to 
confusion. (see 
https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC2246 (6680)

[RFC Errata System]

The following errata report has been submitted for RFC2246,
"The TLS Protocol Version 1.0".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6680

--
Type: Editorial
Reported by: TH3D3V1L5 

Section: 2119

Original Text
-
TH3D3V1L5

Corrected Text
--
d6d6d6/md5.ul.9001.iso.rtf

Notes
-
X@-^irsa

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. 

--
RFC2246 (no draft string recorded)
--
Title   : The TLS Protocol Version 1.0
Publication Date: January 1999
Author(s)   : T. Dierks, C. Allen
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

[TLS] [Technical Errata Reported] RFC5246 (6572)

[RFC Errata System]

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6572

--
Type: Technical
Reported by: Johannes Görlich 

Section: 9

Original Text
-
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

Corrected Text
--
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).

Notes
-
A must-be-implement cipher suite should not relay on a bulk encryption 
algorithm which is vulnerable to plain-text attacks or on a secure hash 
algorithm which has been proven to be insecure.

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. 

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC2818 (6503)

[RFC Errata System]

The following errata report has been submitted for RFC2818,
"HTTP Over TLS".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6503

--
Type: Editorial
Reported by: Jennalyn bernardo 

Section: RFC 2459

Original Text
-
HTTP Over TLS

Corrected Text
--
HTTP Over TLS

Notes
-
Pls help me to remove me here I want my own privacy thank u so much

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. 

--
RFC2818 (draft-ietf-tls-https-04)
--
Title   : HTTP Over TLS
Publication Date: May 2000
Author(s)   : E. Rescorla
Category: INFORMATIONAL
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] [Editorial Errata Reported] RFC8996 (6492)

[RFC Errata System]

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/eid6492

--
Type: Editorial
Reported by: Martin Thomson 

Section: 1.1

Original Text
-
ServerHello.Random

Corrected Text
--
ServerHello.random 

Notes
-
Very pedantic, but RFC 8446 uses all lowercase for "random" to match the 
grammar.

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. 

--
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] [Technical Errata Reported] RFC8446 (6401)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6401

--
Type: Technical
Reported by: Eric Covener 

Section: 4.6.2

Original Text
-
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

Corrected Text
--
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  



Notes
-
4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) 
client 
authentication when the client has sent  the "post_handshake_auth" extension. I 
think 
the language would be stronger if it were really forbidden, and openssl 
s_server permits 
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped 
as 
"handshake" is not ambiguous in 1.3 due to no renegotiation.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC5246 (6244)

[RFC Errata System]

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6244

--
Type: Editorial
Reported by: Victor S. Osipov 

Section: 6.2.3.2

Original Text
-
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.

Corrected Text
--
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_length.

Notes
-
This is an error here. The structure SecurityParameters hasn't the element 
block_size.
It has the element block_length.
See in section 6.1:
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;

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. 

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6205)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6205

--
Type: Editorial
Reported by: Martin Thomson 

Section: 4.3.2

Original Text
-
   Servers which are authenticating with a PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).

Corrected Text
--
   Servers which are authenticating with a resumption PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).  Servers which are authenticating with an external PSK
   MUST NOT send the CertificateRequest message either in the main handshake
   or request post-handshake authentication. Future specifications MAY
   provide an extension to permit this. 

Notes
-
The lack of qualification on "authenticating with a PSK" implies that the 
statement applies equally to both external and resumption PSKs.  However, there 
are two conditions being governed: whether a certificate can be requested 
during the handshake, and whether a certificate can be requested 
post-handshake.  The latter of these requires different rules depending on the 
type of PSK.

We know from the analysis of resumption (see 
https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that 
combining a PSK handshake of either type with a client certificate is not safe. 
 Thus, the prohibition on CertificateRequest during the handshake applies 
equally to both resumption and external PSKs.

For post-handshake, Appendix E.1 already discusses the risks of combining PSKs 
with certificates, citing the same analysis as above.

   [...]  It is unsafe to use certificate-based client
   authentication when the client might potentially share the same
   PSK/key-id pair with two different endpoints.

For this reason an external PSK is not safe to use with post-handshake 
authentication.  A resumption PSK does not have this property, so the same 
prohibition doesn't apply.

Splitting the requirements as proposed makes this split clearer.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6204)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6204

--
Type: Editorial
Reported by: Chris Wood 

Section: E.1

Original Text
-
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either the client or the server unless negotiated by some 
extension.

Corrected Text
--
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either client or the server. Future specifications MAY 
provide an extension to permit this. 

Notes
-
The existing text can be misread as permitting this combination upon 
negotiation of the "post_handshake_auth" extension, which would be incorrect. 
[1] describes an attack that can occur based on this misinterpretation. The 
proposed text aims to make clear that a *new* extension is required for this 
combination. 

[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6152)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6152

--
Type: Technical
Reported by: Ben Smyth 

Section: 4

Original Text
-
Clients MUST check for ["supported_versions"] prior to
processing the rest of the ServerHello (although they will have to 
parse the ServerHello in order to read the extension). -- Section 4.2.1.

Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in Section 4.1.3 and then
process the extensions, starting with determining the version using
"supported_versions". -- Section 4.1.4

Upon receiving a message with type server_hello, implementations MUST
first examine the Random value... -- Section 4.1.3.


Corrected Text
--


Notes
-
These requirements are seemingly conflicting. I suspect checking for 
"supported_versions" must 
come first, since that may influence subsequent steps, e.g., checking 
legacy_compression_method 
and the Random value. It doesn't seem to matter whether legacy_version, 
legacy_session_id_echo, 
cipher_suite, and legacy_compression_method are checked before the Random 
value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of 
my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor 
legacy_compression_method. 
Perhaps the latter should be checked to be zero, aborting with alert 
illegal_parameter if it isn't, as per
Section 4.1.2.)

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6151)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6151

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.4

Original Text
-
   | Post- | ClientHello ... client  | client_application_traffic_ |
   | Handshake | Finished +  | secret_N|
   |   | CertificateRequest  | |

Corrected Text
--
   | Post- | ClientHello ... client  | [sender]_application_traffic|
   | Handshake | Finished +  | _secret_N   |
   |   | CertificateRequest  | |

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6150)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6150

--
Type: Editorial
Reported by: Ben Smyth 

Section: GLOBAL

Original Text
-
Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT). 

Corrected Text
--
Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT), post-handshake 
certificate-based client authentication is possible.

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6148)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6148

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.2.10

Original Text
-
The selected ALPN [RFC7301] protocol, if any

Corrected Text
--
The selected ALPN [RFC7301] protocol, if extension 
application_layer_protocol_negotiation is present

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6147)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6147

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.2.10.

Original Text
-
In order to accept early data, the server MUST have accepted a PSK
cipher suiteIn addition, it MUST verify that the
following values are the same as those associated with the
selected PSK:



-  The selected cipher suite

Corrected Text
--


Notes
-
Accepting the "PSK cipher suite" surely implies the PSK is associated with the 
cipher suite, hence, 
"The selected cipher suite" can be dropped.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6146)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6146

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.2.10.

Original Text
-
The TLS version number

Corrected Text
--
The selected TLS version number

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6145)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6145

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.2.10.

Original Text
-
When a PSK is used and early data is allowed for that PSK

Corrected Text
--


Notes
-
I couldn't find restrictions that forbid early data for a PSK. Explaining where 
such restrictions
could exist would be useful. E.g., PSKs might be associated with data that 
forbids early data.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6144)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6144

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.2.8.

Original Text
-
Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...the selected_group field does not
correspond to a group which was provided in the "key_share" extension
in the original ClientHello.

Corrected Text
--
Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...a key share was not offered (in the "key_share" 
extension in the original ClientHello) for the group in the 
selected_group field.

Notes
-
The original text requires knowledge of the "key_share" extension and is rather 
hard to read,
the proposed text should be easier to understand.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6143)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6143

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.2.7

Original Text
-
As of TLS 1.3, servers are permitted to send the "supported_groups"
extension to the client.

Corrected Text
--


Notes
-
It is unclear whether servers are permitted to send the "supported_groups" 
extension to 
the client without solicitation, i.e., when the client does not first send the 
extension to the 
server. Clarification would be useful.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6142)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6142

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.6.1.

Original Text
-
Clients MUST NOT cache tickets for longer than 7 days

Corrected Text
--
Clients MUST NOT use tickets for longer than 7 days

Notes
-
"MUST NOT cache" is surely overly zealous and may unnecessarily result in 
non-compliant implementations

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6141)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6141

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.4.3

Original Text
-
   -  The context string

Corrected Text
--
   -  The context string (defined below)

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6140)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6140

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.4.2.2.

Original Text
-
This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.

Corrected Text
--
This fullback chain MUST NOT use the deprecated SHA-1 hash,
except if advertised by the client, in which case it MAY.

Notes
-
The original text is difficult to read, eliminating the unnecessary "SHOULD 
NOT" seems to make it 
easier.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6139)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6139

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.4.2.2.

Original Text
-
As servers MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable.

Corrected Text
--
As servers MAY require the presence of the "server_name" extension, client
SHOULD send this extension.

Notes
-
Since it is unclear when it is applicable for a server to send the extension, 
dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6138)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6138

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.2.10

Original Text
-
   For externally  
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the
   connection which established the PSK.  

   ...

   For externally established 
   PSKs, the associated values are those provisioned along with the key.
   For PSKs established via a NewSessionTicket message, the associated  
   values are those negotiated in the connection during which the ticket
   was established. 

Corrected Text
--
   For externally  
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the
   connection which established the PSK.  

Notes
-
Drop largely verbatim duplicated text

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6137)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6137

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.2.10

Original Text
-
symmetric cipher suite

Corrected Text
--
cipher suite

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6136)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6136

--
Type: Technical
Reported by: Ben Smyth 

Section: 4.1.4

Original Text
-
   Upon receipt of a HelloRetryRequest, the client MUST check the
   legacy_version, legacy_session_id_echo, cipher_suite, and 
   legacy_compression_method as specified in Section 4.1.3 

Corrected Text
--


Notes
-
Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6135)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6135

--
Type: Editorial
Reported by: Ben Smyth 

Section: Global

Original Text
-
list, series, set, and vector are seemingly used as synonyms. 

Corrected Text
--
Using list, series, set, xor vector would help at least one reader. 


Notes
-
Additionally, consistent usage is desirable, e.g., page 31 uses "A list of 
extensions" whereas "A set of 
extensions" is used on page 60. Elsewhere inconsistently usage causes 
confusion, e.g., 
Page 48:

   client_shares:  A list of offered KeyShareEntry values in descending
  order of client preference.

   This vector MAY be empty if the client is requesting a

(Replace "vector" with "list", or vice versa.)

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6128)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6128

--
Type: Editorial
Reported by: Ben Smyth 

Section: GLOBAL

Original Text
-
terminate and abort are used interchangeable, but this isn't explained until 
after such use.

In Section 6.2, we have: In the rest of this specification, when the phrases 
"terminate the connection" and "abort the handshake" are used without a 
specific alert it means that the implementation SHOULD send the alert indicated 
by the
descriptions below.  

Corrected Text
--
Perhaps explain terminology earlier. At the very least, in Section 6.2, open 
the above sentence with "Throughout this specification"



Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6127)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6127

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.1.2.

Original Text
-
If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.

Corrected Text
--
If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group. Note: A "key_share" 
extension may not be supplied in a HelloRetryRequest message 
when a server receives  an "early_data" (Section 4.2.10).

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6126)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6126

--
Type: Editorial
Reported by: Ben Smyth 

Section: 4.1.1

Original Text
-
Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph.

Corrected Text
--
Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph, 
because PSK-only key exchange mode does not need supported_groups.

Notes
-
If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can 
be used, which doesn't require supported_groups. This is perhaps worthy of 
explanation.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6125)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6125

--
Type: Editorial
Reported by: Ben Smyth 

Section: GLOBAL

Original Text
-
PSKs are referred to as out-of-band and external

Corrected Text
--
Referring to PSKs as either out-of-band xor external would help at least one 
reader

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6124)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6124

--
Type: Editorial
Reported by: Ben Smyth 

Section: 2

Original Text
-
   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

Corrected Text
--
   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key
 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

or

   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set 
of Diffie-Hellman key 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Technical Errata Reported] RFC8446 (6123)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6123

--
Type: Technical
Reported by: Ben Smyth 

Section: 2

Original Text
-
The handshake protocol allows peers to negotiate a protocol version, select 
cryptographic algorithms, optionally authenticate each other, and establish 
shared secret keying material.

Corrected Text
--


Notes
-
Only client authentication is optional (albeit, server authentication is 
implicit for PSK-only key exchange mode)

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6122)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6122

--
Type: Editorial
Reported by: Ben Smyth 

Section: 1.2

Original Text
-
The key derivation functions have been redesigned.

Corrected Text
--
The key derivation function has been redesigned.

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6121)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6121

--
Type: Editorial
Reported by: Ben Smyth 

Section: 1

Original Text
-
cryptographic modes

Corrected Text
--
cryptographic algorithms

Notes
-


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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8446 (6120)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6120

--
Type: Editorial
Reported by: Ben Smyth 

Section: 1

Original Text
-
the underlying transport is a reliable, in-order data stream



Corrected Text
--
the underlying transport layer is a reliable, in-order stream delivery service

or

the underlying transport protocol is a reliable, in-order stream delivery 
service

or similar

Notes
-
Similar elsewhere

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC8447 (6009)

[RFC Errata System]

The following errata report has been submitted for RFC8447,
"IANA Registry Updates for TLS and DTLS".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6009

--
Type: Editorial
Reported by: Benjamin Kaduk 

Section: 14

Original Text
-
   o  Added a "Recommended" column to the registry.  X.509 and Raw


Corrected Text
--
   o  Added a "Recommended" column to the registry.  X509 and Raw


Notes
-
Update to match https://www.rfc-editor.org/errata/eid5976

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. 

--
RFC8447 (draft-ietf-tls-iana-registry-updates-05)
--
Title   : IANA Registry Updates for TLS and DTLS
Publication Date: August 2018
Author(s)   : J. Salowey, S. Turner
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

[TLS] [Errata Verified] RFC8446 (5976)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5976

--
Status: Verified
Type: Editorial

Reported by: Rich Salz 
Date Reported: 2020-02-04
Verified by: Benjamin Kaduk (IESG)

Section: 11

Original Text
-
   This document updates an entry in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."


Corrected Text
--
   This document updates two entries in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."  IANA has updated the entry for value 0 to have the name
   "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".

Notes
-
The protocol description language changed the spelling used for "X509", and the 
registry should be updated to match.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Errata Verified] RFC8422 (6002)

[RFC Errata System]

The following errata report has been verified for RFC8422,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security 
(TLS) Versions 1.2 and Earlier". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6002

--
Status: Verified
Type: Technical

Reported by: Rich Salz 
Date Reported: 2020-03-02
Verified by: Benjamin Kaduk (IESG)

Section: 9

Original Text
-
   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with this document as reference.  This
   keeps compatibility with TLS 1.3.


Corrected Text
--
   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with DTLS-OK set to "Y" and this document
   as reference.  This keeps compatibility with TLS 1.3.

Notes
-
IANA had consulted with Yoav, one of the authors (and a TLS registry expert), 
who explicitly told them to use DTLS-OK of "Y", but this clarification was not 
reflected in the final RFC.  This also matches the text in the subsequent 
paragraph.

--
RFC8422 (draft-ietf-tls-rfc4492bis-17)
--
Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Publication Date: August 2018
Author(s)   : Y. Nir, S. Josefsson, M. Pegourie-Gonnard
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

[TLS] [Technical Errata Reported] RFC8422 (6002)

[RFC Errata System]

The following errata report has been submitted for RFC8422,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security 
(TLS) Versions 1.2 and Earlier".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6002

--
Type: Technical
Reported by: Rich Salz 

Section: 9

Original Text
-
IANA has assigned two values in the "TLS SignatureAlgorithm" registry for 
ed25519 (7) and ed448 (8) with this document as reference.  This keeps 
compatibility with TLS 1.3.

Corrected Text
--
IANA has assigned two values in the "TLS SignatureAlgorithm" registry for 
ed25519 (7) and ed448 (8) with DTLS-OK set to true (T) and this document as 
reference.  This keeps compatibility with TLS 1.3.


Notes
-
IANA had consulted with Yoav, one of the authors (and a TLS registry expert), 
who explicitly told them to use DTLS-OK should be "Y".  This also matches the 
text in the subsequent paragraph.

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. 

--
RFC8422 (draft-ietf-tls-rfc4492bis-17)
--
Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Publication Date: August 2018
Author(s)   : Y. Nir, S. Josefsson, M. Pegourie-Gonnard
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

[TLS] [Editorial Errata Reported] RFC8446 (5976)

[RFC Errata System]

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5976

--
Type: Editorial
Reported by: Rich Salz 

Section: GLOBAL

Original Text
-
Section 4.4.2 has the following:
  enum {
  X509(0),
  RawPublicKey(2),
  (255)
  } CertificateType;


Corrected Text
--


Notes
-
The registry has "X.509" as the certificate type.  The IANA registry for TLS 
Certificate types at 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
 has "X.509" as the name for value 0.  The name should be changed to "X509" and 
the reference should be changed to RFC 8446.  A comment "Was X.509 before TLS 
1.3" should be added.

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. 

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
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

[TLS] [Editorial Errata Reported] RFC5246 (5955)

[RFC Errata System]

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5955

--
Type: Editorial
Reported by: Itumeleng 

Section: 5246

Original Text
-


Corrected Text
--


Notes
-


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. 

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
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