Re: Go Back to Single Packet Number Space

[Eric Rescorla <[e-mail]>]

On Thu, Jul 26, 2018 at 7:04 AM, Nick Banks <
nibanks=[e-mail]> wrote:

> First, I think we should limit the discussion to what actually is in V1.
> Things like post quantum crypto and possible future TLS changes are
> interesting to reason about, but should have no immediate bearing on the
> design right now. If things change in the future that might cause
> additional issues, we should handle them in a future version.
>
>
>
> Second, on the topic of only acknowledging packets at a greater than or
> equal encryption level being even harder or less efficient to implement,
> while I whole-heartedly disagree, I was thinking about this, and feel we
> could actually go one step further. Already I have proposed disallowing
> ACKs in Initial packets and allowing 0-RTT packets to be acknowledged in
> Handshake packets. We could instead just say no ACKs in Initial packets,
> but all other packets can acknowledge any other packet.
>

This seems like a lot of special casing.


No encryption level requirements at all. The obvious possible point of
> contention with this, is that it would allow Handshake packets to
> acknowledge 1-RTT packets. While it is a ‘lower’ encryption level (I don’t
> really know what that means) both Handshake and 1-RTT keys are keys only
> the endpoints know. I don’t see any harm in temporarily (as long as you
> accept Handshake packets) allowing Handshake packets to acknowledge 1-RTT
> packets. With this design, an implementation that needs to acknowledge
> something can then do whatever it likes, so long as it doesn’t use an
> Initial packets.
>

This does not match the analytic framework established for TLS 1.3, which
explicitly includes key separation between handshake and traffic keys. This
was very important when we did the protocol analysis, so I would not be in
favor of this change.

-Ekr




> Next, for not explicitly sending ACK frames in Initial packets, I
> personally don’t see the explicit event of TLS changing read encryption
> keys from initial to handshake as an implicit signal. To me, it seems very
> reasonable to call that out as the explicit signal to treat your initial
> packet(s?) as acknowledged.
>



>
> - Nick
>
>
>
> *From:* Patrick McManus <[e-mail]>
> *Sent:* Thursday, July 26, 2018 5:15 AM
> *To:* Kazuho Oku <[e-mail]>
> *Cc:* Martin Thomson <[e-mail]>; Nick Banks <
> [e-mail]>; QUIC WG <[e-mail]>
> *Subject:* Re: Go Back to Single Packet Number Space
>
>
>
>
>
>
>
> On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku <[e-mail]> wrote:
>
> 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 sums up my feelings as well - I really like the explicitness of the
> separate spaces.
>