Re: [quicwg/base-drafts] Stronger migration handshake (#2370)

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.

A few comments

> +### Handshake Completion {#handshake-completion}
+
+The connection establishment handshake concludes when both parties have
+successfully agreed on the protocol version and on encryption keys, and
+have obtained insurance that all necessary Initial and Handshake messages
+have been properly received by their peers, as defined in {{QUIC-TLS}}.
+
+For the server, this is achieved when the TLS stack informs the
+transport that the session establishment is complete, and that the
+1-RTT receive keys can now be used, as indicated in section 4.1.3 of
+{{QUIC-TLS}}.
+
+For the client, this is achieved after the 1-RTT keys become available 
+when the server acknowledges either the client's Handshake message carrying
+the last element of the Crypto Stream or an 1-RTT message sent by the client.
+Waiting for either of these events allows the client to verify the

```suggestion
Waiting for either of these events allows the client to verify that
```

> +
+The connection establishment handshake concludes when both parties have
+successfully agreed on the protocol version and on encryption keys, and
+have obtained insurance that all necessary Initial and Handshake messages
+have been properly received by their peers, as defined in {{QUIC-TLS}}.
+
+For the server, this is achieved when the TLS stack informs the
+transport that the session establishment is complete, and that the
+1-RTT receive keys can now be used, as indicated in section 4.1.3 of
+{{QUIC-TLS}}.
+
+For the client, this is achieved after the 1-RTT keys become available 
+when the server acknowledges either the client's Handshake message carrying
+the last element of the Crypto Stream or an 1-RTT message sent by the client.
+Waiting for either of these events allows the client to verify the
+completion of the handshake even in cases where the Handshake

```suggestion
the handshake is complete, even in cases where acknowledgements for
```

> +The connection establishment handshake concludes when both parties have
+successfully agreed on the protocol version and on encryption keys, and
+have obtained insurance that all necessary Initial and Handshake messages
+have been properly received by their peers, as defined in {{QUIC-TLS}}.
+
+For the server, this is achieved when the TLS stack informs the
+transport that the session establishment is complete, and that the
+1-RTT receive keys can now be used, as indicated in section 4.1.3 of
+{{QUIC-TLS}}.
+
+For the client, this is achieved after the 1-RTT keys become available 
+when the server acknowledges either the client's Handshake message carrying
+the last element of the Crypto Stream or an 1-RTT message sent by the client.
+Waiting for either of these events allows the client to verify the
+completion of the handshake even in cases where the Handshake
+acknowledgement is lost.

```suggestion
Handshake packets are lost.
```

> @@ -1532,6 +1532,24 @@ be unambiguously different to ensure no confusion about their interpretation.
 One way that a new format could be introduced is to define a TLS extension with
 a different codepoint.
 
+### Handshake Completion {#handshake-completion}
+
+The connection establishment handshake concludes when both parties have

I don't agree with some of this text, but importantly, it's more than is needed. Suggested rephrase of this paragraph, and combine this with the next paragraph: "Connection handshake is complete when version negotiation is complete and 1-RTT keys are available at both endpoints."

> @@ -1532,6 +1532,24 @@ be unambiguously different to ensure no confusion about their interpretation.
 One way that a new format could be introduced is to define a TLS extension with
 a different codepoint.
 
+### Handshake Completion {#handshake-completion}
+
+The connection establishment handshake concludes when both parties have
+successfully agreed on the protocol version and on encryption keys, and
+have obtained insurance that all necessary Initial and Handshake messages
+have been properly received by their peers, as defined in {{QUIC-TLS}}.
+
+For the server, this is achieved when the TLS stack informs the
+transport that the session establishment is complete, and that the
+1-RTT receive keys can now be used, as indicated in section 4.1.3 of
+{{QUIC-TLS}}.
+
+For the client, this is achieved after the 1-RTT keys become available 
+when the server acknowledges either the client's Handshake message carrying

Replace "the server acknowledges ... by the client" with "either all Handshake packets or a 1-RTT packet sent by the client are acknowledged"

-- 
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/2370#pullrequestreview-198395293