Subject: [quicwg/base-drafts] Long header + token and PNE (#1535)

From: Christian Huitema <[email-masked]>
Date: Sat, 07 Jul 2018 18:27:44 -0700

Draft-13 says:
```
The Initial packet has two additional header fields that follow the
normal Long Header.
```
But of course, this means that the variable length token length follows the variable length PN, which is encrypted. I guess the editors wanted to make the header parsing code more interesting. It certainly will not help load balancers, firewalls, etc., which may want to parse the tokens during DDOS defense.

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 07 Jul 2018 21:20:46 -0700

Here is what I understand so far:

• Initial packet starts with long header, included encrypted PNE;

• Continues with varint length + retry token;

• Then encrypted payload.

The encryption is done before PNE, as usual.

The "nonce" used for PNE starts at (index of PNE)+4. This may well fall inside the retry token. Do we even care?

The "authenticated" data for AEAD covers the long header and the retry token. Or is it just the long header?

-- 
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/1535#issuecomment-403261225

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 14 Jul 2018 14:06:10 -0700

My interpretation of -3 will be that token_len and token are placed _after_ the payload, because payload is defined as the last element of the long header. But that means that -13 is impossible to implement, because the length of the payload can’t be determined without parsing the token_len field that follows the payload.

Anyways my understanding is that the correct definition is to place token and token_len right before the encrypted pn field.

-- 
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/1535#issuecomment-405049878

---

From: Christian Huitema <[email-masked]>
Date: Sat, 14 Jul 2018 14:22:23 -0700

> On Jul 14, 2018, at 2:06 PM, Kazuho Oku <[email-masked]> wrote:
> 
> My interpretation of -3 will be that token_len and token are placed after the payload, because payload is defined as the last element of the long header. But that means that -13 is impossible to implement, because the length of the payload can’t be determined without parsing the token_len field that follows the payload.
> 

Impossible is a big word. I did actually implement it. But it is ugly and unnecessarily complicated.
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.

-- 
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/1535#issuecomment-405050704

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 15 Jul 2018 00:00:17 -0700

@huitema To clarify, my interpretation of -13 (explained above) is different from your interpretation that is described as "this means that the variable length token length follows the variable length PN". #1567 to avoid that confusion.

-- 
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/1535#issuecomment-405071809

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 22:13:14 -0700

Closed #1535 via e3756579b43c43b002afa71ce5818341ec5c114b.

-- 
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/1535#event-1761807202