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

[Ian Swett <[e-mail]>]

That would also allow this to be placed in DNS via the HTTPSVC draft.

On Fri, Apr 24, 2020 at 9:51 PM Ryan Hamilton <[e-mail]> wrote:

> 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
>>
>>
>>