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.

Sign up for GitHub

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

Jump to bottom

use TRANSPORT_PARAMETER_ERROR when authenticating connection IDs #3691

Merged
merged 5 commits into from Jun 9, 2020
Merged

use TRANSPORT_PARAMETER_ERROR when authenticating connection IDs #3691

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
994f32d
use TRANSPORT_PARAMETER_ERROR when authenticating connection IDs
marten-seemann May 24, 2020
065e9aa
use PROTOCOL_VIOLATIONs for the retry_source_connection_id checks
marten-seemann May 27, 2020
e241f42
Turn the absence clauses into prose
martinthomson May 27, 2020
bb533c0
Merge pull request #6 from quicwg/3691-prose
marten-seemann May 27, 2020
7e50215
Fixups from review
martinthomson Jun 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 7 additions & 6 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1583,14 +1583,15 @@ values that an endpoint used in the Destination and Source Connection ID fields
of Initial packets that it sent. Including connection ID values in transport
parameters and verifying them ensures that that an attacker cannot influence
the choice of connection ID for a successful connection by injecting packets
carrying attacker-chosen connection IDs during the handshake. An endpoint MUST
treat any of the following as a connection error of type PROTOCOL_VIOLATION:
carrying attacker-chosen connection IDs during the handshake.

* absence of the initial_source_connection_id transport parameter from either
endpoint,
An endpoint MUST treat absence of the initial_source_connection_id transport
parameter from either endpoint or absence of the
original_destination_connection_id transport parameter from the server as a
connection error of type TRANSPORT_PARAMETER_ERROR.

* absence of the original_destination_connection_id transport parameter from
the server,
An endpoint MUST treat the following as a connection error of type
TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:

* absence of the retry_source_connection_id transport parameter from the server
after receiving a Retry packet,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my preference would be to allow either PROTOCOL_VIOLATION or TRANSPORT_PARAMETER_ERROR to be used when retry_source_connection_id is missing (or when it exists for no reason).

This is borderline, and in the past, we have allowed more than one error code to be used when that is reasonable. In this specific case, the QUIC stack can ask the decoder of Transport Parameters to provide source_connection_id (or to not provide one). In such a design, it is reasonable for the decoder of the Transport Parameters to raise an error when that expectation does not match.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the existing rules we basically permit either. Is there some way you would prefer to phrase this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We permit specific error codes to be replaced by PROTOCOL_VIOLATION, not the other way round, iirc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The simplest change would be to move these two cases that deal with retry_source_connection_id above, so that they would be classified as TRANSPORT_PARAMETER_ERROR. Doing so does not forbid endpoints from sending PROTOCOL_VIOLATION, as we have a catch-all clause stating that sending PROTOCOL_VIOLATION in place of other error code is permitted.

If want to be verbose, we could say that An endpoint MUST treat the following as a connection error of type PROTOCOL_VIOLATION or TRANSPORT_PARAMETER_ERROR: (list the two bullet points covering retry_source_connection_id).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WFM

Expand Down