Re: Unrecoverable loss pattern

[Ian Swett <[e-mail]>]

On Thu, Mar 1, 2018 at 7:58 PM Christian Huitema <[e-mail]>
wrote:

> 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?
>
>
I was thinking that you'd designate a different stream as the
post-handshake encrypted crypto stream and stream 0 would become the
unencrypted crypto stream.  Possibly that stream would be subject to flow
control, and we could not subject stream 0 to flow control, which may be
simpler than the current flow control arrangement?  Or possibly that causes
more problems than it solves, since TLS is designed as a single stream.

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