Subject: Re: [quicwg/base-drafts] Consider simplifying Packet Number Encryption (#1575)

From: Mark Nottingham <[email-masked]>
Date: Wed, 19 Sep 2018 17:10:18 +0000 (UTC)

Discussed in NYC; @ekr to follow up with @DavidSchinazi within two weeks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-422883263

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Sep 2018 17:12:49 +0000 (UTC)

I prefer the current approach.

IIUC, the proposal is to have a conditional branch that tests if the sum of PN length and payload is below 20 octets, then create a zero-padded copy for sampling.

I do not think that is simpler than the current approach that uses a conditional branch to determine the sampling offset.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-422884131

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Sep 2018 22:19:54 +0000 (UTC)

I had a conversation with @ekr about this yesterday, and I'm wondering if the following proposal might get us the best of both worlds:
1) Require that QUIC packets MUST verify `length(packet number) + length(payload) >= 4`, by padding the payload if needed.
2) Always have PNE encrypt 4 bytes from the start of the packet number, and use the following 16 bytes as nonce.

In practice the padding overhead here is very low as it only impacts a small number of frame types when sent without an ACK frame. (Worse case scenario is a lonely PING frame with packet number below 63, and that case suffers 2 bytes of padding out of a 20+8+1+1+1=31 byte IPv4 packet)

It also has the nice property of obfuscating the packet-number length, as an observer can no longer tell when the packet number is below 63.

In terms of implementation, this is simplest for decryption, and the padding can be added right before encrypting the payload as that code needs to have access to the packet number as nonce anyway.

What are people's thoughts on this?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-424144509

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 17:13:48 +0000 (UTC)

That sounds good.  We can stipulate that a packet MUST always contain at least 3 octets of frames.  Adding a couple of padding octets is probably a good idea.

Note that we're probably changing the encoding of packet numbers (again, yeah, sorry), so the precise set of 

Not sure whether you mean that you always XOR 4 octets (which means XOR over the encrypted payload if the packet number is <4), or whether you only XOR the octets of the packet number.  With the proposed move of the packet number length to the first octet, it's probably better to only XOR the octets of the packet number.  That way you don't touch the payload octets other than to sample them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-424424893

---

From: David Schinazi <[email-masked]>
Date: Sat, 29 Sep 2018 10:38:05 -0700

I think requiring 3 octets of frames is more restrictive that we need to be. I would prefer saying that QUIC packets MUST verify `length(packet number) + length(payload) >= 4`, and if implementors want to do that by always ensuring 3 bytes of frames that's fine.

I meant that we XOR over the payload if the packet number length is < 4. When we're encrypting the PN, I'm not sure the distinction between PN and payload is relevant - there's nothing wrong with changing the start of the payload in my mind. And it simplifies the implementation.

But we can put this on hold until we've landed on what the PN encoding looks like.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-425662595