Re: Go Back to Single Packet Number Space

[Kazuho Oku <[e-mail]>]

I prefer having split packet number spaces, because in addition to
what Martin says, I feel uneasy about allowing a receiver to
acknowledge a packet "in a greater than or equal encryption level."

My understanding is that this the key of the proposal. Use of a
unified packet number space makes sense only when an endpoint can send
an acknowledgement for all packets that it has received in one
encryption level.

This does sound like a nice hack, but I wonder if it might be too
fragile to changes in TLS that might happen in the future.

At the moment, there is one issue, which might be subtle.

Consider the case where the client is sending it's 2nd flight that
consists of a Handshake packet containing ClientFinished (and
optionally Certificate, CertificateVerify), and a 1-RTT packet
containing application data. At this point, the client knows the 1-RTT
write key, and because the server typically sends NST at the same time
it sends ServerFinished using 0.5 RTT data, the client will be
required to send ACK as part of the 1-RTT packet.

This means that if the Handshake packet gets lost, the server will not
be able to process the ACK even if the packet that contained the ACK
reaches the server, because 1-RTT read key on the server-side is yet
to be activated.

I am not sure how important this issue is.

It might cause excessive retransmits from the server than what we
would see in the separate packet number space approach. The fact that
the server will be sending RTO packets while the user selects his /
her certificate using the client-side UI makes me giggle, but it might
not be a big deal.

However, the existence of such issues make me wonder that the proposal
is relying too much on the details of TLS 1.3. And I am not sure if
the issue explained here is the only problem.

Considering the fact that having split packet number space is just
about having an ACK queue for 3 levels, I would prefer retaining
current design rather than implementing a "hack" that could have
corner cases.

2018-07-26 10:41 GMT+09:00 Martin Thomson <[e-mail]>:
> The feedback I've heard is that the simplification is subjective.
> Others have said that a single space would complicate their
> implementation considerably more.  You might want to say more about
> that.
>
> The loss of acknowledgements during the Initial phase has the
> unfortunate effect of forcing implementations to rely on implicit
> acknowledgment.  This doesn't seem like a problem now, but we're close
> to the quantum computer cryptographic apocalypse (put that on a
> sandwich board and yell it on street corners folks!) and this sort of
> reduction in capability could serious impair our ability to ship a key
> exchange that doesn't have problems.
>
> Now, this latter thing is not an unfixable problem if you cared about
> it, but it depends on what your real problem is.
> On Thu, Jul 26, 2018 at 5:29 AM Nick Banks
> <nibanks=[e-mail]> wrote:
>>
>> Hello Folks,
>>
>>
>>
>> I have opened a GitHub Issue (#1579) and Pull Request (#1591) for this topic, but it seems progressed has stalled, so I figured I should take it to the list.
>>
>>
>>
>> While implementing draft-13, I came across a number of pain points related to using multiple packet number spaces. A lot of the issues result in duplicated state (and associated memory) for all the packet number spaces. But more importantly, the multiple packet number spaces bring in a lot more complexity of logic, compared to the previous single packet number space design. There is a lot more detail in the GitHub issue, and I’d ask that folks take a look at it (and the PR) and provide any feedback they might have. I feel that my Issue adequately describes the problem and my PR provides good (if not better, IMO) solutions to the problems that were fixed previously with multiple packet number spaces. I believe having a single packet number space will drastically simplify implementations in the end.
>>
>>
>>
>> Finally, as QUIC V1 (2?) is coming to a close (hopefully) I feel like we should resolve this issue soon. I don’t want this issue to slip out into the next version.
>>
>>
>>
>> Thanks,
>>
>> - Nick
>



-- 
Kazuho Oku