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

[Eric Rescorla <[e-mail]>]

Note that we also can't close 2741 until we resolve 2863.

-Ekr


On Sun, Oct 27, 2019 at 4:01 PM Eric Rescorla <[e-mail]> 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.
> -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
>>>>
>>>>