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

Consistent use of the term protected packets #994

Closed
mikkelfj opened this issue Dec 6, 2017 · 1 comment
Closed

Consistent use of the term protected packets #994

mikkelfj opened this issue Dec 6, 2017 · 1 comment
Labels
-tls -transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@mikkelfj
Copy link
Contributor

mikkelfj commented Dec 6, 2017

QUIC TLS 08 sec. 5.3 claims that clear text packets are protected by AEAD with a key derived from the connection ID. This is correct, but later the TLS document uses the terminology protected and unprotected to distinguish between cleartext packets and 1-RTT protected packets.

The transport document refers to all packet types as being protected by some key, except for version neg, and stateless reset. This is correct, but the terminology does not match the TLS unprotected terminology. Also, the term cleartext is a bit vague at this point.

I realize this is likely a left-over from before cleartext packets became protected and rephrasing the entire QUIC TLS doc probably isn't top priority in the editing process.

@mnot mnot added -tls editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Dec 12, 2017
@ianswett ianswett assigned ianswett and unassigned ianswett Mar 14, 2018
@seanturner
Copy link
Contributor

We'll definitely do a sanity check before we're done. This is noted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-tls -transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

4 participants