Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define the use of generic TLS alerts #3601

Merged
merged 2 commits into from May 5, 2020
Merged

Define the use of generic TLS alerts #3601

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b41c848
Define the use of generic TLS alerts
martinthomson Apr 28, 2020
475242d
Tweaks from review
martinthomson Apr 28, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 18 additions & 11 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -740,19 +740,25 @@ QUIC implementations SHOULD instead use the Retry feature (see Section 8.1 of
{{QUIC-TRANSPORT}}). HelloRetryRequest is still used to request key shares.


## TLS Errors
## TLS Errors {#tls-errors}

If TLS experiences an error, it generates an appropriate alert as defined in
Section 6 of {{!TLS13}}.

A TLS alert is turned into a QUIC connection error by converting the one-byte
alert description into a QUIC error code. The alert description is added to
0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.
The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.
A TLS alert is converted into a QUIC connection error. The alert description is
added to 0x100 to produce a QUIC error code from the range reserved for
CRYPTO_ERROR. The resulting value is sent in a QUIC CONNECTION_CLOSE frame of
type 0x1c.

The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate
alerts at the "warning" level.

QUIC permits the use of a generic code in place of a specific error code; see
Section 11 of {{QUIC-TRANSPORT}}. For TLS alerts, this includes replacing any
alert with a generic alert, such as handshake_failure (0x128 in QUIC).
Endpoints MAY use a generic error code to avoid possibly exposing confidential
information.


## Discarding Unused Keys

Expand Down Expand Up @@ -1567,12 +1573,13 @@ QUIC requires that the cryptographic handshake provide authenticated protocol
negotiation. TLS uses Application Layer Protocol Negotiation (ALPN)
{{!ALPN=RFC7301}} to select an application protocol. Unless another mechanism
is used for agreeing on an application protocol, endpoints MUST use ALPN for
this purpose. When using ALPN, endpoints MUST immediately close a connection
(see Section 10.3 in {{QUIC-TRANSPORT}}) if an application protocol is not
negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see
{{tls-errors}}). While {{!ALPN}} only specifies that servers use this alert,
QUIC clients MUST also use it to terminate a connection when ALPN negotiation
fails.
this purpose.

When using ALPN, endpoints MUST immediately close a connection (see Section
10.3 of {{QUIC-TRANSPORT}}) with a no_application_protocol TLS alert (QUIC error
code 0x178; see {{tls-errors}}) if an application protocol is not negotiated.
While {{!ALPN}} only specifies that servers use this alert, QUIC clients MUST
use error 0x178 to terminate a connection when ALPN negotiation fails.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct to read that this MUST requires a client that receives a no_application_protocol alert to respond with a no_application_protocol alert?

I am not sure if that aligns to what we have now. At the moment, the provisions that we have is that an endpoint that receives CONNECTION_CLOSE MAY respond with a CONNECTION_CLOSE, using NO_ERROR if appropriate (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-10.3-7).

Based on that, I think what we need here is MAY rather than MUST, and think that NO_ERROR is more appropriate (assuming that we do not have a principle of an endpoint that receives a CONNECTION_CLOSE frame carrying an error echo the error code it has received). Or it might make sense to just drop the last sentence.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is intended to apply to the case when a server does not include an ALPN extension. If the client receives an alert, ALPN isn't really the thing that failed -- the handshake is.


An application protocol MAY restrict the QUIC versions that it can operate over.
Servers MUST select an application protocol compatible with the QUIC version
Expand Down