Subject: [quicwg/base-drafts] Specify AEAD-based protection of cleartext packets (#693)

From: ekr <[email-masked]>
Date: Fri, 21 Jul 2017 08:07:07 +0000 (UTC)

Based on discussion in Prague:

- (Provisionally) algorithm is AES-GCM
- Key should be derived from (1) client connection ID and (2) a fixed key baked into the QUIC version
- Otherwise standard AEAD

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

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jul 2017 01:11:52 -0700

I think this obsoletes #554 

-- 
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/693#issuecomment-316935519

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Jul 2017 03:15:39 -0700

I have no major issue with AES-GCM and the benefit is that it is already there - but please also consider AES-CMAC - it is much lighter and does the job for clear text - and would thus be more version neutral - e.g. implementations are not forced to carry GCM machinery if they want other crypto in a specific version. Notably, middle-boxes would have an easier time.

https://tools.ietf.org/html/rfc4493
https://tools.ietf.org/html/rfc4494

-- 
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/693#issuecomment-316964166

---

From: ekr <[email-masked]>
Date: Fri, 21 Jul 2017 10:24:03 +0000 (UTC)

The rationale for GCM was that Ian wanted to encrypt the plaintext.

-- 
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/693#issuecomment-316965894

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jul 2017 10:47:05 +0000 (UTC)

Yes, I'm worried about the day when QUIC version N+1 wants to support TLS > 1.3 and I don't want to deal with all the old middleboxes that have ossified QUIC==TLS 1.3.

-- 
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/693#issuecomment-316970212

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Jul 2017 10:52:43 +0000 (UTC)

ah I see

-- 
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/693#issuecomment-316971232

---

From: Christian Huitema <[email-masked]>
Date: Sat, 29 Jul 2017 21:40:47 -0700

How does this apply to the Version Negotiation packet?

-- 
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/693#issuecomment-318877966

---

From: ekr <[email-masked]>
Date: Sun, 30 Jul 2017 13:37:56 +0000 (UTC)

I had in mind the same way. You would use the client's version there too

-- 
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/693#issuecomment-318902411

---

From: ekr <[email-masked]>
Date: Sun, 30 Jul 2017 13:38:35 +0000 (UTC)

This is assigned to me, but I'm waiting on doing it until @martinthomson  does some refactoring. Trying to avoid merge conflicts

-- 
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/693#issuecomment-318902450

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Jul 2017 15:50:36 +0000 (UTC)

So for version negotiation, we would have:

1) Client sends an Initial packet with version unknown to server.
2) Server sees only the header and cannot decrypt the content because it does not know the version specific key.
3) Server replies with version negotiation packet, which is not encrypted.

Correct?

-- 
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/693#issuecomment-318910481

---

From: ekr <[email-masked]>
Date: Sun, 30 Jul 2017 23:37:24 +0000 (UTC)

Ian was suggesting that the version-specific key be predictable from the version, so no, you would just decrypt 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/693#issuecomment-318938033

---

From: David Benjamin <[email-masked]>
Date: Sun, 30 Jul 2017 16:40:47 -0700

If it's predictable, won't the middleboxes just derive the key, decrypt it, and then do their usual ossifying thing?

-- 
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/693#issuecomment-318938198

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 30 Jul 2017 23:42:01 +0000 (UTC)

On Sun, Jul 30, 2017 at 4:37 PM, ekr <[email-masked]> wrote:

> Ian was suggesting that the version-specific key be predictable from the
> version, so no, you would just decrypt it.
>
​Decrypt which? The version negotiation packet? The version negotiation
packet has N versions in it, right?

-- 
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/693#issuecomment-318938255

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Jul 2017 17:30:18 -0700

I don't see the point of going to AEAD encryption if the key is entirely predictable from the packet. Doing so would not allow us to replace AES-GCM by something else in the future. It would also be a mere speed bump for ossifying NATs. I would rather stick to FNV1A-64.

I see the point of a key that is specified as part of the document specifying a specific version. That mean that a NAT developer could not decrypt the data for version X without having read the spec for version X. It is not an iron-proof guarantee, because the NAT developers may decide to just read the part of the spec that specifies the key and ignore the other parts. But people who do that can be pointed out as misbehaving. The document that specifies the version would also specify the algorithm, which will allow for evolution. 

But then, that means that servers receiving an packet with the wrong version will only be able to understand the packet 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/693#issuecomment-318941077

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Jul 2017 19:28:39 -0700

The idea here is to make the key (and algorithm) version-specific.  Then you absolutely can't pretend to support a version you don't understand.

The risk, as always, is that NATs latch on to one version and block all other versions.  But that's preferable to the range of subtle and noxious stuff that they might otherwise do.

@ekr, if the server sends a Version Negotiation packet, it can't know which version to choose - the only version it knows that the client supports is one that it doesn't.  If I'm right, then Version Negotiation has to be unencrypted.  I think that for consistency we should define version 0 for this purpose with a fixed algorithm, which might be f(x)=x.

-- 
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/693#issuecomment-318952269

---

From: Christian Huitema <[email-masked]>
Date: Mon, 31 Jul 2017 03:52:06 +0000 (UTC)

@martinthomson, I think we agree. But I don't think we need the version 0 hack. The base spec says that the clear text packets are integrity protected, but it does not mention anything of the kind for the version negotiation packet. The way I read the spec, the version negotiation packets are not protected at all.

This means that the version can be spoofed. But then, the transport parameters repeat the content and results of the renegotiation, and the spoofing will be detected. So we are probably fine without any protection.

-- 
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/693#issuecomment-318960940

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Jul 2017 04:08:39 +0000 (UTC)

:)  The only hazard here is what you get when the Version Negotiation is indistinguishable from Internet-noise.  I think that we can and should just decide that we're comfortable with that.

-- 
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/693#issuecomment-318962575

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Jul 2017 21:50:22 -0700

Yes, we should be OK with the "Internet Noise" issue. Version Negotiation is sent to clients. It will only be accepted if the connection ID and Sequence Number match what the client expects. That, and the IP source address and UDP source port...

-- 
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/693#issuecomment-318966887

---

From: ekr <[email-masked]>
Date: Mon, 31 Jul 2017 13:31:03 +0000 (UTC)

There are two objectives here:

1. Preventing off-path attackers from being able to inject packets. AEADing all packets with a key derived from the client CONN_ID does this (regardless of whether or not you mix in some version-specific key). It also doesn't actually matter for this whether you encrypt, but it's convenient because it means no new transform.

2. Preventing middleboxes from trying to read the content of versions they don't know. Having a strong defense against this obviously requires an unpredictable per-version key, but Ian seemed to think there was some value in a predictable key and I'm fine with going along, but i'm also fine not doing this at all.

WRT to the various suggestions made above:
It's important that VN be protected from off-path attackers as well because otherwise attackers can inject it and cause connection failure just as with other packets (remember: all of this is about protecting injection of packets pre-crypto, because we need to have a negotiation protocol that protects against full on-path attackers). Thus, it needs to *also* be tied to the ClientInitial and the whole point of this issue is to do that in a generic way rather than in a per-packet specific way, as @huitema proposes directly above. Hence, the AEAD (or, as I originally proposed, HMAC). So, I don't think it can be unprotected.

I think the right approach here is a variant of @martinthomson's suggestion above.
1. Use a version-specific key label that's unpredictable and baked into the version when it's published. I.e., Key = HKDF(ConnID, version_label)
2. VN always uses some predictable label (say, all 0s)

The impact of this would be that:
1. VN is integrity protected, as expected and you can always send VN
2. Servers which receive packets for versions they totally don't know will send VN even if the packet is actually invalid. this seems acceptable because any attacker can produce valid packets and elicit a VN.

-- 
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/693#issuecomment-319067600

---

From: Christian Huitema <[email-masked]>
Date: Mon, 31 Jul 2017 16:09:29 +0000 (UTC)

Works for me.

-- 
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/693#issuecomment-319117221