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.

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

Deny 1-RTT Rx keys till finished #3174

Closed
wants to merge 2 commits into from
Closed

Deny 1-RTT Rx keys till finished #3174

wants to merge 2 commits into from

Conversation

martinduke
Copy link
Contributor

Fix for #3173.

Copy link
Member

@martinthomson martinthomson left a comment

Choose a reason for hiding this comment

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

This seems fine, though I was a little concerned about levying requirements on TLS stacks in this way, it seems like a reasonable thing to recommend.

draft-ietf-quic-tls.md Outdated Show resolved Hide resolved
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
Copy link
Member

@kazuho kazuho left a comment

Choose a reason for hiding this comment

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

Thank you for the PR. I agree that giving a warning to the implementors in the QUIC-TLS draft is the right choice.

I am fine with the PR aside from the editorial concern below.

@@ -504,6 +504,9 @@ client could interleave ACK frames that are protected with Handshake keys with
0-RTT data and the server needs to process those acknowledgments in order to
detect lost Handshake packets.

A TLS implementation MUST NOT provide a 1-RTT decrypt secret to QUIC until it
the TLS handshake is complete.
Copy link
Member

@kazuho kazuho Oct 31, 2019

Choose a reason for hiding this comment

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

As stated in #3173 (comment), I do not think we should be using a normative word here, as this is a requirement in the TLS 1.3 handshake protocol (specifycally the one stated in section 4.4.4).

QUIC is a user of the TLS handshake protocol (like DTLS 1.3), and we should not re-mandate a behavior that the TLS handshake protocol already requires you to do.

That said, I am fine with editors making the choice.

Copy link
Member

Choose a reason for hiding this comment

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

I'm persuaded by Kazuho's argument here. I don't think that we need the whole appendix, but a note on this might be worth adding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants