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

["Martin Thomson" <[e-mail]>]

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.

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.

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.

Of course, this is all getting increasingly byzantine.