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

[Martin Duke <[e-mail]>]

Thanks Martin,

Replies inline.

On Mon, Apr 6, 2020 at 5:34 PM Martin Thomson <[e-mail]> 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