Subject: [quicwg/base-drafts] Hinting at quic version in Alt-Svc (#124)

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 17:36:15 -0800

Is there the potential for a version downgrade if the client is given unauthenticated hints about the version(s) that the server supports?

It's true that Alt-Svc will be authenticated in MOST cases, so maybe we don't have to worry about this.  On the other hand, it creates problems for analyzing the security properties of the negotiation.  I would suggest that we should insist that the Alt-Svc advertisement be authenticated before using any hints.

That could rule out the DNS as a source of version hints.

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

---

From: janaiyengar <[email-masked]>
Date: Thu, 05 Jan 2017 18:09:29 -0800

The use of Alt-Svc for negotiating QUIC would be in the HTTP mapping document,  but this seems reasonable to 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/124#issuecomment-270813232

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jan 2017 22:10:43 -0800

I *think* this is a non-issue, but it depends on how Source Tokens are handled and I'm not entirely clear on that yet.  So check my logic.

If you've dealt with the server over QUIC before, you know its (previous) supported version list because that data is carried in the Transport Parameters (at least in both our current PRs!).  That should always supersede the Alt-Svc hints.

If you haven't dealt with the server over QUIC before, you're going to do a 1-RTT handshake anyway because you lack a Source Token.  (I think.)  You'll find out the server's supported list before you send any data and detect any attempted downgrade.

The hint only serves to help you avoid the 1-RTT case turning into a 2-RTT case, because you have to first find an acceptable version, *then* do a 1-RTT TLS handshake.  Of course, if you can reuse your 0-RTT context from a TLS/TCP connection, that might get us into muddier water.

-- 
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/124#issuecomment-271065866

---

From: Patrick McManus <[email-masked]>
Date: Sun, 08 Jan 2017 10:01:57 -0800

> If you've dealt with the server over QUIC before, you know its (previous) supported version list because that data is carried in the Transport Parameters (at least in both our current PRs!). That s…

are you saying you have to pin a min version? how would a service rollback if it operationally needed to? Maybe I'm misreading..

-- 
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/124#issuecomment-271167399

---

From: Mike Bishop <[email-masked]>
Date: Sun, 08 Jan 2017 10:29:51 -0800

In a roll-back scenario, you get a version you don’t understand on the server, then do 0-RTT on the next round-trip, and pick up the server’s new (old) config.  Not ideal, but still secure.

Sent from my Windows 10 phone

From: Patrick McManus<mailto:[email-masked]>
Sent: Sunday, January 8, 2017 10:02 AM
To: quicwg/base-drafts<mailto:[email-masked]>
Cc: Mike Bishop<mailto:[email-masked]>; Comment<mailto:[email-masked]>
Subject: Re: [quicwg/base-drafts] Hinting at quic version in Alt-Svc (#124)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/124#issuecomment-271167399>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hRtXhY_nU2hAUC3k3RrZchqh5qW8ks5rQSSVgaJpZM4LcUW8>.

-- 
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/124#issuecomment-271169079

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jan 2017 15:17:52 -0800

I think that there is a hole in the logic.  Say that you have a client that prefers version 22.  It receives a false advertisement that says that the server supports version 20 and 21 (it really does include 22, but it's old or modified).  The client will proceed into the handshake with 21.

The server supports 22, and the client eventually learns this.  However, neither peer is dissatisfied with 21 and so they proceed with 21. If 21 actually has a vulnerability that neither is aware of, that's an opening for an attacker.  If the client is REQUIRED to reject this we have no security issue, just a nasty performance one (assuming that we stick to h2 in this case because hq just failed).

The text that I currently have does not require a failure in this case.  The assumption being that if the server did not trigger version negotiation, then the server was OK with the version that the client offered.  I think that this is a considerable weakness in the version negotiation scheme because the decision to trigger negotiation is made in ignorance of all the facts.  That might be a difficult problem to address though.

The basic property we're looking for is that the peer that chooses gets its most preferred choice from the set of mutually supported options.  If we don't require a hard fail, it's clear to me that we don't have that property.  We might be able to regain that property by adding a bunch of extra conditions on the ways that version hints can be advertised.  But that significantly increases the complexity of the security analysis required, as well as the fragility of the protocol.

@MikeBishop is right to point out that without a hint in Alt-Svc, you can get some nasty latency effects.  It's probably also true that we can add conditions on the advertisement that will be met by Alt-Svc and address the concern, but we need to be very careful about this.

-- 
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/124#issuecomment-271187816

---

From: Mike Bishop <[email-masked]>
Date: Sun, 08 Jan 2017 16:08:25 -0800

I would phrase the desired property differently, and that probably influences the different approaches.  My desired properties were that the peers wind up on *some mutually-acceptable* version on the current connection and can identify the highest mutually-supported version (and switch to it if they choose) 1 RTT later.  Notably, the upgrade case -- if the server has newly added support for version 22, I think it's fine for clients to use version 21 for one more connection while they discover the server's new capability.

If a version is vulnerable and neither peer knows it, then an attacker has an opening.  That's going to be true regardless.  Clients that don't update their acceptable protocols are vulnerabilities waiting to happen, whatever else we mandate.

If you want to change the new-connection-on-higher-version-discovery from MAY to SHOULD or MUST, that's a reasonable point of discussion.  I'd also be fine saying that authenticated hints (such as previous connections) MUST always trump unauthenticated hints (such as DNS or http:// Alt-Svc).  I'm somewhat less comfortable saying unauthenticated hints get ignored entirely.

-- 
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/124#issuecomment-271191339

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jan 2017 16:52:50 -0800

I'm not pushing in any particular direction, I just want to make sure we understand the properties of the design we have.

> If a version is vulnerable and neither peer knows it, then an attacker has an opening. That's going to be true regardless.

This is not necessarily true.  It's just a consequence of the current negotiation design.  For example, absent the structural flaws in earlier versions of TLS, if both peers support TLS 1.3 and the server prefers it, they either negotiate TLS 1.3 or detect a downgrade attack.  The same applies for cipher suite negotiation and most of the other negotiated properties.  There are plenty of reasons why an endpoint might have to accept a weakened version of a protocol, but ensuring that you end up with the most preferred option prevents a whole class of attacks.

For instance, we now know that SHA-1 is weak.  But in many protocols, endpoints are forced to accept it or lose the ability to communicate with lots of peers.  This is true in SIP, HTTP, and even TLS, at least for the time being.  It's not busted to the point that we know that we absolutely can't use it, but we damn well wish we didn't have to support it.  A negotiation design that could be coerced into negotiating SHA-1 when a better alternative was available would be unacceptable.

Now, I guess you could say that clients could put older or less preferred versions into two categories: merely tolerable and known good.  If a known good version is available and a merely tolerable version is negotiated, abort.  That's more complicated, I don't know what we would write down about it, I don't know how you would write down advice about the categorization, and I don't know what the analysis would look like, but it might be a feasible tweak on the existing design.

-- 
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/124#issuecomment-271194549

---

From: ianswett <[email-masked]>
Date: Tue, 10 Jan 2017 08:11:21 -0800

I tend to agree with Mike's points and his stated design goal.

You're point about weaker versions is a valid one.  If the client also indicated what versions it supported in the handshake, the server could quickly decide whether to reject or accept a slightly older version.  If both are happy with the selected version given knowledge of the available options, that seems fine.

-- 
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/124#issuecomment-271618294

---

From: mirjak <[email-masked]>
Date: Tue, 10 Jan 2017 09:06:04 -0800

As a meta-comment here: I'm not sure if there really is a downgrade attack because other than with TLS/crypto negotiation, I would rather not expect to have always the case where a newer version is better than an older one. It might just be different; and if you need a certain feature that is only supported in version X, than there is no point for you to use version Y. Also I would expect version numbers not necessarily to increase linearly; I guess you could just pick a random number in the available space.

-- 
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/124#issuecomment-271634240

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Jan 2017 17:55:45 -0800

I'm not convinced there's a reason to use unauthenticated hints -- what is the argument for allowing them? If we do hints with Alt-Svc, that'll mean that we require the negotiation to have happened over HTTPS, which is what I'd want.

-- 
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/124#issuecomment-272592621

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Jan 2017 18:08:10 -0800

Alt-Svc requires that the target be secure, not the origin.  So an Alt-Svc header containing hints can come over plaintext, and the question is whether we ignore them.

My inclination is that (in the absence of anything better) an unauthenticated hint is better than a blind guess.

-- 
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/124#issuecomment-272593507

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jan 2017 22:11:49 -0800

Discussed in Tokyo; consensus in the room that at least one side should send complete version information in the version handshake, and the decider has the option to restart. Therefore, alt-svc does not need to be authenticated.

-- 
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/124#issuecomment-274718753

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jan 2017 22:11:49 -0800

Closed #124.

-- 
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/124#event-933993724