Re: New Version Notification for draft-duke-quic-version-aliasing-01.txt

[Ryan Hamilton <[e-mail]>]

I love this and think it is a net positive for QUIC. Would it also be worth
specifying an Alt-Svc embedding for this information? This would allow
HTTP/3 client to use the aliased version on their *first* connection to a
new server.

On Thu, Apr 23, 2020 at 4:56 PM Martin Duke <[e-mail]> wrote:

> Based on some great feedback from the list, I substantially revised this
> draft:
> https://www.ietf.org/id/draft-duke-quic-version-aliasing-01.html
>
> Key changes:
> - Added "Initial Token Extensions" to increase salt entropy and make seed
> polling attacks impractical.
> - Allowed servers to store a mapping of version number and ITE to seed
> instead of a crypto function.
> - Made standard version encoding mandatory. This dramatically simplifies
> the new Retry logic and changes the security model.
>
> Martin
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Thu, Apr 23, 2020 at 4:50 PM
> Subject: New Version Notification for
> draft-duke-quic-version-aliasing-01.txt
> To: Martin Duke <[e-mail]>
>
>
>
> A new version of I-D, draft-duke-quic-version-aliasing-01.txt
> has been successfully submitted by Martin Duke and posted to the
> IETF repository.
>
> Name:           draft-duke-quic-version-aliasing
> Revision:       01
> Title:          QUIC Version Aliasing
> Document date:  2020-04-23
> Group:          Individual Submission
> Pages:          14
> URL:
> https://www.ietf.org/internet-drafts/draft-duke-quic-version-aliasing-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/
> Htmlized:
> https://tools.ietf.org/html/draft-duke-quic-version-aliasing-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-duke-quic-version-aliasing
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-duke-quic-version-aliasing-01
>
> 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 and encrypts Initial Packets using secret keys instead of
>    standard ones.  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, as well as improving the protocol's privacy
>    properties.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>