Subject: I-D Action: draft-ietf-quic-version-aliasing-00.txt

From: [email-masked]
Date: Mon, 06 Apr 2020 17:07:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : QUIC Version Aliasing
        Author          : Martin Duke
	Filename        : draft-ietf-quic-version-aliasing-00.txt
	Pages           : 11
	Date            : 2020-04-06

Abstract:
   The QUIC transport protocol [QUIC-TRANSPORT] preserves its future
   extensibility partly by specifying its version number.  There will be
   a relatively small number of published version numbers for the
   foreseeable future.  This document provides a method for clients and
   servers to negotiate the use of other version numbers in subsequent
   connections.  If a sizeable subset of QUIC connections use this
   mechanism, this should prevent middlebox ossification around the
   current set of published version numbers and the contents of QUIC
   Initial packets.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-version-aliasing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-version-aliasing-00
https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-aliasing-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 17:19:23 -0700

Sorry everyone,

Typo in the title xml. I immediately replaced it with an individual draft.

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 17:25:51 -0700

Sorry everyone

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Apr 6, 2020 at 5:07 PM
Subject: I-D Action: draft-ietf-quic-version-aliasing-00.txt
To: <[email-masked]>
Cc: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the QUIC WG of the IETF.

Abstract:

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 Apr 2020 10:33:43 +1000

Thanks for putting this together Martin.  It's good to see this all written down.  (I'm ignoring the name.  I'm sure we can sort that out.)

>From the length of the document, it's clear that this isn't small enough to justify inclusion in the draft.  More so because I'm about to suggest more text...

This document doesn't appear to address the case where a server has aliased X and now discovers that they want to deploy a version that uses that value.  Concretely, this allows you do alias version 2, but we might define a real version 2 at some point that the server wants to deploy.  I think that the basic design strongly discourages deployment of a version that might be covered by an alias that was previously advertised, unless you love trial decryption of maybe-Initial packets.  That means carving out space for the new version (and maybe its aliases) and not issuing aliases for those.  Then you have to wait for expiration of the aliases that cover the overlap.

Your text on linkability really needs to treat an alias like resumption ticket or a path validation token.  That avoids a bunch of problems with replicating recommendations and the like.  It also opens a bunch of options with respect to the token.

There's a version of this design that I particularly like that uses the token more.  If you have a token, then if you are prepared to read from that, the version field can contain almost anything.  You only need to ensure that you need to avoid deploying a version that doesn't have a token.

The mandates on using a RNG for the version and a cryptographic function for the salt are a little strong.  There is no inherent problem with randomly generating and remembering mappings.  And versions might be ignored entirely if you encode the real version into the token field as above.

The Initial salt is 20 octets in this version of QUIC.  It might be a different length in the final version.  And it can be up to 64 octets without costing any more time in generating keys.  Maybe you don't need to be so precise.

---

From: Martin Duke <[email-masked]>
Date: Tue, 7 Apr 2020 10:49:24 -0700

Thanks Martin,

Replies inline.

On Mon, Apr 6, 2020 at 5:34 PM Martin Thomson <[email-masked]> wrote:

> <snip>
>
> This document doesn't appear to address the case where a server has
> aliased X and now discovers that they want to deploy a version that uses
> that value.  Concretely, this allows you do alias version 2, but we might
> define a real version 2 at some point that the server wants to deploy.  I
> think that the basic design strongly discourages deployment of a version
> that might be covered by an alias that was previously advertised, unless
> you love trial decryption of maybe-Initial packets.  That means carving out
> space for the new version (and maybe its aliases) and not issuing aliases
> for those.  Then you have to wait for expiration of the aliases that cover
> the overlap.
>

I envision expiration times as being quite short, but I added some language
about this in the working draft. If a client gets a VN packet or TP that
later advertises that version, you should discard the aliased one.

>
> Your text on linkability really needs to treat an alias like resumption
> ticket or a path validation token.  That avoids a bunch of problems with
> replicating recommendations and the like.  It also opens a bunch of options
> with respect to the token.
>
> There's a version of this design that I particularly like that uses the
> token more.  If you have a token, then if you are prepared to read from
> that, the version field can contain almost anything.  You only need to
> ensure that you need to avoid deploying a version that doesn't have a token.
>

I wouldn't mind more specifics about your preference here, but the token is
a bit overloaded. The resumption token includes some IP address data that
we expressly don't want. The existing Retry token is actually important in
resolving a few security issues related to this proposal, as you can see in
the section on Retry.

>
>
> The mandates on using a RNG for the version and a cryptographic function
> for the salt are a little strong.  There is no inherent problem with
> randomly generating and remembering mappings.  And versions might be
> ignored entirely if you encode the real version into the token field as
> above.
>

This is a great suggestion and I have added it to the working draft.

>
> The Initial salt is 20 octets in this version of QUIC.  It might be a
> different length in the final version.  And it can be up to 64 octets
> without costing any more time in generating keys.  Maybe you don't need to
> be so precise.
>
>
I do need at least 16 octets because I've repurposed the salt for some
Retry mechanics. I agree that we *could* allow more flexibility here, but
unless we're prepared to offer some considerations for salt length I'd
rather keep it simple for now.

Martin