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

[Martin Duke <[e-mail]>]

Alt-svc is a great idea. I might restructure the draft to cover multiple
delivery systems besides transport parameters.

The difficulty with DNS is that the DNS server has to have the keys to
securely generate salts. I would love to have an internet where that was
easy, but someone who knows more than me about DNS will have to tell me if
it can be.

Thanks for reading!

On Sun, Apr 26, 2020, 08:06 Ian Swett <[e-mail]> wrote:

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