Subject: [quicwg/base-drafts] Encrypting token in Retry packet (#3477)

From: Quoc-Viet Nguyen <[email-masked]>
Date: Sat, 22 Feb 2020 15:12:23 -0800

I have read through https://github.com/quicwg/base-drafts/pull/3120 and related issues (https://github.com/quicwg/base-drafts/issues/3274 https://github.com/quicwg/base-drafts/issues/3014)
and wonder if we can have it similar to Initial Packet encryption instead. I understand we already have consensus but wonder if we can make the protocol simpler.

In initial packet, the initial AEAD is calculated from Destination CID. So I propose we remove pseudo-packet concept and build AEAD from Original Destination CID to encrypt the retry token just like Initial packet encrypting its token, packet number and payload.

I see the benefits are:
- Consistent packet encryption mechanism, more code resuse (please)
- No additional buffer to build pseudo-packet
- Easier to have custom protocol (or next version) to use chosen AEAD, i.e. CHACHA20_POLY1305
- Can apply to other packets in future (e.g Version Negotiation)

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Feb 2020 15:47:56 -0800

This idea was discussed and dismissed.  The problem here is that the HKDF application required to get the keys is significantly more expensive than applying the AEAD.  The cost of producing a Retry was considered important enough not to take this cost.

The pseudo-packet is relatively inexpensive in practice.  Allocating an extra 21 bytes and pre-filling the connection ID in that space doesn't end up costing that much.

-- 
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/3477#issuecomment-590009756

---

From: Quoc-Viet Nguyen <[email-masked]>
Date: Sun, 23 Feb 2020 00:00:25 -0800

If HKDF-Expand-Label is expensive, can we use ODCID such as first 128 bit as the secret key and the remain as the nonce? Or can we generalize it and say SHA256 of user data (ODCID in this case) will be AEAD key and nonce?

WRT pseudo packet. I think on client side, I still need to allocate memory for a copy of received retry packet plus odcid to verify the integrity tag.

-- 
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/3477#issuecomment-590037541

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Feb 2020 15:53:31 -0800

Those options were also suggested.  I think that the extra AES operation (or operations) was regarded as "too expensive".

If you pull incoming packets into a buffer starting at position 21, you can pre-fill the extra stuff.  It's not great, but it can work.

-- 
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/3477#issuecomment-590131711

---

From: ianswett <[email-masked]>
Date: Sun, 23 Feb 2020 17:16:32 -0800

This has been discussed at considerable length as @martinthomson nicely summarized, so I don't see a reason to change the previous consensus now.

-- 
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/3477#issuecomment-590140464

---

From: Lars Eggert <[email-masked]>
Date: Sun, 23 Feb 2020 18:30:25 -0800

Closed #3477.

-- 
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/3477#event-3063942378