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

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

On Wed, Oct 30, 2019, at 10:58, Eric Rescorla wrote:
> On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson <[e-mail]> wrote:
> > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote:
> >  > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson <[e-mail]> wrote:
> >  > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote:
> >  > > > I think we're clearly going to need to spend some time on this. I don't 
> >  > > > think the spec is satisfactory as-is: we should be designing a 
> >  > > > transport that works for all use cases, not just H3. That said, I also 
> >  > > > don't agree that we need an additional explicit signal. We have one, 
> >  > > > it's called "ACK". We should figure out how to make that work.
> >  > > 
> >  > > I think that we've established that ACK doesn't work without something to push it along.
> >  > 
> >  > No, I don't agree with that assessment.
> > 
> >  Well, I'd like some proof. I shared what I believe to be proof earlier. Happy to walk through it again though.
> 
> Yeah, I think that would help. I've gotten a little lost on the list, 
> so maybe you can re-point it out to me.

Let me try restating it more thoroughly:

The problem that Marten identified is a deadlock because one side discards keys at a time that might be significantly in advance of the other.  If the endpoint that retains keys still hasn't received acknowledgments, it enters a deadlock state if it exhausts the congestion window by sending Handshake packets.

(As an aside, David suggested that we might avoid deadlock if the congestion controller didn't create a dependency cycle between 1-RTT and Handshake, but I didn't detect any inclination to do that, nor am I completely confident that attempting to do so would guarantee success.  There's also the problem that Kazuho and Jana identified, which observes that a loose upper bound on convergence time was undesirable if we want to enable migration.)

Both peers can enter this potential deadlock state in different ways, so we need a symmetric solution.  I can draw up what this looks like in converse, but just imagine that the client sends and loses a Handshake ACK that is separate from the Finished.  That side of this could be addressed with implicit acknowledgment for the server, but I don't think we want to go there.

Any signal that is based purely on "organic" traffic (that is stuff that is sent by the application) can produce an asymmetric state where one side receives the signal and the other does not.  If both peers stop sending packets at that point, which "organic" traffic would have to permit, then the keys will be gone on one side and not the other.

In general, frames from an endpoint don't result in any mandatory transport-level action other than an ACK frame.  ACK frames don't elicit acknowledgment and aren't sent again.  PATH_CHALLENGE is the other way to get a transport-level forced response, but that is similar in that PATH_RESPONSE also doesn't require retransmision.  An endpoint that sends a packet can decide not to send another packet.  Thus, any implicit signal we create can only guarantee one-way propagation, which is firmly in two generals territory as Christian points out.

A PATH_CHALLENGE is almost right for this purpose, because it initiates a three-way exchange, but the lack of requirements for retransmission makes it difficult to guarantee that the process terminates.  And that probably requires overloading semantics for the frames in uncomfortable ways.  Forcing either endpoint to repeatedly initiate path validation would be worse than HANDSHAKE_DONE, especially when you consider that the path is already validated by the handshake.

Thus, while we might be able to define a process where each peer can satisfy themselves that their peer is "done", we don't have an "organic" process that we can attach to for roughly synchronizing the times that endpoints reach that conclusion.