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 1 commit
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.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -1642,7 +1642,7 @@ 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. A client MUST NOT request the use of the TLS 1.3
compatibility mode. A server MUST treat the receipt of a TLS ClientHello that
compatibility mode. A server SHOULD treat the receipt of a TLS ClientHello that
requests the use of the TLS 1.3 middlebox compatibility mode as a connection
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
error of type PROTOCOL_VIOLATION.
Copy link
Member

@kazuho kazuho Apr 23, 2020 •
edited

Choose a reason for hiding this comment

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

Use of MUST NOT for client is fine, but I would prefer using SHOULD or MAY on the server-side.

In a server-side TLS 1.3 stack, it is entirely reasonable to implement Compatibility Mode at the record layer in a reactive manner. In your record layer, when you receive the handshake traffic secret from the handshake layer, you inject CCS depending on the length of SH.legacy_session_id that has been retained. At the moment, there's nothing that has to be done at the handshake layer on the server-side.

Use of MUST NOT for the server breaks TLS stacks implemented that way.

Copy link
Contributor

Choose a reason for hiding this comment

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

In your record layer, when you receive the handshake traffic secret from the handshake layer, you inject CCS depending on the length of SH.legacy_session_id that has been retained. At the moment, there's nothing that has to be done at the handshake layer on the server-side.

Assume that you're not validating the empty legacy_session_id on the server side, how would you prevent the injection of CCS then?

Copy link
Member Author

Choose a reason for hiding this comment

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

I can do SHOULD.

The way our stack works is that we let TLS consume the ClientHello and then ask it for a response. That produces a CCS if the client asked for one. We turn that into an error (we used to crash). Any implementation could, as I think Kazuho suggests, just drop the CCS, which might be easier in cases where your interface only passes handshake records. We have a generic record callback, so detecting record type 20 is easy.


Expand Down