Re: [quicwg/base-drafts] Fixed handshake key deadlock issue (#3093)

[Martin Thomson <[e-mail]>]

As we concluded at the meeting, we're going to keep Handshake keys indefinitely.

FWIW, I don't believe that it is possible to find a confirmation step that doesn't involve both peers actively driving the state machine.  Otherwise, peers might not reach the same state within a reasonable time.  This change still has problems (more below) and only adds delay to the confirmed state by making the requirements more complex.

Here's an example of how this fix breaks.  I'm sure that there are more:

![image](https://user-images.githubusercontent.com/67641/67252125-5a26cf80-f4bd-11e9-915c-29e8bb33a7be.png)

<details><summary>web sequence diagram code</summary>
```
title Bad scenario

Client->Server: Initial
Client->Server: 0-RTT (ack-eliciting)
Server->Client: Initial + Handshake
Server->Client: 1-RTT (ACK for 0-RTT)

Client->Server: Handshake
Server-->Client: ACK (lost)

Client->Server: 1-RTT (ack-eliciting + ACK for 0.5-RTT)
Server->Client: 1-RTT (ACK for 1-RTT)
note right of Server
   The server now believes that 
   the handshake is confirmed
end note

note left of Client
   The client isn't confirmed
end note

note over Client,Server
   Considerable time can now elapse
end note

Client->Server: Handshake (retransmission)
note over Server: drop garbage
Client->Server: Handshake (retransmission)
note over Server: drop garbage ...
```
</details>




-- 
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/3093#issuecomment-544760798