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

[Eric Rescorla <[e-mail]>]

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


On Fri, Oct 25, 2019 at 9:36 AM Martin Duke <[e-mail]> wrote:

> I agree with the dissenters. The current spec works in the HTTP3 use case,
> though I think we should fix it. Keeping keys forever is unsatisfactory for
> several reasons. We should use an explicit signal, and there is no reason
> to kick the can down the road. Let's just leave #2863 open till we resolve
> it.
>
> On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar <[e-mail]> wrote:
>
>> Yup. We need to get this over with in the dumbest way possible.
>>
>> On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop <[e-mail]> wrote:
>>
>>> I think we’ve amply demonstrated that implicit signals don’t work.  I’d
>>> like to see an explicit confirmation of handshake completion that happens
>>> at 1-RTT.
>>>
>>>
>>>
>>> *From:* QUIC <[e-mail]> *On Behalf Of * David Schinazi
>>> *Sent:* Tuesday, October 22, 2019 4:07 PM
>>> *To:* Jana Iyengar <[e-mail]>
>>> *Cc:* Mikkel Fahnøe Jørgensen <[e-mail]>; IETF QUIC WG <
>>> [e-mail]>; Martin Thomson <[e-mail]>; Kazuho Oku <
>>> [e-mail]>
>>> *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino
>>>
>>>
>>>
>>> +1
>>>
>>>
>>>
>>> I think the text we have in the spec today is better than the proposal
>>> to never discard the handshake keys.
>>>
>>> My preference would be to spend the time to fix the issue, and not add a
>>> temporary workaround for now.
>>>
>>>
>>>
>>> On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <[e-mail]>
>>> wrote:
>>>
>>> I agree with Kazuho here. The issue of migration was not one we had
>>> considered. I was going through this with Kazuho, and we may have
>>> identified yet another issue with handshake retransmissions and migration,
>>> which is present in the current spec.
>>>
>>>
>>>
>>> Sadly, I don't think we can call this issue done...
>>>
>>>
>>>
>>> On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahnøe Jørgensen <
>>> [e-mail]> wrote:
>>>
>>> Without a way to move to a single PN space I find this a deal breaker. I
>>> might do a custom version of the protocol.
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> *Fra:* QUIC <[e-mail]> på vegne af Kazuho Oku <
>>> [e-mail]>
>>> *Sendt:* tirsdag, oktober 22, 2019 6:58 AM
>>> *Til:* Martin Thomson
>>> *Cc:* IETF QUIC WG
>>> *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2019年10月22日(火) 11:38 Martin Thomson <[e-mail]>:
>>>
>>> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote:
>>> >  I'd also prefer to fix the problem, even if it means bringing back
>>> > something like RETIRE_KEY.
>>>
>>> I would prefer to think of this proposed resolution as a temporary one.
>>> I don't think that we agreed to keep the handshake keys indefinitely, only
>>> that we would use that option as a fallback position until we found a
>>> better solution.
>>>
>>>
>>>
>>> I might point out that #3121 is not proposal-ready as a way to resolve
>>> #2863. That is because it does not define how to send and receive Handshake
>>> packets until or after migration happens. There would be a deadlock unless
>>> both endpoints agree on how that should be done (e.g., how to select SCID,
>>> whether the path used for Handshake packets migrates too).
>>>
>>>
>>>
>>> Without that being clarified, can we say that we are ready for a
>>> consensus call?
>>>
>>>
>>>
>>>
>>> On that basis, I think that it would be best if we open a new issue that
>>> says "Handshake keys can't ever be dropped".
>>>
>>> We might still conclude not to address that issue, but the important
>>> thing is to ensure that any solution works properly.
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Kazuho Oku
>>>
>>>