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

[ekr <[e-mail]>]

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