[quicwg/base-drafts] Editorial comments (#1376)

[janaiyengar <[e-mail]>]

@gloinul sent a few comments on the transport draft.

A. Section 6.2 says:

A server sends a Version
   Negotiation packet in response to each packet that might initiate a
   new connection, see Section 6.1 for details.

That is not what Section 6.1 says. It says that only if unsupported versions are received and length sufficient SHOULD the server send a version negotiation packet. I guess unknown version of the "version request pattern" is what it should say.

B. Section 6.4.1:

   initial_max_stream_data (0x0000):  <...> This is equivalent
      to an implicit MAX_STREAM_DATA frame (Section 7.7) being sent on
      all streams immediately after opening.

Shouldn't the word "implicit" be removed here?

C. Section 6.7.2

This token can be provided to the cryptographic handshake immediately
   after establishing a connection.

I become very uncertain about this sentence. Is it intended to say that the client provides the server after the connection has been established, which appears strange for a resumption case. Or is the intention to say that the server can provide the client with a resumption token for later use at any point after the current connection has been established?

In general this section is not clear on how the session resumption address validation differs from the client address validation. Does the resumption token arrive to the server as part of the Init TLS handshake? If that is the case, please be explicit.


D. Section 6.9.1

An endpoint uses a new connection ID for probes sent from a new local
   address, see Section 6.9.6 for further discussion.

I think this need to be clearer on that both source and destination may be changed, assuming either part not being zero length.

E. Section 6.9.6:

I find this whole section confusing. It fails to clarify in which order things needs to happen. I might be not understanding this correctly, but I don't see how a peer can migrate and chose a new connection ID unless the this endpoint has previously sent a NEW_CONNECTION_ID frame to that peer. But, when one arrive at this text there is no explanation that this need to happen. Nor appear it specified that this should / must occur at any point in the connection's life time.

F. Section 6.10.2:

   The server SHOULD also initiate path validation of the client using
   its preferred address and the address from which it received the
   client probe.  This helps to guard against spurious migration
   initiated by an attacker.

Doesn't this text also needs considerations around the connection ID to use for those checks?

G. Section 7.15:

   For instance, a server acknowledges a TLS ClientHello in the packet
   that carries the TLS ServerHello; similarly, a client can acknowledge
   a TLS HelloRetryRequest in the packet containing a second TLS
   ClientHello.

This appear to be a contradiction to the earlier, do not acknowledge RETRY packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1376