1751157 - NSS TLS 1.3 ensure correct alerts are send

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement)

Description

[Leander Schwarz]

Upon the client receiving an EncryptedExtensions message that contains extensions that are not permitted in this message, NSS responds with an 'unsupported extension' alert (tested this with Padding and SupportedVersions extensions)

RFC 8446 - 4.3.1. Encrypted Extensions
The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert.

When a TLS 1.2 server selects a protocol version not supported by NSS client. NSS responds with an 'illegal parameter' alert.

RFC 5246 - E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
    If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection.

Comment 1

[Leander Schwarz]

There are contradictory statements in RFC8446 regarding the correct alert sent on reception of prohibited/unspecified extensions in handshakes.

Section 6.2 Error Alerts generally states:

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.

While Section 4.2 Extensions states:

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.

I think the MUST keyword implies that the "illegal_parameter" alert should be sent and we should submit an RFC errata to clear this up (suggest specification of unsupported_extensions description not contradictory to the statement in 4.2).

Comment 2

[Leander Schwarz]

Attachment: Bug 1751157 - Throw illegal_parameter alert for illegal extensions in handshake message. r=djackson

Comment 3

[Martin Thomson [:mt:]]

So I think that the text in 4.2 is clear one way:

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.

That is, if the extension cannot appear in that particular message, then it's illegal_parameter. That maps to our tls13_extension_disallowed status for all messages by my reading (not just EncryptedExtensions as in your patch).

And you are right in that this contracts the definition of unsupported_extension.

I would personally prefer to use unsupported_extension here, but the more direct wording in Section 4.2 makes me think that illegal_parameter is what was intended. Of course, it could also be that unsupported_extension is just a more specific code for a general illegal_parameter condition and the spec might allow either. That would annoy people who write compliance tests, but it would also be better for everyone else.

Rather than file an erratum, I would start by mailing tls@ietf with the question.

Comment 4

[Leander Schwarz]

The same question was asked before in the mailing list (https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/) and refers to section 6.2 stating that the main test (section 4.2) is of higher importance, so illegal_parameter alert should be correct for prohibited extensions.

Comment 5

[Leander Schwarz]

When a TLS server selects an protocol version greater than TLS 1.2 by writing it to its 'server_hello.legacy_version' field, the client responds with an 'illegal_parameter' alert. This behavior is RFC compliant following section 4.1.3,

In TLS 1.3, the TLS server indicates
its version using the "supported_versions" extension
(Section 4.2.1), and the legacy_version field MUST be set to
0x0303, which is the version number for TLS 1.2.

and section 6.2:

illegal_parameter: A field in the handshake was incorrect or
inconsistent with other fields. This alert is used for errors
which conform to the formal protocol syntax but are otherwise
incorrect.

protocol_version: The protocol version the peer has attempted to
negotiate is recognized but not supported.

For unsupported versions < TLS 1.3 the client correctly responds with 'protocol_version' alert as specified in RC8446 section D.1:

If the version chosen by the server is not supported by the client
(or is not acceptable), the client MUST abort the handshake with a
"protocol_version" alert.

The original reporter confirmed that the supposedly wrong behavior might have been caused by them testing with undefined version numbers > TLS 1.2 (0x303).

Comment 6

[Dennis Jackson]

https://hg.mozilla.org/projects/nss/rev/8fd5ca0cf8976bcef820f7b507d45e1527c1c029