Re: [quicwg/base-drafts] A day in the life (#3225)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.

Perhaps also some discussion on termination - silent idle timeout vs connection close, and risk of loss of close packet.

> -required here.
-
-suggested structure:
-
- - establishment
-   - VN
-   - Retry
-   - Crypto
- - use (include migration)
- - shutdown
-
--->
+A QUIC connection is a stateful interaction between a client and server, the
+primary purpose of which is to support the exchange of data by an application
+protocol.  Streams ({{streams}}) are the primary means by which an application
+protocol exchanges information.

That is not necessarily the case with DATAGRAM extension.

> -   - VN
-   - Retry
-   - Crypto
- - use (include migration)
- - shutdown
-
--->
+A QUIC connection is a stateful interaction between a client and server, the
+primary purpose of which is to support the exchange of data by an application
+protocol.  Streams ({{streams}}) are the primary means by which an application
+protocol exchanges information.
+
+Each connection starts with a handshake phase, during which client and server
+establish a shared secret using the cryptographic handshake protocol
+{{QUIC-TLS}} and negotiate the application protocol.  The handshake
+({{handshake}}) confirms that endpoints are willing to communicate

```suggestion
({{handshake}}) confirms that both endpoints are willing to communicate
```

> +Each connection starts with a handshake phase, during which client and server
+establish a shared secret using the cryptographic handshake protocol
+{{QUIC-TLS}} and negotiate the application protocol.  The handshake
+({{handshake}}) confirms that endpoints are willing to communicate
+({{validate-handshake}}) and establishes parameters for the connection
+({{transport-parameters}}).
+
+An application protocol can also operate in a limited fashion during the
+handshake phase.  0-RTT allows application messages to be sent by a client
+before receiving any messages from the server.  However, 0-RTT lacks certain key
+security guarantees. In particular, there is no protection against replay
+attacks in 0-RTT; see {{QUIC-TLS}}.  Separately, a server can also send
+application data to a client before it receives the final cryptographic
+handshake messages that allow it to confirm the identity and liveness of the
+client.  These capabilities allow an application protocol to offer the option to
+trade some security guarantees for improved latency.

```suggestion
trade some security guarantees for reduced latency.
```

... or to buffer packets until the handshake is confirmed.

> +({{transport-parameters}}).
+
+An application protocol can also operate in a limited fashion during the
+handshake phase.  0-RTT allows application messages to be sent by a client
+before receiving any messages from the server.  However, 0-RTT lacks certain key
+security guarantees. In particular, there is no protection against replay
+attacks in 0-RTT; see {{QUIC-TLS}}.  Separately, a server can also send
+application data to a client before it receives the final cryptographic
+handshake messages that allow it to confirm the identity and liveness of the
+client.  These capabilities allow an application protocol to offer the option to
+trade some security guarantees for improved latency.
+
+The use of connection IDs ({{connection-id}}) allows connections to migrate to a
+new network path, both as a direct choice of an endpoint and when forced by a
+change in a middlebox.  {{migration}} describes how a migration can be performed
+securely without adversely affecting privacy.

That is a strong claim. "... with as little impact on privacy as practically possible" would be more precise.

-- 
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/pull/3225#pullrequestreview-315530990