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

Advice for middlebox authors #4305

Closed
larseggert opened this issue Oct 28, 2020 · 4 comments
Closed

Advice for middlebox authors #4305

larseggert opened this issue Oct 28, 2020 · 4 comments
Labels
-invariants ietf-lc An issue that was raised during IETF Last Call.

Comments

@larseggert
Copy link
Member

Reviewer: Yoav Nir
Review result: Ready

The contents of the "security and privacy considerations" section seems to be
advice for middlebox authors. I think that it may have been better to name the
section something else. However, there is no information that is missing, so I
don't really have any recommendations for changing things.

@larseggert larseggert added this to the secdir-invariants milestone Oct 28, 2020
@larseggert larseggert added this to Triage in Late Stage Processing via automation Oct 28, 2020
@larseggert
Copy link
Member Author

Opening this in case we want to make editorial changes.

@martinthomson
Copy link
Member

I understand the concern, but of the options I can think of, doing nothing seems best.

I considered:

  1. Moving this text to Section 2 (and removing the redundant point to the appendix)
  2. Moving this text to a new section entitled "Middlebox Considerations" or some such
  3. Doing nothing

I think we can justify this on the basis that these can be thought of as attacks. Maybe not on the protocol, or specific deployments of it, but on the ability of the protocol to evolve. Critically, these are attacks that this draft does not protect against.

@larseggert larseggert added the ietf-lc An issue that was raised during IETF Last Call. label Nov 2, 2020
@martinthomson martinthomson added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Nov 5, 2020
@project-bot project-bot bot moved this from Triage to Consensus Emerging in Late Stage Processing Nov 5, 2020
@janaiyengar
Copy link
Contributor

Agreed. It's worth noting that this isn't a protocol document, this is documenting the unchanging aspects of the protocol. Section 1 says "The primary goal of this document is to ensure that it is possible to deploy new versions of QUIC."

Given that, it's reasonable to argue that the security considerations apply to the evolvability of QUIC.

@LPardue
Copy link
Member

LPardue commented Dec 8, 2020

The proposed resolution was to close to with action, which was signalled to the appropriate review channel.

Hearing no pushback, I'm closing this.

@LPardue LPardue closed this as completed Dec 8, 2020
Late Stage Processing automation moved this from Consensus Emerging to Issue Handled Dec 8, 2020
@LPardue LPardue removed the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-invariants ietf-lc An issue that was raised during IETF Last Call.
Projects
Late Stage Processing
  
Issue Handled
Development

No branches or pull requests

4 participants