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

Closure alerts are errors too #4570

Merged
merged 3 commits into from Jan 14, 2021
Merged

Closure alerts are errors too #4570

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4cad27d
Closure alerts are errors too
martinthomson Jan 6, 2021
a7806d5
qualify
martinthomson Jan 7, 2021
0625b35
Wrap
martinthomson Jan 7, 2021
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
8 changes: 6 additions & 2 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -803,8 +803,12 @@ 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 is only able to convey an alert level of "fatal". In TLS 1.3, the only
existing uses for the "warning" level are to signal connection close; see
Section 6.1 of {{!TLS13}}. As QUIC provides alternative mechanisms for
connection termination and the TLS connection is only closed if an error is
encountered, a QUIC endpoint MUST treat any alert from TLS as if it were at the
"fatal" 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
Expand Down