Subject: [quicwg/base-drafts] Version downgrade vulnerability (#121)

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Jan 2017 02:34:13 -0800

If we do this badly, there might be two versions of QUIC for which the transport parameters are confusable in a way that confounds the validation of version negotiation because the transport parameters are interpreted differently for different QUIC versions.

We need to write that into the security considerations.  We might recommend preserving the initial part of the transport parameters extension, or - better yet - using a new extension codepoint when the format needs to change.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 19:56:32 -0800

Marking as design to improve visibility.

-- 
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/121#issuecomment-270825766

---

From: hardie <[email-masked]>
Date: Thu, 12 Jan 2017 10:55:51 -0800

So, just to be sure I understand this:  Client engages in version negotiation and claims to be version N.  The validation step would be an effort to confirm that transport parameters conform to N.  You're concerned that version N+1's use of that set of parameters would retain the same form but have a different meaning; in that case, validation by syntax doesn't work.  

If that's right, I agree that having design/security considerations highlighting the issue is reasonable and recommending that when the semantics of a syntactical element need to change a new codepoint should get assigned.

-- 
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/121#issuecomment-272249290

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 16:29:44 -0800

@hardie, yes you got 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/121#issuecomment-272327088

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Jan 2017 17:59:07 -0800

I'm not certain I did, though.

If the server declines to speak N, it won't look at the handshake, and therefore won't ever attempt to interpret the transport parameters.  If they do a negotiation round-trip and wind up on N+1, the client would send fresh parameters in format N+1.

Are we guarding against a client bug where they accidentally reuse their original transport parameters in the new version, or where semantics "leak" between versions in a client that supports several?

-- 
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/121#issuecomment-272592873

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jan 2017 13:33:34 -0800

The attack here is that you have a change in the *structure* of the transport parameters such that a client might construct transport parameters from version N, but due to the version negotiation being attacked have them interpreted as being version M.  That could be in a way that ensures that the server thinks the client is OK according to the server's version M interpretation; at the same time the client could see the server's version M parameters as valid according to a version N interpretation.

If you don't think that sounds likely, imagine moving the version fields in #122 to a parameter and follow the logic through.  It is plausible, if unlikely, that the two variations could be interpreted as being correct when evaluated under a different schema.

-- 
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/121#issuecomment-272725510