On 12/16/2020 8:35 PM, Fernando Gont wrote:
On 17/12/20 01:08, Christian Huitema wrote:
[...]
Our document requires specifications to spell out the
interoperability requirements, because quite too often speficiations
specify things they need not.
For example, the QUIC spec specifies sequence numbers start at 0.
*That* is an over specification. Because sequence numbers need not
start at zero.
QUIC does not mandate that sequence numbers start at 0.
Section 5.1.1 of draft-ietf-quic-transport-29 says:
" The sequence number of the
initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1.
"
Later in the same section, it says:
" The sequence number on
each newly-issued connection ID MUST increase by 1. "
When you mentioned "sequence numbers", I thought that you were referring
to packet sequence numbers.
Connection ID sequence numbers are something else entirely. The sequence
numbers are used to manage the creation and release of the Connection ID
objects. For a variety of protocol reasons, the connection ID sequence
numbers must start at zero.
This is actually a great example of the kind of discussions that would
arise if this draft was published. You lob these "connection ID sequence
numbers" is the arbitrary category of "temporary identifiers", and start
making generic statements about the need to apply some kind of
randomization. Yet the "connection ID sequence numbers" are never
visible on the wire, and there is no reason to believe that they have
any effect on the security or privacy considerations of the protocol.
OTOH, with respect to connection I-Ds, Section 5.1.1 says:
"Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and to be
identified by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same
connection. As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection."
But then, the next section ("5.1.1. Issuing Connection IDs") talks
about randomized connection IDs:
The connection
ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection
ID.
So yes: sequence numbers seem to be over-specified, and connection-ids
seem to be under-specified.
What am I missing?
In short, you are missing the tons of discussions that went into that
specification, taking into account the needs of a variety of
environments including for example server farms. You are also picking
out the Initial Connection ID out of context -- for protocol reasons, it
is not generated in the same way as other connection IDs.
Again, you are providing a great example of why the IETF should not
publish this draft. It is using an abstract generalization of
"identifiers" to draw broad recommendations that are at odds with actual
protocol development practice. Endorsing these recommendation in a BCP
or even an informational RFC will be harmful, because it will cause
unnecessary discussions, just like the one we are having here.
When I saw the first iterations of this work, my feeling was that
documenting a class of design failures was great, but trying to go from
there to design mandates was going too far. A couple years later, my
opinion has not change. An informational document documenting a series
of past attacks would be interesting and educational. The kind of rule
making proposed in the draft, on the other hand, would be mostly harmful.
-- Christian Huitema
-- Christian Huitema
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
