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

Ben Kaduk's Transport Comment 10 #4617

Closed
LPardue opened this issue Jan 7, 2021 · 7 comments
Closed

Ben Kaduk's Transport Comment 10 #4617

LPardue opened this issue Jan 7, 2021 · 7 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.

Comments

@LPardue
Copy link
Member

LPardue commented Jan 7, 2021

@kaduk said:

Section 7.2

When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable
value. This Destination Connection ID MUST be at least 8 bytes in
length. [...]

My usual policy on seeing a random nonce shorter than 128 bits is to ask
for explanation of why the shorter value is safe for the use it is being
put to. (How bad would it be to bump this to 16?)

@LPardue LPardue added -transport iesg An issue raised during IESG review. labels Jan 7, 2021
@LPardue LPardue added this to the transport-iesg milestone Jan 7, 2021
@martinthomson
Copy link
Member

It's at least twice as good as the one used in TCP. As this is time-bounded and a collision even at probability 0.5 requires immense investment from an attack to engineer, this seems more than adequate for its purpose.

It is also the same size as the tokens we use for path validation. A change would be disruptive. I don't see any reason to change here.

@kaduk
Copy link
Contributor

kaduk commented Jan 10, 2021

Please consider reiterating that it is time bounded in the document (and for path validation as well); I would prefer to not have future protocols attempt to refer to QUIC's 8-byte value as justification for their own when they actually need something bigger.

@larseggert larseggert added this to Triage in Late Stage Processing via automation Jan 11, 2021
@larseggert larseggert added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Jan 12, 2021
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Jan 12, 2021
@janaiyengar
Copy link
Contributor

@kaduk : The immediate next sentence says Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection. That makes it clear enough I think.

@kaduk
Copy link
Contributor

kaduk commented Jan 13, 2021

I don't think that helps the reader make the connection that the shorter nonce is safe due to the time bound.
But I could be wrong, of course.

@larseggert
Copy link
Member

We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.

@janaiyengar
Copy link
Contributor

Since this comment is about how the nonce might be unsafe under other conditions, it's good enough to do nothing here.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Jan 27, 2021
@martinthomson
Copy link
Member

The nonce is safe because it has been analyzed. Anyone hoping to copy what QUIC does had best understand why QUIC does what it does before doing so. If we learn that people don't exercise judgment and discretion in this, we can try to fix it next time. We can't possibility preemptively foreclose on every conceivable bad decision in this spec. It's already far too large.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.
Projects
Late Stage Processing
  
Issue Handled
Development

No branches or pull requests

5 participants