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

Packet protection or not? #3887

Closed
MikeBishop opened this issue Jul 9, 2020 · 2 comments · Fixed by #3900
Closed

Packet protection or not? #3887

MikeBishop opened this issue Jul 9, 2020 · 2 comments · Fixed by #3900
Labels
-tls -transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@MikeBishop
Copy link
Contributor

In Transport, we say:

Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.

However, in TLS we have a section named "Packet Protection" (Section 5) with subsections describing how to protect Initial (5.2) and Retry (5.8) packets which talk about Initial, at least, as using packet protection. I think it would be clearer to describe the lack of security properties that this limited form of protection provides, rather than say they're not protected at all.

Alternatively, we could rework the language in TLS, but that feels like a bigger terminology change.

@MikeBishop MikeBishop added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport -tls labels Jul 9, 2020
@martinthomson
Copy link
Member

ekr suggested that we limit the use of "integrity protection" (and I presume "confidentiality protection") to those cases where the protection is real, and not based on fixed keys or trivially-acquired keys. I think that might be the best answer here, even if that takes more effort to get right.

@janaiyengar
Copy link
Contributor

@martinthomson : That sounds good like a good way forward.

martinthomson added a commit that referenced this issue Jul 14, 2020
This breaks down some of the packet protection text in favour of more
specific language about the protections provided.  By preference,
this talks about integrity protection and confidentiality protection as
it relates to those packets that are protected using keys derived from
TLS.  For Initial packets this means avoid use of "packet protection" as
much as possible (I'm sure that I have missed some of these).  The same
for Retry.

This required some additional framing, but it wasn't too intrusive.
Most of the changes are cosmetic.

Closes #3887.
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

Successfully merging a pull request may close this issue.

3 participants