Subject: [quicwg/base-drafts] Including Connection ID in cleartext key derivation (#893)

From: martinduke <[email-masked]>
Date: Thu, 19 Oct 2017 16:42:22 +0000 (UTC)

I apologize for not catching PR#844, but I think including the connection ID in the cleartext key derivation creates some minor problems for not much benefit.

1) I suppose forcing you to derive a different key for each apparently valid CLIENT_INITIAL increases the expense of middleboxes decrypting these packets. However, it also increases the expense for end servers, trusted proxies, etc. with no real increase in security or ossification-resistance.

2) It is possible for implementers to screw up host/network order for connection ID, which will create debug-resistant crypto mismatches.

3) Most importantly, I have to store an additional crypto context in my QUIC PCB. Once I've generated 1-RTT keys, there is an interval where I must prepare to receive three different keys: Cleartext, 0-RTT, and 1-RTT, If I can store the cleartext key on a system-wide per-version basis, then I can use the two spots I need for key renegotiation anyway.

I readily concede that none of these points are showstoppers, but I would like someone to make the case for this added complexity.

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

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Oct 2017 16:57:49 +0000 (UTC)

In response to (3) above, I'd say each QUIC connection context would likely still hold the cleartext key, even if connection ID wasn't an input. You can't assume (at least client side) any individual connections have any shared state with any other connections. For instance, in WinQuic, they do not have any shared state.

For (2), yes this can be an initial minor debug headache, but interop testing in general will always have these headaches, IMO.

As for (1) I believe making the cleartext encrypted based on the Client's initial connection ID does solve some problems around a particular scenario that @huitema brought up related to immediately creating a new connection after a previous one was cancelled. It allows for you to ignore received handshake packets from the initial connection. So it does have some value, just not necessarily security.

-- 
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/893#issuecomment-337971165

---

From: martinduke <[email-masked]>
Date: Thu, 19 Oct 2017 17:09:40 +0000 (UTC)

While some implementations might not have shared state, it would certainly be valuable for server implementations that do have it to only have to compute the cleartext key once when loading the config, instead of for every incoming CLIENT_INITIAL.

I guess I don't understand @huitema's case. The keys are only different if the connection IDs are different, and if the connection IDs are different that's sufficient to distinguish the attempts.

-- 
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/893#issuecomment-337974363

---

From: MikkelFJ <[email-masked]>
Date: Fri, 20 Oct 2017 16:08:53 +0000 (UTC)

I believe there are only two overheads in creating a new temporary initial key for handshake:

1. create randomness, compute AES key context, and compute the GCM hash.
2. allocate and deallocate memory for the context space for the context.

I don't have any numbers for the cost of the key setup. I would actually be interested in hearing what the cost is. But it is surely a lot faster than Diffie Helman key exchanges.

So, on the surface there might be something to be gained. But it comes at a cost in complexity:

A reusable initial key must be reference counted and protected against overuse wrt. safety limits, and indexed and cached per endpoint. The key must be regoniated with the endpoint somehow and the negotation should be safe against certain attacks. It must be verified that protection against off path attacks on the handshake remains effective. The key endpoint cache will consume space that is possibly irrelevant, for example for an endpoint the only connects once to many different peers. When the cache expires, a new key must be obtained somehow.

-- 
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/893#issuecomment-338249331

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 Oct 2017 17:52:47 +0000 (UTC)

@martinduke wrote:
> I guess I don't understand @huitema's case. The keys are only different if the connection IDs are
> different, and if the connection IDs are different that's sufficient to distinguish the attempts.

When the first Server Clear Text messages arrives, it carries no reference to the initial connection ID chosen by the client. There is thus no way to distinguish between the response to the latest Client Initial and a repeat of a Server Clear Text from a previous connection attempt. Same IP addresses, same ports, no clue.

If the key depends on the connection ID, you ensure that the client will drop messages that are not relevant to the connection, thus solving the problem of spurious repeat of Server Clear Text messages.

-- 
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/893#issuecomment-338277944

---

From: martinduke <[email-masked]>
Date: Fri, 20 Oct 2017 13:02:00 -0700

Closed #893.

-- 
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/893#event-1303679717

---

From: martinduke <[email-masked]>
Date: Fri, 20 Oct 2017 20:09:21 +0000 (UTC)

Alright, this might not be how I would design SCID, but this decision makes sense in that context. Closing the issue.

-- 
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/893#issuecomment-338308485