Subject: [quicwg/base-drafts] Authenticating public parts of the packet header (#226)

From: janaiyengar <[email-masked]>
Date: Tue, 24 Jan 2017 17:51:45 -0800

QUIC AEAD usage in quic-tls draft currently says "associated data, A,  for the AEAD is an empty sequence." The current rationale is that the public header fields do not need to be authenticated since the connection ID, flags, packet number, and version number are all effectively covered by  encryption/decryption. 

We have at least 1 public flags field that is as yet unused. Since we do not know its use yet, we may want to authenticate the header to future-proof.

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

---

From: martinduke <[email-masked]>
Date: Tue, 24 Jan 2017 18:14:31 -0800

I can think of mildly problematic middlebox behavior that QUIC could block by authenticating the public header. For instance, a middlebox could inspect a CHLO and then rewrite the connection ID to aid in classification and traffic shaping.

This may or may not be acceptable, but then if there is a path change or multipath that bypasses the middlebox, the connection will break.

-- 
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/226#issuecomment-275000392