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

[Jana Iyengar <[e-mail]>]

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