Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify server CONNECTION_CLOSE with Handshake #2688

Merged
merged 14 commits into from Jun 18, 2019
Merged

Clarify server CONNECTION_CLOSE with Handshake #2688

Changes from 1 commit
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
9582787
Clarify server CONNECTION_CLOSE with Handshake
ianswett May 10, 2019
9bcc7fa
Update draft-ietf-quic-transport.md
ianswett May 10, 2019
ead6736
Update draft-ietf-quic-transport.md
ianswett May 10, 2019
96c8913
Update draft-ietf-quic-transport.md
ianswett May 13, 2019
e70eff7
Update draft-ietf-quic-transport.md
ianswett May 13, 2019
cfa8de6
Update draft-ietf-quic-transport.md
ianswett May 14, 2019
ab282cd
Update draft-ietf-quic-transport.md
ianswett May 14, 2019
1bb9ef0
Update draft-ietf-quic-transport.md
ianswett May 15, 2019
4079e66
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
9dfb614
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
4029df2
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
68d1c8b
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
b669d0f
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
ce74eec
Update draft-ietf-quic-transport.md
ianswett Jun 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 6 additions & 6 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2307,14 +2307,14 @@ signal closure.
If the connection has been successfully established, endpoints MUST send any
ianswett marked this conversation as resolved.
Show resolved Hide resolved
CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a
peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
in a Handshake packet. If the endpoint does not have Handshake keys, it MAY
in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD
send CONNECTION_CLOSE frames in an Initial packet.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be only a statement of fact that describes the exception to the preceding SHOULD. "If the endpoint does not have Handshake keys, it sends CONNECTION_CLOSE frames in an Initial packet"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused why we have a MUST and a SHOULD for the other two cases, but you're advising no normative text for the Initial case? Am I missing something?


The server can have Handshake keys but not know that the client has Handshake
keys. In order to guarantee a CONNECTION_CLOSE is processed, it has to send
a CONNECTION_CLOSE in both Handshake and Initial, because the client discards
Initial keys as soon as it has Handshake keys. If multiple packets are sent,
they can be coalesced (see {{packet-coalesce}}) to facilitate retransmission.
The server may not know whether the client has Handshake keys. In order to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The server may not know whether the client has Handshake keys. In order to
It is possible that an endpoint does not know whether the peer has Handshake keys. In order to

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fairly sure server to client is the only case two connection closes may need to be sent, which is why it's written with server an client.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That assumes a lot about the shape of the handshake though. If you are going to make that call, cite QUIC-TLS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have in mind 17.2.2.1 in Transport: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-17.2.2.1

"A client stops both sending and processing Initial packets when it sends its first Handshake packet."

This clearly indicates that a client will almost never be processing Initial and Handshake packets at once, so if you only send one connection close, some clients will drop it. In all other cases with #2673 landed, the client and server should both still have Handshake keys even if they also have 1-RTT keys?

Is there something about TLS I'm implicitly assuming as well? I can imagine I am, but I don't know what it is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, the two docs blur together in my mind. This is OK. I would suggest that you need to address both transitions here though. The transition to Handshake and the transition to 1-RTT have the same sort of uncertainty.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The handshake to 1-RTT transition has an overlap where the peer has both sets of keys, unlike Initial to Handshake, so I think using handshake confirmed as the signal here provides what we want?

ianswett marked this conversation as resolved.
Show resolved Hide resolved
guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The server can't guarantee this. (see proposed text below)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A server can't guarantee the packet arrives, but I think sending both guarantees that if it does arrive at the client, the client can be decrypted. Am I missing something?

in both Handshake and Initial, because the client discards Initial keys as soon
as it has Handshake keys. If multiple packets are sent, they can be coalesced
(see {{packet-coalesce}}).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested rewording of text after the first sentence:
"Under these circumstances, an endpoint SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to increase the likelihood of a CONNECTION_CLOSE frame being processed by the peer. These packets can be coalesced into a single UDP datagram (see {{packet-coalesce}})."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bigger point here is that the server also isn't sure when the client gets 1-RTT keys. We should say the same about that transition. I believe that we can rely on handshake confirmation for this transition. Endpoints might choose to send CONNECTION_CLOSE in Handshake packets prior to the handshake being confirmed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, another spot we're relying on #2673?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the text about sending 1-RTT connection closes to use Handshake confirmed, which lines up with #2673. I think that's a good fix?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't sound so uncertain :) I think that the fix is good.

And we'd (collectively) be crazy if we didn't take #2673.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd also individually go crazy if we don't take it. 😉

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Under these circumstances, a server SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client. These packets can be coalesced into a single UDP datagram (see {{packet-coalesce}})."



## Stateless Reset {#stateless-reset}
Expand Down