Re: Unrecoverable loss pattern

[Christian Huitema <[e-mail]>]

On 3/1/2018 11:30 AM, Mikkel Fahnøe Jørgensen wrote:

> I sort of like the idea of closing stream 0 after unencrypted data.
> For that matter, a stream could be burned on every key or path
> migration which could act as a handoff signal. But it is more a path
> thing than a stream thing because ACK timings depend on path and
> encryption state. I’d like to view the handshake as a separate path
> from the encrypted content - also because the initial connection ID
> might be something arbitrarily different from the later connection.

If you do that, what do you use for post handshake TLS messages, such as
new session ticket messages?

>
> Receipt of encrypted data is not necessarily sufficient because a
> server might start to optimistically transmit data soon after the
> initial packet in anticipation of the client accepting its handshake.
> But the server has not established full trust at this point, so
> consequently the client could not use it as an implicit ACK, at least
> not unless the Client Finished message becomes irrelevant.
>
> I think Finished was needed in part because it is a TLS thing that is
> unwise to mess with, and in part because a Client Auth cert could be
> long, but I am really not sure about this. At least there appears to
> be cases where the encryption cannot be trusted before the Finished is
> received.
Yes.

-- Christian Huitema