Re: Consensus Calls for Transport/TLS issues, post-Cupertino

[Christian Huitema <[e-mail]>]

On 10/30/2019 5:54 PM, Martin Thomson wrote:
> On Thu, Oct 31, 2019, at 08:21, Eric Rescorla wrote:
>> On Wed, Oct 30, 2019 at 2:06 PM Mikkel Fahnøe Jørgensen 
>> <[e-mail]> wrote:
>>>> I'm going to stop here, because it seems that you're assuming we don't just keep the keys indefinitely. How does that lead to deadlock?
>>> The problem is that having keys indefinitely leads to various problems.
>> I've heard that asserted but I'm not so sure.
> The problems I'm aware of are largely edifices of our own construction.
>
> The primary one I am aware of is that we don't know what to do about sending Handshake packets after a migration.  This is fixable, because it is a definitional problem.  We haven't defined what to do.  The problem is, I think just limited to the use of Source Connection ID on long header packets.  I personally would prefer not to have to fix this one.
>
> If you don't continue sending Handshake packets, that has the same effect as discarding keys for the side that is being starved of acknowledgments.

There is the half-way step of only sending acknowledgements, only upon
receipt of new Handshake packets.

> We could also build, as Mike alludes to, an implicit acknowledgment.  We currently have one for the Initial->Handshake transition and we could build another.  That only reduces this from a symmetric issue to an asymmetric one unless we address the existing problem.

I would assume that implementations, in practice, will consider implicit
acknowledgements. This is fairly obvious on the server side: receiving
the "handshake complete" from the stack means that all required
handshake packets have been received by both parties. The server knows
that there is no point in re-transmitting any of the previous handshake
packets. It can implement the "implicit ack" logic without breaking
anything on the server side. I assume that implementations will just do
that, no matter what the Quic spec says, because it makes the server
stack robust to silly scenario in which the client's acks of handshake
packets get lost. Which means that the Quic spec might just as well say it.

So the problem really is asymmetric. The client is fine, because it
eventually receives an ACK of its final handshake packet can can
consider the handshake confirmed at that point. But the server never
knows whether the ack of the final handshake was properly received.

> If we were able to reduce this to just a client-side problem, then we might also say that clients can't migrate prior to verifying that all Handshake data was transmitted to as to avoid any need for problems.  Then migration becomes proof positive that the client is done transmitting and that can be the signal.

Migration is only initiated by the client in V1, so waiting for the last
handshake ACK on the client side is good enough. But key rotation could
be initiated by the server, and doing that before handshake confirmed is
a bit problematic. Which means that the server needs to know whether the
client's handshake is confirmed, which is where the Handshake Done
signal becomes useful. My preference would be for the server to send
that signal and repeat it until it is acknowledged by the client. When
that ACK is received, the server knows that the handshake is confirmed.

-- Christian Huitema