Subject: [quicwg/base-drafts] Payload length in header encrypted with sequence number (#1293)

From: Christian Huitema <[email-masked]>
Date: Sat, 14 Apr 2018 00:52:17 +0000 (UTC)

There is an interesting feature interaction between PN encryption and the encoding of the payload length in the header.

The current specification of PN encryption (PR #1079) specifies encrypting the 16 byte field starting at the offset of the packet number. The current specification of the long header places the payload length *after* the packet number. So the payload length gets encrypted with the packet number. And that's a royal pain, because that means the payload length cannot be assessed before decrypting the packet number.

-- 
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/1293

---

From: Christian Huitema <[email-masked]>
Date: Fri, 13 Apr 2018 18:30:47 -0700

See PR  #1294.

-- 
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/1293#issuecomment-381294257

---

From: Mike Bishop <[email-masked]>
Date: Sun, 15 Apr 2018 16:54:15 +0000 (UTC)

I believe this is incorrect.  In the long headers, the length of the packet number is always a fixed 32-bit field, so you can always find the payload length without decrypting this fixed-size field.  I can't find anything in the PNE PR which says you should encrypt a larger region than the packet number field itself; line number?

Now, the PR doesn't account for compound packets in that it assumes the encrypted payload to begin immediately after the packet number for sampling purposes, but that's a minor fix to #1079.

-- 
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/1293#issuecomment-381420963

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Apr 2018 17:57:47 +0000 (UTC)

The problem is that #1079 is ambiguous. Yes, this could be fixed by making it crystal-clear that only the 4 bytes of the packet number are encrypted in a long header, and only the 4 bytes starting at the packet number offset in a short header. But then, please fix it!

-- 
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/1293#issuecomment-381425190

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Apr 2018 20:03:14 +0000 (UTC)

OK. I fixed my implementation of PNE to only encrypt 4 bytes following the PN offset, and all the tests are now passing. I still have a small doubt about the logic. Is PNE supposed to be tied to the packet number length for the short header? Is it supposed to encrypt 1, 2 or 4 octets based on actual PN length, or is it fine to just encrypt four bytes?

-- 
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/1293#issuecomment-381433882

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Apr 2018 02:58:27 +0000 (UTC)

Closed #1293.

-- 
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/1293#event-1577724750

---

From: Christian Huitema <[email-masked]>
Date: Mon, 16 Apr 2018 19:58:27 -0700

Closed since #1294 was merged.

-- 
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/1293#issuecomment-381817636