Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

[Lucas Pardue <[e-mail]>]

Hi Ben,

Thanks for the review. I've captured your comments as issues on the QUIC WG
GItHub repository. Links to each are provided as in-line responses.

On Wed, Jan 6, 2021 at 9:45 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-quic-transport-33: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is very much a "discuss discuss", and I am not strongly convinced
> that there is a problem here, but if there is a problem it is a fairly big
> one.
>
> This document defers creation of a downgrade protection mechanism for
> version negotiation; after all, if there is only one version in
> existence, there is nothing to negotiate.  However, an effective
> downgrade protection mechanism requires support from all potentially
> affected parties in order to be reliable, so some careful thought is in
> order.  If we limit ourselves to a mindset where QUIC versions are
> infrequent undertakings brought about by standards action (i.e., we
> don't have to worry until a "v2" exists), then deferring seems to be
> okay (but part of the Discuss is to confirm that my reasoning is valid).
> The main goal of downgrade protection is to be able to distinguish a node
> that only supports v1 (or in general, any single version, or set of
> versions that only has one overlapping version with the peer) from one
> that supports a different shared version but was tricked by an attacker
> into using v1 when it otherwise would have used a different version.
> I'll call that different version v2 for clarity.  However, if the peer
> only supports v1, there's nothing to distinguish and nothing to
> negotiate; it suffices to ensure that all nodes that are capable of v2
> support the downgrade protection scheme.  That is, an attacker can only
> change the negotiated protocol version (as opposed to just causing
> connection failure, which can be done in many other ways) if there is
> some shared version other than v1 that would have been negotiated in the
> absence of the attacker.  So, if v2 is definitly going to be
> defined+implemented before other versions, and all nodes that support v2
> support downgrade protection, we are guaranteed that in any case where
> two peers would negotiate v2 in the absence of an attack, both peers
> support the downgrade protection mechanism and thus that mechanism will
> be effective in the face of an attack.  Peers that don't support the
> mechanism only do v1 and so there is no downgrade possible when they are
> participating in the connection.  (We would, of course, still need to be
> confident that we could define such a downgrade protection scheme in a
> backwards-compatible manner, though this seems like a fairly low bar
> given the extensibility provided by transport parameters and frame
> types.)
>
> However, it's not clear to me that this assumption holds that v2 is
> going to be the next version and that every node that implements v1 and
> some other version will definitely implement v2.  In particular, we
> currently have a very open registration policy for new versions, and
> there may be a desire to have some custom version of QUIC, perhaps that
> only has a small difference from v1, and furthermore a desire to use
> that custom version when available but be able to use v1 when not
> available.  There might be multiple such new versions in development in
> parallel, with no clear "first new version" tasked with the
> responsibility to develop a downgrade protection mechanism for global
> use.  The interaction between multiple competing downgrade-protection
> mechanisms seems likely to become quite messy quite quickly, so I am
> inclined to see "make each non-standards-track version specify their own
> downgrade protection" as a non-starter.
>
> I think that the lack of a secure downgrade protection mechanism is
> fundamentally incompatible with an open procedure for creating new
> versions while claiming that the protocol is a secure protocol.  While it
> would not be a pleasant choice, I think we might be forced to require
> standards action for new QUIC versions until we have a single global
> downgrade protection mechanism defined.  Or perhaps I misunderstand the
> ecosystem that we are trying to produce, or am making erroneous
> assumptions.  I'd love to hear more about how the WG decided to proceed
> with the current formulation, especially with regard to what
> consideration was given to non-standards-track new versions.
>
> The above notwithstanding, I support this protocol and I expect to
> change my position to Yes once this point is resolved in some manner.
>
>
https://github.com/quicwg/base-drafts/issues/4607


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This protocol is nicely done and the document well-written and
> well-organized.  It's really exciting to see what we can do with a
> nearly clear slate and the accumulated modern knowledge about protocol
> design.  Congratulations and thanks to all who contributed!
> Special thanks (in advance) to the chairs for helping translate my
> comments into github issues.
>
> I have some editorial suggestions that I put up at
> https://github.com/quicwg/base-drafts/pull/4597 .
>
> Abstract, Section 1
>
> My understanding is that "exemplary" typically is used to refer to not
> just any example of the topic in question, but to one that is the
> pinnacle of achievement or the best of its kind.  Do we intend to make
> such a claim about the congestion control algorithm in [QUIC-RECOVERY]?
>

https://github.com/quicwg/base-drafts/issues/4608


> Section 1.3
>
>    x (E) ...:  Indicates that x is repeated zero or more times (and that
>       each instance is length E)
>
> Does "repeated zero or more times" mean that there is zero or more
> instances in total, or one or more instances in total?  (I assume the
> latter, and would suggest additional wording if the former is what was
> intended.)  I am specifically curious about the application to the Ack
> Range field of the ACK Frame, since it seems like early on in a
> connection it is not always possible to construct a valid Gap field, but
> will not duplicate the question there.
>

https://github.com/quicwg/base-drafts/issues/4609


> Section 2.4
>
>    *  write data, understanding when stream flow control credit
>       (Section 4.1) has successfully been reserved to send the written
>       data;
>
> (side note) I note that "flow control credit has been reserved" is
> different than "has been ACKd by the peer".  I guess the expectation is
> that if such information is needed, an application-layer ACK should be
> used, since QUIC ACKs can be sent before the peer application has
> consumed the received data?
>
>
https://github.com/quicwg/base-drafts/issues/4610

Section 3.1
>
> I'm not sure why "Peer Creates Bidirectional Stream" appears on two
> transitions in the figure.  The prose suggests that the copy on the
> Ready->Send transition is erroneous.
>

https://github.com/quicwg/base-drafts/issues/4611


> Section 4.1
>
>    QUIC employs a limit-based flow-control scheme where a receiver
>    advertises the limit of total bytes it is prepared to receive on a
>    given stream or for the entire connection.  [...]
>
> Should I be reading some distinction into "limit-based" (here) vs
> "credit-based" (earlier) flow control?
>

https://github.com/quicwg/base-drafts/issues/4612


> Section 4.2
>
>    When a sender receives credit after being blocked, it might be able
>    to send a large amount of data in response, resulting in short-term
>    congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
>    how a sender can avoid this congestion.
>
> No such section exists in the -33; perhaps §7.7 is intended?
>

https://github.com/quicwg/base-drafts/issues/4613


> Section 5.1.1
>
>    An endpoint SHOULD ensure that its peer has a sufficient number of
>    available and unused connection IDs.  Endpoints advertise the number
>    of active connection IDs they are willing to maintain using the
>    active_connection_id_limit transport parameter.  An endpoint MUST NOT
>    provide more connection IDs than the peer's limit.  [...]
>
> IIUC, the reason that a negotiated limit is needed here is not exactly
> for the storage of the connection ID values themselves (though the
> requirement to explicitly use RETIRE_CONNECTION_ID makes it not as
> simple as it might be), but rather due to the requirement to recognize
> the associated stateless reset tokens.  Is that correct?  If so, perhaps
> it could be mentioned as a factor, here.
>

https://github.com/quicwg/base-drafts/issues/4614


> Section 5.2.2
>
>                                    Servers SHOULD respond with a Version
>    Negotiation packet, provided that the datagram is sufficiently long.
>
> This SHOULD seems redundant with the first sentence of the section?
>
>    Packets with a supported version, or no version field, are matched to
>    a connection using the connection ID or - for packets with zero-
>    length connection IDs - the local address and port.  These packets
>    are processed using the selected connection; otherwise, the server
>    continues below.
>
> (side note) Packets with a short header do not indicate the connection
> ID length (or version).  I think we admit the possibility that a server
> could advertise a zero-length connection ID to some but not all clients;
> does that imply that a lookup by address/port in the local connection
> database would be needed to determine whether such a short-header packet
> would have a zero-length connection ID or not?
>

https://github.com/quicwg/base-drafts/issues/4615


> Section 6.2
>
>                                                A client MUST discard any
>    Version Negotiation packet if it has received and successfully
>    processed any other packet, including an earlier Version Negotiation
>    packet.  [...]
>
> It seems like this requirement might be too strict, in that it could
> prevent otherwise successful communication when a limited on-path
> attacker injects a Version Negotiation packet.
>

https://github.com/quicwg/base-drafts/issues/4616


> 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?)
>

https://github.com/quicwg/base-drafts/issues/4617


>                                                            Once a client
>    has received a valid Initial packet from the server, it MUST discard
>    any subsequent packet it receives with a different Source Connection
>    ID.
>
> This seems over-zealous as written, since it would seem to prevent the
> server from ever using a new Source Connection ID on that connection,
> even in response to a client migration event.  Is it intended to be
> scoped to just Initial (and Handshake?) packets as is done for the
> server in the following paragraph?
>

https://github.com/quicwg/base-drafts/issues/4618


> Section 7.4
>
>                    Application protocols can recommend values for
>    transport parameters, such as the initial flow control limits.
>    However, application protocols that set constraints on values for
>    transport parameters could make it impossible for a client to offer
>    multiple application protocols if these constraints conflict.
>
> Should we go a step further and forbid application protocols from making
> such requirements?
>

https://github.com/quicwg/base-drafts/issues/4619


> Section 7.5
>
>    Once the handshake completes, if an endpoint is unable to buffer all
>    data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
>    CRYPTO frames received in the future, or it MAY close the connection
>    with a CRYPTO_BUFFER_EXCEEDED error code.  [...]
>
> How future-proof is this?  NewSessionTicket is "safe" to discard in that
> doing so has no negative consequences for the current connection (it may
> indicate that previously received tickets have been invalidated, but
> that is also fairly benign and can happen for other reasons), but in
> general post-handshake CRYPTO frames are not constrained in what TLS
> messages they can carry, including any TLS messages defined in the
> future.  I am not sure that we can effectively require all future TLS
> post-handshake messages to be safe to discard.
>

https://github.com/quicwg/base-drafts/issues/4620


> Section 8.1.3
>
>    Clients that want to break continuity of identity with a server MAY
>    discard tokens provided using the NEW_TOKEN frame.  [...]
>
> This seems more like a SHOULD than a MAY, given the precondition.
>

https://github.com/quicwg/base-drafts/issues/4621


>                                                     A server SHOULD
>    encode tokens provided with NEW_TOKEN frames and Retry packets
>    differently, and validate the latter more strictly.  [...]
>
> Didn't we already have a MUST-level requirement for being able to tell
> them apart, in §8.1.1?
>

https://github.com/quicwg/base-drafts/issues/4622


> Section 8.1.4
>
>    An address validation token MUST be difficult to guess.  Including a
>    large enough random value in the token would be sufficient, but this
>    depends on the server remembering the value it sends to clients.
>
> (How large is "large enough?")
>

https://github.com/quicwg/base-drafts/issues/4623


> Section 8.2
>
>    Path validation is used by both peers during connection migration
>    (see Section 9) to verify reachability after a change of address.  In
>    path validation, endpoints test reachability between a specific local
>    address and a specific peer address, where an address is the two-
>    tuple of IP address and port.
>
> In light of the toplevel definition of "address" in this document, the
> last clause seems unnecessary.
>

https://github.com/quicwg/base-drafts/issues/4624


> Section 9
>
>    The design of QUIC relies on endpoints retaining a stable address for
>    the duration of the handshake.  [...]
>
> Why do we allow PATH_CHALLENGE (and the impossible PATH_RESPONSE) to be
> sent in 0-RTT frames, then?  (This might dupe a comment later...)
>

https://github.com/quicwg/base-drafts/issues/4625


> Section 9.5
>
>    Similarly, an endpoint MUST NOT reuse a connection ID when sending to
>    more than one destination address.  Due to network changes outside
>    the control of its peer, an endpoint might receive packets from a new
>    source address with the same destination connection ID, in which case
>    it MAY continue to use the current connection ID with the new remote
>    address while still sending from the same local address.
>
> The MAY seems like it may be in conflict with the MUST.
>

https://github.com/quicwg/base-drafts/issues/4630


> Section 10.2.1
>
>    An endpoint's selected connection ID and the QUIC version are
>    sufficient information to identify packets for a closing connection;
>    the endpoint MAY discard all other connection state.  [...]
>
> Are the packet protection keys for outgoing traffic (or the literal
> CONNECTION_CLOSE packet contents) not considered part of "connection
> state"?
>

https://github.com/quicwg/base-drafts/issues/4631


> Section 10.3
>
> Just to check my understanding: it is "safe" for a server to decide that
> it will never use stateless reset and send random values in the
> stateless_reset_token fields that it immediately forgets?  (It would
> then not be able to ever send stateless reset, of course, but AFAICT
> that is the only consequence.  The client still has to track the
> relevant state, and the server has to track
> per-connection-ID-sequence-number state.)  I don't know if that's worth
> mentioning, since the field is otherwise essentially mandatory when
> server connection IDs are in use.
>

https://github.com/quicwg/base-drafts/issues/4632


>                                                                 An
>    endpoint that sends a stateless reset in response to a packet that is
>    43 bytes or shorter SHOULD send a stateless reset that is one byte
>    shorter than the packet it responds to.
>
> (side note) We haven't gotten to the anti-looping stuff in §10.3.3 yet,
> so the "one byte shorter" is a bit out of the blue until we get there.
>

https://github.com/quicwg/base-drafts/issues/4633


> Section 10.3.2
>
> I'm not sure whether it should be here or earlier, but somewhere we
> should motivate this construction as being something that can be
> generated statelessly, e.g., by a server restarting after a crash, based
> only on attributes (e.g., Connection ID) of a received packet from a
> previous connection.  The value is computed in advance and given to the
> peer so that the peer will know what to expect if the stateless reset
> functionality needs to be used, and then generated at runtime by an
> endpoint that has lost state.  The scheme described in the first
> paragraph requires state, and thus is hard to justify describing as a
> stateless reset...
>

https://github.com/quicwg/base-drafts/issues/4635


>    A single static key can be used across all connections to the same
>    endpoint by generating the proof using a second iteration of a
>    preimage-resistant function that takes a static key and the
>    connection ID chosen by the endpoint (see Section 5.1) as input.  [...]
>
> The phrase "second iteration" doesn't seem to be explained at all.
>

https://github.com/quicwg/base-drafts/issues/4636


>    This design relies on the peer always sending a connection ID in its
>    packets so that the endpoint can use the connection ID from a packet
>    to reset the connection.  An endpoint that uses this design MUST
>    either use the same connection ID length for all connections or
>    encode the length of the connection ID such that it can be recovered
>    without state.  In addition, it cannot provide a zero-length
>    connection ID.
>
> (There is a corollary that the length of the connection ID has to be
> enough so that multiple connection IDs can be issued to all potential
> peers cumulatively over the lifetime of the static key, though perhaps
> it's sufficiently obvious so as to go without saying.)
>

https://github.com/quicwg/base-drafts/issues/4637


> Section 12.4
>
> A forward-reference to §19.21 for how extension frames can be used might
> be useful.
>
> Why are PATH_CHALLENGE/PATH_RESPONSE allowed in the 0-RTT packet number
> space?  (Hmm, the prose and table may be inconsistent here, too.  I
> touch some things in my PR but I think not all of them.)  The server
> isn't allowed to send at that level, so it seems that even if a client
> did sent PATH_CHALLENGE in 0-RTT, the PATH_RESPONSE would have to come
> back in 1-RTT.  (And with no challenge to reply to, the client can't
> very well send a PATH_RESPONSE in 0-RTT.)  Also, IIRC, we state
> elsewhere that we require a stable path for the duration of the
> handshake.  Even preferred-address probing can't occur until the client
> has the server's transport parameters, which aren't usable until 1-RTT
> keys are available (even if they may technically be available prior to
> then).
>

https://github.com/quicwg/base-drafts/issues/4638


> Section 13.2.3
>
>    ACK frames SHOULD always acknowledge the most recently received
>    packets, and the more out-of-order the packets are, the more
>    important it is to send an updated ACK frame quickly, [...]
>
> Do we have a strict definition of "out of order" that we adhere to?  I
> didn't see one in [QUIC-RECOVERY] on a quick search, but haven't read it
> in depth yet.
> (TCP RACK used roughly "X is out of order when X has lower sequence
> number than Y and X is received after Y is received", which is what I'll
> use as a mental model until I read otherwise.)
>

https://github.com/quicwg/base-drafts/issues/4639


> Section 13.2.5
>
>    When the measured acknowledgement delay is larger than its
>    max_ack_delay, an endpoint SHOULD report the measured delay.  This
>    information is especially useful during the handshake when delays
>    might be large; see Section 13.2.1.
>
> I'm not sure I understand when this delay would not be reported even in
> the absence of this guidance.  Is the idea that you should specifically
> send an ACK with Largest Acknowledged corresponding to the highly
> delayed packet, even if you could send an ACK with a larger Largest
> Acknowledged (but lower delay)?
>

https://github.com/quicwg/base-drafts/issues/4640


> Section 17
>
> (side note) I don't know that it would be of particular benefit to have
> it explained in the document, but I do find myself curious why there is
> a Fixed Bit.
>

https://github.com/quicwg/base-drafts/issues/4641


> Section 17.2.5
>
> Should we give some guidance on the (minimum) length of the Retry Token
> (possibly in a subsection)?  I am not sure that the "MUST be
> non-zero-length" from §17.2.5.2 is the only guidance we want to give...
>

https://github.com/quicwg/base-drafts/issues/4642


> Section 17.2.5.1
>
>    A server MAY send Retry packets in response to Initial and 0-RTT
>    packets.  A server can either discard or buffer 0-RTT packets that it
>    receives.  A server can send multiple Retry packets as it receives
>    Initial or 0-RTT packets.  A server MUST NOT send more than one Retry
>    packet in response to a single UDP datagram.
>
> When the server sends multiple Retry packets in such a scenario, do the
> Source Connection ID fields need to be different (or the same) across
> all of them?  (Or does it not matter?)
>

https://github.com/quicwg/base-drafts/issues/4643


> Section 17.2.5.2
>
>    Token field to the token provided in the Retry.  The client MUST NOT
>    change the Source Connection ID because the server could include the
>    connection ID as part of its token validation logic; see
>    Section 8.1.4.
>
> It looks like Section 8.1.4 doesn't actually talk specifically about
> connection IDs being bound to the token, just "additional information
> about clients".  Perhaps it should?
>

https://github.com/quicwg/base-drafts/issues/4644


> Section 19.16
>
>    Retiring a connection ID invalidates the stateless reset token
>    associated with that connection ID.
>
> Is it the sending or the ACKing of the frame that effectuates the
> invalidation?
>

https://github.com/quicwg/base-drafts/issues/4645


> Section 19.17
>
> As above, please confirm that the 64-bit nonce is wide enough to support
> the purpose for which it is being used.
>

https://github.com/quicwg/base-drafts/issues/4646


> Section 19.19
>
>    Reason Phrase:  A human-readable explanation for why the connection
>       was closed.  This can be zero length if the sender chooses not to
>       give details beyond the Error Code.  This SHOULD be a UTF-8
>       encoded string [RFC3629].
>
> Does "human-readable" engage BCP 18 and the SHOULD-level requirement for
> carrying information about language?
>

https://github.com/quicwg/base-drafts/issues/4647


> Section 20.1
>
>    TRANSPORT_PARAMETER_ERROR (0x8):  An endpoint received transport
>       parameters that were badly formatted, included an invalid value,
>       was absent even though it is mandatory, was present though it is
>       forbidden, or is otherwise in error.
>
> (nit) maybe some singluar/plural mismatch here, though the RFC Editor
> would probably have a better suggested fix than I could come up with.
>

https://github.com/quicwg/base-drafts/issues/4648


> Section 21
>
> Should we reiterate somewhere that 1-RTT data sent by the server prior
> to handshake completion is being sent to an unauthenticated client?
>

https://github.com/quicwg/base-drafts/issues/4649


> Section 21.1
>
> As was noted by others, the terminology used for the taxonomy of
> attackers is a bit unusual (i.e., divergent from [SEC-CONS]) and
> surprising.  It does seem to be fairly clearly specified, though, so is
> probably not worth trying to change at this point.
>

https://github.com/quicwg/base-drafts/issues/4650


> Section 21.1.1
>
> [Just noting here for visibility that my editorial PR adds some text
> here to emphasize that the peer authentication provided by the TLS
> handshake is a vital property as well.  Clients that do not check TLS
> server certificates against the identity of the endpoint they're
> attempting to contact are not guaranteed secure operation.]
>

https://github.com/quicwg/base-drafts/issues/4651


> Section 21.1.3.1
>
>    *  Split and merge datagrams along packet boundaries
>
> Those packet boundaries are obfuscated by header protection, though,
> right?
>

https://github.com/quicwg/base-drafts/issues/4652


> Section 21.1.3.3
>
>    3.  A limited on-path attacker can cause an idle connection to be
>        deemed lost if the server is the first to resume activity.
>
> Pedantically, if the client resumes activity after the server does, but
> within, say, 2*PTO, I don't think the connection would actually be lost.
> But perhaps I am missing something.
>

https://github.com/quicwg/base-drafts/issues/4653


> Section 21.2
>
>    The Source and Destination Connection ID fields are the primary means
>    of protection against off-path attack during the handshake.  These
>
> Presumably we should then give some guidance on how to generate the
> Connection IDs so that they can fulfill this role effectively.  Though it
> is likely to change significantly as a result of IETF Review,
> draft-gont-numeric-ids-sec-considerations may have some useful advice
> here.  In particular, it seems like they actually do need to be
> unpredictable in order to fulfill this role, and very short Connection
> IDs will not be very effective either.
>

https://github.com/quicwg/base-drafts/issues/4654


> Section 21.3
>
>    Servers SHOULD provide mitigations for this attack by limiting the
>    usage and lifetime of address validation tokens; see Section 8.1.3.
>
> I recognize that it is probably an advanced implementation feature to do
> so, but implementations can also mitigate by detecting elevated rates
> across all connections or some identifiable cateogry of connections, of
> sending responses to 0-RTT data that are declared lost, treating that as
> indication of an ongoing attack, and racheting down the congestion
> window it uses for such data for the duration of the attack.  This in
> theory could improve the stability of the Internet as a whole, which
> would be the motivation for mentioning it in this document as opposed to
> leaving it at the discretion of implementors.
>

https://github.com/quicwg/base-drafts/issues/4655


> Section 21.5
>
>    For example, cross-site request forgery [CSRF] exploits on the Web
>    cause a client to issue requests that include authorization cookies
>    [COOKIE], allowing one site access to information and actions that
>    are intended to be restricted to a different site.
>
> Server-side request forgery is also a powerful example of this type of
> attack.  Though it's not really clear that we need more than one example
> here, so "no change" is okay with me.
>

https://github.com/quicwg/base-drafts/issues/4656


> Section 21.5.2
>
>    Clients however are not obligated to use the NEW_TOKEN frame.
>    Request forgery attacks that rely on the Token field can be avoided
>    if clients send an empty Token field when the server address has
>    changed from when the NEW_TOKEN frame was received.
>
>    Clients could avoid using NEW_TOKEN if the server address changes.
>    However, not including a Token field could adversely affect
>    performance.  Servers could rely on NEW_TOKEN to enable sending of
>    data in excess of the three times limit on sending data; see
>    Section 8.1.  In particular, this affects cases where clients use
>    0-RTT to request data from servers.
>
> This seems to be setting us up to specifically recommend trading away
> security in favor of performance.  Is that the right tradeoff?
> (Also, in the vein of my earlier comment, advanced implementation
> strategies involving detecting the presence of an attack might provide
> global benefit to the Internet, though the case is a bit weaker here
> than it was in the other situation.)
>

https://github.com/quicwg/base-drafts/issues/4657


> Section 21.10
>
>    An on-the-side attacker can duplicate and send packets with modified
>
> This is the only instance of "on-the-side" (or "on the side") in the
> document; I suggest rephrasing to conform to the prevailing terminology.
>

https://github.com/quicwg/base-drafts/issues/4658


> Section 21.11
>
> This would be a good place (or §10.3) to discuss the procedures for
> rotating the static key used by stateless reset, per BCP 107.
>

https://github.com/quicwg/base-drafts/issues/4659


> Section 21.13
>
>                        Ideally, routing decisions are made independently
>    of client-selected values; a Source Connection ID can be selected to
>    route later packets to the same server.
>
> Is the client's address considered to be "client-selected"?  It's not
> clear to me that ignoring IP address locality and routing efficiency is
> going to be the ideal behavior.
>

https://github.com/quicwg/base-drafts/issues/4660


>
> Section 22.1.1
>
> Are there going to be PII concerns with requiring contact information in
> the (public) registry?
>

https://github.com/quicwg/base-drafts/issues/4661


> Section 22.1.2
>
>    Applications to register codepoints in QUIC registries MAY include a
>    codepoint as part of the registration.  IANA MUST allocate the
>    selected codepoint if the codepoint is unassigned and the
>    requirements of the registration policy are met.
>
> Is this intended to preclude the experts from requiring an allocation to
> be made from a range with a different-length encoding?
>

https://github.com/quicwg/base-drafts/issues/4662


> Section 22.1.4
>
> Should we require an expectation that the publicly available
> specification is going to be stable and/or continue to be accessible, as
> a condition of a permanent registration?
>

https://github.com/quicwg/base-drafts/issues/4663


> Section 23.1
>
> I think RFC 4086 is typically listed only as an Informative reference.
>
> It is amusing that IPv4 is a normative reference but IPv6 only
> informative.  (Given how they are referenced, I don't fault this
> categorization.)
>

https://github.com/quicwg/base-drafts/issues/4664


> Section 23.2
>
> Should [QUIC-INVARIANTS] also be required reading?
>

https://github.com/quicwg/base-drafts/issues/4665

Cheers,
Lucas
On behalf of QUIC WG Chairs