Subject: Version Negotiation, Crypto Protocols, and ALPN

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Dec 2016 18:05:36 +0000

We've got a couple GitHub issues around version negotiation and how all the pieces play together.  I'd like to keep the layers as modular as possible, so I'm trying to flex the joins a little bit conceptually.

*        draft-ietf-quic-transport<https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.2.3> says:

If not explicitly specified in the application mapping, TLS is assumed to be the default crypto handshake protocol, as described in [QUIC-TLS]. An application that maps to QUIC MAY however specify an alternative crypto handshake protocol to be used.

*        draft-ietf-quic-tls<https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.8.1> says:

The ALPN identifier for the protocol MUST be specific to the QUIC version that it operates over.

*        draft-ietf-quic-http<https://quicwg.github.io/base-drafts/alpn-alt-svc/draft-ietf-quic-http.html#rfc.section.3> (in PR#90) would say:

HTTP/QUIC support is indicated by selecting the ALPN token "hq" in the crypto handshake.

*        Ian's comment in Issue #45<https://github.com/quicwg/base-drafts/issues/45#issuecomment-263712650>:

I would suggest [the crypto protocol] be baked into the QUIC version.

There's also some related discussion in Issue #87<https://github.com/quicwg/base-drafts/issues/87> / Issue #89<https://github.com/quicwg/base-drafts/issues/89> which diverged from it.

So the application mapping is supposed to specify the QUIC versions and, implicitly or explicitly, the crypto protocol that's acceptable.  Except the crypto protocol is already known by the time the ALPN tokens are being interpreted, because you have to parse the QUIC frame and the crypto protocol to find the ALPN tokens.  Besides which, I'm inclined *not* to require new QUIC versions to imply revs to the application protocol anyway; if we had to, either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. placeholder where the QUIC version is embedded), but I'd prefer that HTTP allows *any* version of QUIC that provides the necessary properties (which is likely to be all future versions, but not necessarily).  Those versions might or might not use TLS as their crypto protocol - HTTP simply requires QUIC, and QUIC simply requires that the crypto handshake be able to negotiate an application-layer protocol.

I'm thinking of it this way:

*        QUIC specifies that a particular QUIC version uses a particular crypto handshake and/or allocates the crypto protocol a few bits of the version field.

*        The QUIC TLS extension carries:

o   Client->server:  The initially-offered version

o   Client->server:  The finally-selected version

o   Server->client:  The set of versions the server did / would have sent in a Version Negotiation packet

*        The application specifies requirements of the QUIC version to be used, but doesn't bind that version in its ALPN token

However, this is a more expansive design issue, so I'd like to make sure it's visible on-list.

---

From: Martin Duke <[email-masked]>
Date: Fri, 30 Dec 2016 22:10:30 -0800

I agree that binding QUIC versions to the ALPN seems unnecessary.

If by the second point you mean that TLS would handle QUIC version
negotiation, I'm not sure how that work. In principle new QUIC versions
might change the headers, so I'm not sure how we'd get to the TLS message
in the general case.

Or perhaps I misunderstood what you wrote.

On Tue, Dec 20, 2016 at 10:05 AM, Mike Bishop <[email-masked]>
wrote:

> We’ve got a couple GitHub issues around version negotiation and how all
> the pieces play together.  I’d like to keep the layers as modular as
> possible, so I’m trying to flex the joins a little bit conceptually.
>
>
>
> ·        draft-ietf-quic-transport
> <https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.2.3>
> says:
>
> If not explicitly specified in the application mapping, TLS is assumed to
> be the default crypto handshake protocol, as described in [QUIC-TLS]. An
> application that maps to QUIC MAY however specify an alternative crypto
> handshake protocol to be used.
>
> ·        draft-ietf-quic-tls
> <https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.8.1>
> says:
>
> ·        draft-ietf-quic-http
> <https://quicwg.github.io/base-drafts/alpn-alt-svc/draft-ietf-quic-http.html#rfc.section.3>
> (in PR#90) would say:
>
> HTTP/QUIC support is indicated by selecting the ALPN token “hq” in the
> crypto handshake.
>
> ·        Ian’s comment in Issue #45
> <https://github.com/quicwg/base-drafts/issues/45#issuecomment-263712650>:
>
> There’s also some related discussion in Issue #87
> <https://github.com/quicwg/base-drafts/issues/87> / Issue #89
> <https://github.com/quicwg/base-drafts/issues/89> which diverged from it.
>
>
>
> So the application mapping is supposed to specify the QUIC versions and,
> implicitly or explicitly, the crypto protocol that's acceptable.  Except
> the crypto protocol is already known by the time the ALPN tokens are being
> interpreted, because you have to *parse* the QUIC frame and the crypto
> protocol to *find* the ALPN tokens.  Besides which, I'm inclined *not* to
> require new QUIC versions to imply revs to the application protocol anyway;
> if we had to, either HTTP would define that the ALPN token is e.g.
> `hq-QQQQ` (i.e. placeholder where the QUIC version is embedded), but I’d
> prefer that HTTP allows *any* version of QUIC that provides the necessary
> properties (which is likely to be all future versions, but not
> necessarily).  Those versions might or might not use TLS as their crypto
> protocol – HTTP simply requires QUIC, and QUIC simply requires that the
> crypto handshake be able to negotiate an application-layer protocol.
>
>
>
> I’m thinking of it this way:
>
> ·        QUIC specifies that a particular QUIC version uses a particular
> crypto handshake and/or allocates the crypto protocol a few bits of the
> version field.
>
> ·        The QUIC TLS extension carries:
>
> ·        The application specifies requirements of the QUIC version to be
> used, but doesn’t bind that version in its ALPN token
>
>
>
> However, this is a more expansive design issue, so I’d like to make sure
> it’s visible on-list.
>

---

From: Mike Bishop <[email-masked]>
Date: Sat, 31 Dec 2016 16:15:11 +0000

No, the spec already requires that TLS echo it, because when QUIC sends it it’s not protected and could be tampered with.  My primary addition there is that the server’s list be sent by TLS even if not by QUIC, so the client can cache it.

Sent from my Windows 10 phone

From: Martin Duke<mailto:[email-masked]>
Sent: Friday, December 30, 2016 10:10 PM
To: Mike Bishop<mailto:[email-masked]>
Cc: IETF QUIC WG<mailto:[email-masked]>
Subject: Re: Version Negotiation, Crypto Protocols, and ALPN

If by the second point you mean that TLS would handle QUIC version negotiation, I'm not sure how that work. In principle new QUIC versions might change the headers, so I'm not sure how we'd get to the TLS message in the general case.

On Tue, Dec 20, 2016 at 10:05 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
We’ve got a couple GitHub issues around version negotiation and how all the pieces play together.  I’d like to keep the layers as modular as possible, so I’m trying to flex the joins a little bit conceptually.

•        draft-ietf-quic-transport<https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.2.3> says:

•        draft-ietf-quic-tls<https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.8.1> says:

•        draft-ietf-quic-http<https://quicwg.github.io/base-drafts/alpn-alt-svc/draft-ietf-quic-http.html#rfc.section.3> (in PR#90) would say:

HTTP/QUIC support is indicated by selecting the ALPN token “hq” in the crypto handshake.

•        Ian’s comment in Issue #45<https://github.com/quicwg/base-drafts/issues/45#issuecomment-263712650>:

There’s also some related discussion in Issue #87<https://github.com/quicwg/base-drafts/issues/87> / Issue #89<https://github.com/quicwg/base-drafts/issues/89> which diverged from it.

So the application mapping is supposed to specify the QUIC versions and, implicitly or explicitly, the crypto protocol that's acceptable.  Except the crypto protocol is already known by the time the ALPN tokens are being interpreted, because you have to parse the QUIC frame and the crypto protocol to find the ALPN tokens.  Besides which, I'm inclined *not* to require new QUIC versions to imply revs to the application protocol anyway; if we had to, either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. placeholder where the QUIC version is embedded), but I’d prefer that HTTP allows *any* version of QUIC that provides the necessary properties (which is likely to be all future versions, but not necessarily).  Those versions might or might not use TLS as their crypto protocol – HTTP simply requires QUIC, and QUIC simply requires that the crypto handshake be able to negotiate an application-layer protocol.

•        QUIC specifies that a particular QUIC version uses a particular crypto handshake and/or allocates the crypto protocol a few bits of the version field.

•        The QUIC TLS extension carries:

•        The application specifies requirements of the QUIC version to be used, but doesn’t bind that version in its ALPN token

However, this is a more expansive design issue, so I’d like to make sure it’s visible on-list.