Why not also encrypt the Initial payload? #9
Comments
|
@DavidSchinazi That's possible, and I agree that encrypting entire Client Hello is an attracting idea. However, it's not as easy as it might sound. We need to exchange other parameters as well (e.g., identifier of the server's public key being used (to support key rotation), the cipher-suite being selected, digest of the server-side structure that offered the public key (i.e. ESNI resource record)). It's precisely about defining our own handshake protocol that exchanges a shared secret using anon-DH. I am not sure if we want to do that. GQUIC has had it's own handshake protocol, but in IQUIC we decided to use the handshake protocol of TLS because it is the standard way of building a secure channel. I'd prefer continuing that practice, because then we can be rely on the security analysis of TLS, and because we can expect improvements to come from TLS. I might assume that your preference for encrypting Client Hello is to avoid exposing parameters carried by the message (e.g., ALPN, Transport Parameters). If that is the case, I think the correct solution would be to move them into the extension slots of the ESNI extension. Then we can have the same level of protection without having our own handshake protocol. FWIW, you might want to refer to https://tools.ietf.org/html/draft-ietf-tls-esni-02#appendix-D; the compatibility discussion certainly does not apply to QUIC. |
|
Yes, my main goal is encrypting transport parameters. My thought process was that if we're able to do ESNI in QUIC, then we can use the same primitives to go a step further and encrypt the entire Initial payload, following our QUIC mindset of "if it can be encrypted, encrypt it". This would have the advantage of only doing this once, and would potentially require less changes in QUIC and TLS. Couldn't we rely on the security analysis of ESNI? |
Yeah my point is that assuming that the TLS stack would have support for ESNI, it would be easier to use the TLS+ESNI handshake protocol as-is, rather than developing something specific to QUIC. The building blocks we need are:
All of them need to secure and extensible. ESNI provides the former three, and the current approach of AH implements the fourth block reusing the ESI shared key. Exchanging the public key using the Initial headers means that we'd need to define all of the four blocks (or three, if we decide to rely on ESNI Resource Record for key distribution). To me it seems like an unnecessary overlap of features that would require more cost in terms of standardization, implementation, security analysis. Therefore, my preference goes to moving TP (and other privacy-sensitive extensions) into the ESNI extension rather than having our own key exchange. |
Hi @kazuho and @huitema, thanks for writing this! I was wondering, since this mechanism allows protecting the Initial payload, why not also to encrypt it?
We could write a separate KeyShareEntry (Named Group + Key Share) at the start of the payload and use that as the key to AES-GCM-128 to encrypt the payload. Header protection would use the traditional QUICv1 key and IV.
The text was updated successfully, but these errors were encountered: