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

Prohibit TLS 1.3 middlebox compatibility mode #3595

Merged
merged 4 commits into from
May 14, 2020
Merged

Prohibit TLS 1.3 middlebox compatibility mode #3595

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d4baa8a
Prohibit TLS 1.3 middlebox compatibility mode
martinthomson Apr 22, 2020
cf939cc
Servers don't have to enforce
martinthomson Apr 23, 2020
3a633d8
reference legacy_session_id directly
martinthomson May 10, 2020
6a4c95e
You can't carry CCS anyway
martinthomson May 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 21 additions & 5 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,10 +188,6 @@ TLS provides two basic handshake modes of interest to QUIC:
self-contained trigger for any non-idempotent action.

A simplified TLS handshake with 0-RTT application data is shown in {{tls-full}}.
Note that this omits the EndOfEarlyData message, which is not used in QUIC (see
{{remove-eoed}}). Likewise, neither ChangeCipherSpec nor KeyUpdate messages are
used by QUIC; ChangeCipherSpec is redundant in TLS 1.3 and QUIC has defined its
own key update mechanism {{key-update}}.

~~~
Client Server
Expand All @@ -213,6 +209,11 @@ own key update mechanism {{key-update}}.
~~~
{: #tls-full title="TLS Handshake with 0-RTT"}

{{tls-full}} omits the EndOfEarlyData message, which is not used in QUIC; see
{{remove-eoed}}. Likewise, neither ChangeCipherSpec nor KeyUpdate messages are
used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; see {{compat-mode}}.
QUIC has its own key update mechanism; see {{key-update}}.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Worth noting that it's not possible to send CCS anywya?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not here, but I'll do that below.


Data is protected using a number of encryption levels:

- Initial Keys
Expand Down Expand Up @@ -1554,7 +1555,7 @@ Handshake packets, but because that tampering requires modifying TLS handshake
messages, that tampering will cause the TLS handshake to fail.


# QUIC-Specific Additions to the TLS Handshake
# QUIC-Specific Adjustments to the TLS Handshake

QUIC uses the TLS handshake for more than just negotiation of cryptographic
parameters. The TLS handshake provides preliminary values for QUIC transport
Expand Down Expand Up @@ -1631,6 +1632,21 @@ PROTOCOL_VIOLATION.
As a result, EndOfEarlyData does not appear in the TLS handshake transcript.


## Prohibit TLS Middlebox Compatibility Mode {#compat-mode}

Appendix D.4 of {{!TLS13}} describes an alteration to the TLS 1.3 handshake as
a workaround for bugs in some middleboxes. The TLS 1.3 middlebox compatibility
mode involves setting the legacy_session_id field to a 32-byte value in the
ClientHello and ServerHello, then sending a change_cipher_spec record. Both
field and record carry no semantic content and are ignored.

This mode has no use in QUIC as it only applies to middleboxes that interfere
with TLS over TCP. QUIC also provides no means to carry a change_cipher_spec
record. A client MUST NOT request the use of the TLS 1.3 compatibility mode. A
server SHOULD treat the receipt of a TLS ClientHello that with a non-empty
legacy_session_id field as a connection error of type PROTOCOL_VIOLATION.


# Security Considerations

All of the security considerations that apply to TLS also apply to the use of
Expand Down