Re: Go Back to Single Packet Number Space

[Tommy Pauly <[e-mail]>]

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]> 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&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sdata=fstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=0>
> > 
>