RE: Go Back to Single Packet Number Space

[Nick Banks <[e-mail]>]

Sorry for the lack of immediate follow up here. I was on vacation. I’d like to summarize what I see as the current arguments against my proposal with my counters:


  1.  Multiple packet number spaces make it easier, theoretically, to reason about the security properties for the packets.
     *   I’d argue that the security properties should be reasoned in terms of the packet’s encryption level/epoch and leave packet number spaces out of it completely. In those terms, the only difference my design has is that an acknowledgement can also be sent in a higher encryption level.
  2.  Folks have an uneasiness (and see it as a hack) about allowing for ACK frames to be sent in greater than or equal encryption level.
     *   Personally, I don’t see this as a hack at all. To me, it seems reasonable and intuitive to always use the more secure mechanism to acknowledge the information you have received so far.
  3.  A single packet number space may pose problems with the client’s second flight (if the Handshake packet is lost).
     *   In the multiple packet space, if the client coalesces the Initial packet with the ACK frame with their Handshake packet with the CRYPTO frame, you have exactly the same issue. The server ends up with an RTO and retransmits.
  4.  There are issues related to the security analysis if Handshake packets are allowed to acknowledge 1-RTT packets.
     *   I’d like more explanation on exactly what the issue is here. Did previous analysis explicitly show that something like this would be a problem, or has there just not been any analysis for something like this? My understanding is that the Handshake keys give you trust enough to know you are talking with whoever you started the conversation with, but they aren’t authenticated to be who they claim they are yet. Why would that level of trust not be acceptable to acknowledge a received packet?

To summarize my claimed pros for a single packet number space:


  1.  There is less state (memory) to manage on both the sender and receiver side.
  2.  There is less logic required for building packets to acknowledge all the currently received packets.
     *   I don’t believe an implementation would need to support sending coalesced packets to have an efficient handshake.
  3.  Cross encryption level loss recovery is easier to reason about and implement.
  4.  A single set of packet numbers is easier to reason about and debug.
  5.  Saves bytes on the wire.
     *   1 ACK frame for the server’s first flight.
     *   1 long header packet and ACK frame for the client’s second flight.

In general, I still believe the single packet number space far superior to the multiple packet space design. I feel it has a lot of tangible benefits over the multiple packet space design.

- Nick

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________
From: [e-mail] <[e-mail]> on behalf of Tommy Pauly <[e-mail]>
Sent: Thursday, July 26, 2018 9:09:24 AM
To: Nick Banks
Cc: Dmitri Tikhonov; [e-mail]; Martin Thomson
Subject: Re: Go Back to Single Packet Number Space

First off, I'd like to +1 to the points Kazuho made, as I think he did a very good job of expressing the concern I have.

To elaborate on the point about separation of spaces making things easier to reason about:

While the table below does indicate that there are 4 different encryption levels/sets of keys, there can and should be a connection between the 0-RTT and 1-RTT spaces.

| Packet Type     | Encryption Level | PN Space  |
|:----------------|:-----------------|:----------|
| Initial         | Initial secrets  | Initial   |
| 0-RTT Protected | 0-RTT            | 0/1-RTT   |
| Handshake       | Handshake        | Handshake |
| Retry           | N/A              | N/A       |
| Short Header    | 1-RTT            | 0/1-RTT   |

Effectively, there are three different levels of trust at play, which determine the type of frame content that may be sent:
- For Initial packets, there is no established trust at all
- For Handshake packets, there is only the established trust that the peers are the same ones that performed the Initial exchange; at this point it is safe to perform authentication
- For both 0-RTT and 1-RTT packets, there is the trust that the peers have completed an authenticated handshake; only here is it safe to send application data

These three levels of trust are not specific to TLS, but a common feature of security handshakes.

Separated packet number spaces allows an implementation to very discretely separate its handling of frames and retransmissions between the three levels of trust. The architecture that this promotes is one that (I hope) is less likely to have bugs in which frames that must only be sent in higher levels of trust are sent in lower levels.

Thanks,
Tommy

On Jul 25, 2018, at 9:37 PM, Nick Banks <nibanks=[e-mail]<mailto:nibanks=[e-mail]>> wrote:

Since there are four encryption levels, the fact that there are only three packet spaces only makes things more confusing IMO.. If your argument is that matching them together makes things easier, then I’d think there should be four packet spaces. I think having all this duplication and separation just adds unnecessary complexity.



Sent from my Windows 10 device
[HxS - 15254 - 16.0.10325.20083]



________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> on behalf of Tommy Pauly <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 25, 2018 9:26:49 PM
To: Dmitri Tikhonov
Cc: Martin Thomson; Nick Banks; QUIC WG
Subject: Re: Go Back to Single Packet Number Space

As another implementer, I also prefer having the split packet spaces. The point isn't necessarily that it's good to have the triple spaces, but rather that it's nice to have the packet number spaces correspond tightly with the packet types and protection. The logic for handling a space can be treated more uniformly in that way, although it does involve potentially more memory to store the state.

Thanks,
Tommy

> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov <[e-mail]<mailto:[e-mail]>> wrote:
>
> On Thu, Jul 26, 2018 at 11:41:48AM +1000, Martin Thomson wrote:
>> The feedback I've heard is that the simplification is subjective.
>> Others have said that a single space would complicate their
>> implementation considerably more.
>
> EKR is one of the "others" [1] -- are there other implementers who
> prefer the triple packet space?
>
>  - Dmitri.
>
> 1. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sdata=fstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&data=02%7C01%7Cnibanks%40microsoft.com%7C38e2ffe83ba6407225a908d5f3122fdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636682181797759761&sdata=7gSr6lvCyd5kS1VgXcXO%2B5GDFAf%2FKyNrK019OWCWKUE%3D&reserved=0>
>