Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

introduce a version alias mechanism #2573

Closed
wants to merge 8 commits into from
Closed

introduce a version alias mechanism #2573

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
870b0ad
draft some text about the version_aliases transport parameter
marten-seemann Mar 27, 2019
077e03c
add an initial secret to the version alias
marten-seemann Mar 27, 2019
2e3a99e
make the version alias lifetime a varint
marten-seemann Apr 1, 2019
9d1090e
make the lifetime a uint32
martinthomson Apr 9, 2019
9e77f11
change the lifetime to milliseconds
mikkelfj Apr 9, 2019
4e3089d
Rewrap
MikeBishop Apr 18, 2019
d887ca7
Mike's suggestions
marten-seemann Apr 18, 2019
b085787
be pedantic about supporting alias versions
marten-seemann Apr 18, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 40 additions & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3246,7 +3246,26 @@ Implementors are encouraged to register version numbers of QUIC that they are
using for private experimentation on the GitHub wiki at
\<https://github.com/quicwg/base-drafts/wiki/QUIC-Versions\>.


## Version Aliases

In order to avoid ossification of the version number defined by this draft,
servers announce a list of version numbers that they interpret as aliases for
the version number used in this draft. Alias versions MUST NOT be a reserved
version. A server MUST NOT advertise an alias version number for a version that
it actually supports. If the server advertises an alias version number that the
client actually supports, the client MUST assume the server doesn't support
that version and ignore the alias.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that the client has to ignore the alias, per se -- it just needs to be cognizant of what the interpretation of that version will be on that server. On the other hand, if there's a possibility that the server might acquire support for that version between flights (server upgrade case), perhaps it's better that the client just avoids it entirely after all.


Servers SHOULD send at least one version alias, and SHOULD frequently change the
value that they announce. Each version alias contains a lifetime, which
indicates how long the server will accept this version alias. It also contains
an initial salt, which is used instead of the initial salt as defined in section
5.2 of {{QUIC-TLS}}. The list of version aliases is sent in the server's
Transport Parameters (see {{transport-parameter-definitions}}).

Clients SHOULD remember the list of aliases and use it for subsequent
connections to the same server in the future. This applies to both 0-RTT
connection as well as connections that don't use 0-RTT.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a note that Version Aliases must not be advertised during version negotiation

Suggested change
Version aliases MUST NOT be advertised in version negotiation Packets to avoid conflicts with future versions and experiments.

# Variable-Length Integer Encoding {#integer-encoding}

Expand Down Expand Up @@ -3955,6 +3974,7 @@ language from Section 3 of {{!TLS13=RFC8446}}.
max_ack_delay(11),
disable_migration(12),
preferred_address(13),
version_aliases(14),
(65535)
} TransportParameterId;

Expand Down Expand Up @@ -4115,6 +4135,25 @@ preferred_address (0x000d):
~~~
{: #fig-preferred-address title="Preferred Address format"}

version_aliases (0x000e):

: A list of version numbers that the server accepts as aliases for the
currently used version. This transport parameter is only sent by the server.
Every version alias contains a lifetime in milliseconds. The alias is only
valid for that lifetime. Clients MUST NOT use an expired alias.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we require the server to announce (some) of the version aliases during their whole lifetime to enable the client to detect downgrade attacks?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the idea that this lifetime is also a commitment to support a given version, then this isn't really a fully effective downgrade-prevention mechanism. I expect that we'll see something good on that shortly.

I would instead prefer to say that the server is required to honour the alias for the entire advertised lifetime unless it also stops supporting that QUIC version.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't consider this a fully effective downgrade-prevention mechanism, but it provides a mechanism for the client to detect on-path version tapering: If the client gets a version negotiation packet in return to an alias version and receives the same version alias that failed again, it can be sure someone is doing a downgrade attack (or the server is horribly broken).

~~~
struct {
uint32 VersionNumber;
uint32 lifetime_ms;
opaque InitialSecret<20>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You want opaque InitialSalt[20]; or opaque InitialSalt<20..32>; with appropriate values for minimum and maximum.

Suggested change
opaque InitialSecret<20>;
opaque initial_secret[20];

} VersionAlias;

VersionAliases VersionAlias<0..2^16-1>;
~~~
{: #fig-version-aliases title="Version Aliases format"}


If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, and
initial_max_stream_data_uni) are equivalent to sending a MAX_STREAM_DATA frame
Expand Down