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

[Eric Rescorla <[e-mail]>]

On Tue, Oct 29, 2019 at 10:02 PM Martin Thomson <[e-mail]> wrote:

> 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.
>

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?

-Ekr




>