Subject: Clarification of transport and HTTP version compatibility

From: Samuel Hurst <[email-masked]>
Date: Wed, 9 May 2018 17:04:56 +0100

Hi all,

Does the quic-transport version and the HTTP mapping version have to
match? For example, could you negotiate QUIC draft-11, but the HTTP side
is still using an older version (such as draft-09 to avoid the
requirement of QPACK)?

As far as I understand it, the QUIC transport version is negotiated as
part of the TransportParams in the appropriate TLS extension, and the
HTTP mapping version is negotiated by ALPN. So in the example above,
would it be acceptable to negotiate 0xff00000a as the transport protocol
version, and then have an ALPN string of "hq-09"?

I'm then assuming that a valid Alt-Svc header for my example could be as
follows:

Alt-Svc: hq-09=":4443";quic="ff00000a"

The quic-tls draft mentions in Section 9.1 "The application-layer
protocol MAY restrict the QUIC version that it can operate over", but
none of the quic-http drafts that I've read list any such restriction.
Therefore, I'm then further assuming that it's safe to run whatever
version of the HTTP mapping I like, unless there's a compatibility
matrix between the various specs that I'm missing?

Best Regards,
Sam

---

From: Mike Bishop <[email-masked]>
Date: Wed, 9 May 2018 17:18:10 +0000

There's no firm restriction, no.  While I find it likely that draft deployments will choose to keep matching versions, the only restriction that the HTTP draft currently imposes is that it be a version of QUIC which uses TLS as the handshake protocol.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Does the quic-transport version and the HTTP mapping version have to match? For example, could you negotiate QUIC draft-11, but the HTTP side is still using an older version (such as draft-09 to avoid the requirement of QPACK)?

As far as I understand it, the QUIC transport version is negotiated as part of the TransportParams in the appropriate TLS extension, and the HTTP mapping version is negotiated by ALPN. So in the example above, would it be acceptable to negotiate 0xff00000a as the transport protocol version, and then have an ALPN string of "hq-09"?

The quic-tls draft mentions in Section 9.1 "The application-layer protocol MAY restrict the QUIC version that it can operate over", but none of the quic-http drafts that I've read list any such restriction.
Therefore, I'm then further assuming that it's safe to run whatever version of the HTTP mapping I like, unless there's a compatibility matrix between the various specs that I'm missing?

Best Regards,
Sam

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 May 2018 18:03:56 +0000

I think this all works fine in the current stage of specification. 

Longer term, what is the failure case for interoperability where different implementations have  different rules for how to combine QUIC version and HTTP/QUIC version. Protocol error due to reception of unanticipated packets and or HTTP/QUIC frames?

Lucas
________________________________________
From: QUIC [[email-masked]] on behalf of Mike Bishop [[email-masked]]
Sent: 09 May 2018 18:18
To: Sam Hurst-RD; IETF QUIC WG
Subject: RE: Clarification of transport and HTTP version compatibility

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

---

From: Mike Bishop <[email-masked]>
Date: Wed, 9 May 2018 21:01:58 +0000

They *shouldn't* be unanticipated protocol errors, because both are negotiated.  I would expect (or at least hope) that these will manifest as negotiation failures at worst.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 May 2018 21:42:52 +0000

I've not terribly familiar with the transport negotiation aspects, so I'm probably missing something sorry.

I guess what is not clear to me is the question, who is responsible for ensuring a sane answer is negotiated? (I suspect no one). It gets more annoying if the client is acting on information provided to it via Alt-Svc, which is quite liberal to from the sender perspective (there are some rules for the client defined in HTTP/QUIC 2.1.1.).

How I read things in the simple case was:

1) Transport version negotiation takes place and client chooses a version. Cryptographic handshake is next.
2) Client intitiates TLS 1.3 handshake with version info for revalidation, plus ALPN list of what it believes are application protocols that are compatible with the chosen version of QUIC.
   a) POSSIBILITY 1 in a pathological case it always sends the same list regardless of version.
3) Server selects an application protocol it believes is compatible with the chosen version of QUIC.
  b) POSSIBILITY 2 naive implementations just assume "hq" works for everything.
4) Client sends something the server is unhappy with and the connection bombs with a protocol error.

Cheers
Lucas
________________________________________
From: Mike Bishop [[email-masked]]
Sent: 09 May 2018 22:01
To: Lucas Pardue; Sam Hurst-RD; IETF QUIC WG
Subject: RE: Clarification of transport and HTTP version compatibility

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Mike Bishop <[email-masked]>
Date: Wed, 9 May 2018 22:43:52 +0000

I think your description of the process is correct.  But for something to fail post-handshake, both possibilities have to occur, not just one.  If a client naively offers an application protocol that doesn't work over the selected version, the server ought to ignore it (and abort the connection if it was the only one offered).  If a client correctly filters its list, the server can't accept what isn't offered even if it's buggy.  So if only one side is broken, what happens should be that the TLS handshake will fail to select an application-level protocol and the connection fails before any requests are sent.

What the TLS draft says about ALPN and versions is:
> If the server cannot select a compatible combination of application protocol and QUIC version, it MUST abort the connection. 
> A client MUST abort a connection if the server picks an incompatible combination of QUIC version and ALPN identifier.

It should be implied, but might be worth explicitly stating, that failure to agree on an ALPN is incompatible with all QUIC versions, always fatal.

>From the Alt-Svc perspective, the ALPN is proscriptive (7838 says fail if that particular ALPN isn't accepted) and the QUIC version is only advisory.  If the advertised version of HTTP/QUIC is no longer supported, they'll fail back to HTTPS, get a new Alt-Svc entry, and try again later.  If the advertised version of HTTP/QUIC *is* supported but a new transport version has become available, the client might try that if it believes the new transport version to be compatible with its existing HQ version.  If that works, it might get an updated Alt-Svc entry telling it that a new HQ version is available as well.

Now, if both sides have mutually agreed to speak an incompatible pair of application protocol and transport versions, then you're in uncharted territory.  If they both expect the same things about how those interact, it'll work; if not, it won't.  That's basically the same as anyone who mutually negotiates an option but disagrees about what the option means, and that's hard to guard against.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, May 9, 2018 2:43 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 May 2018 23:24:26 +0000

Thanks for that explanation Mike, it makes more sense now. 

> It should be implied, but might be worth explicitly stating, that failure to agree on an ALPN is incompatible with all QUIC versions, always fatal.

I don't know if it needs explicit statement. RFC 7301 section 3.2 states that "In the event that the server supports no
 protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert."

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 2:43 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 18:28:15 +0000

Interesting.  I don't believe I've ever seen an implementation actually do that.  If none of the client's proffered protocols are supported, they pretend not to support ALPN and don't include the extension in the ServerHello.  (Though obviously I haven't attempted to test this much.)

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, May 9, 2018 4:24 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

> It should be implied, but might be worth explicitly stating, that failure to agree on an ALPN is incompatible with all QUIC versions, always fatal.

I don't know if it needs explicit statement. RFC 7301 section 3.2 states that "In the event that the server supports no  protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert."

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 2:43 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 May 2018 18:41:13 +0000

Mike, you have not only seen, but shipped such an implementation in several Windows releases.
😊

The logic behind the RFC is that there is no need to waste cycles and complete the handshake if the client and server disagree on the application protocol.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, May 9, 2018 4:24 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 2:43 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.co.uk&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C4ae9736e39614601660308d5b6a3d4e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615737135415287&sdata=%2Fcrt5YmXDN4bvV9yfGkjvnWvYr0LbttsFP3NmhFMtuI%3D&reserved=0

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 18:55:48 +0000

Ah, I see SEC_E_APPLICATION_PROTOCOL_MISMATCH for that.  Good to know.

In that case, we should be able to assume that the requirement to use ALPN is sufficient; if no ALPN token can be agreed on, the TLS handshake will fail and the connection will close.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, May 9, 2018 4:24 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 2:43 PM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Cheers
Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <[email-masked]>; Sam Hurst-RD <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Clarification of transport and HTTP version compatibility

Lucas

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Best Regards,
Sam