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

Cleartext integrity as version independent #568

Closed
mcmanus opened this issue Jun 3, 2017 · 4 comments
Closed

Cleartext integrity as version independent #568

mcmanus opened this issue Jun 3, 2017 · 4 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@mcmanus
Copy link
Contributor

mcmanus commented Jun 3, 2017

making the cleartext integrity checksum version independent would prevent a lot of version negotiation packets from being generated based on receipt of non-quic (and make it harder to use that as an amplification vector?)

@martinthomson
Copy link
Member

If version negotiation is amplifying, something is badly wrong.

I believe that version negotiation should only be generated for packets that exceed a certain size (because the only packet that it makes sense to send version negotiation in response to is an initial client packet and those are guaranteed* to be pretty big*). That is, for some version of a guarantee and some version of big. Note however that we don't have that written down (or even agreed).

As for being able to distinguish noise from QUIC, that's a good reason. We should discuss that.

@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Jun 4, 2017
@mcmanus
Copy link
Contributor Author

mcmanus commented Jun 4, 2017

re: amp - that's a versioning guarantee thing again.. a v1 initial client packet is pretty big.. but a >1 packet received by a v1 server? we have very few rules about the future.. maybe we need a few.

@martinthomson
Copy link
Member

Yes, some constraints on future flexibility seem wise, as long as we can keep it light.

@martinthomson martinthomson added this to Packets in QUIC Jun 5, 2017
@mnot mnot modified the milestone: First Implementation Draft Jun 6, 2017
@mnot mnot changed the title consider making cleartext integrity version independent Cleartext integrity as version independent Jun 20, 2017
@mnot mnot moved this from Packets to Crypto in QUIC Jun 21, 2017
@martinthomson
Copy link
Member

I think that we resolved this with invariants and #724. @mcmanus, explain and reopen if you disagree.

@mnot mnot removed this from Crypto in QUIC Mar 6, 2018
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

3 participants