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

From: Martin Duke <[email-masked]>
Date: Thu, 23 Apr 2020 16:56:02 -0700

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: <[email-masked]>
Date: Thu, Apr 23, 2020 at 4:50 PM
Subject: New Version Notification for
draft-duke-quic-version-aliasing-01.txt
To: Martin Duke <[email-masked]>

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Apr 2020 10:07:51 -0700

That's a nice draft, Martin, but I wonder about deployment. The draft
proposes defining temporary versions in which the Initial packet is
encrypted using a temporary salt keyed by the Initial Token Extension.
This effectively creates a fully encrypted exchange, as the key is only
known to the client and the server. On one hand I like it. It provides
us with a QUIC only solution for encrypted SNI, encrypted ALPN, and
encrypted TP. It prevents third parties from interfering with the QUIC
handshake, much like the authenticated handshake draft. But then, it
also prevents firewalls from inspecting outgoing Client Hellos, and
incurs the risk that they just drop what they don't understand. How do
we verify that this encrypted Initial mechanism can be deployed?

-- Christian Huitema

On 4/23/2020 4:56 PM, Martin Duke wrote:
> Based on some great feedback from the list, I substantially revised
> this draft:
> - Added "Initial Token Extensions" to increase salt entropy and make
> seed polling attacks impractical.
> - Made standard version encoding mandatory. This dramatically
> simplifies the new Retry logic and changes the security model.
>
> Martin
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: Martin Duke <[email-masked] <mailto:[email-masked]>>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>

---

From: Martin Duke <[email-masked]>
Date: Fri, 24 Apr 2020 11:03:22 -0700

I think the deployment story is the same as the less ambitious earlier
attempts at preventing version number ossification -- we need a few "big
players" (you know who you are) to implement this, and that applies the
right amount of pressure to operators to admit the traffic.

It's a similar situation to virtually every other aspect of encrypting the
transport and TLS handshake data. Do you see this as significantly
different by degree?

A substantially less ambitious approach would just generate a few random
version numbers for all clients and not have new salts -- this would do
nothing to protect Initial Packets, but would at least block ossification
of the version field.

I didn't want to go here, because the draft was already hard to write, but
if the domain has its own DNS server, it could distribute the relevant
information via DNS with a unique version/ITE/salt for each query. If
version aliasing really took off, that would be a cool DNS extension.

On Fri, Apr 24, 2020 at 10:08 AM Christian Huitema <[email-masked]>
wrote:

> encrypted using a temporary salt keyed by the Initial Token Extension. This
> effectively creates a fully encrypted exchange, as the key is only known to
> the client and the server. On one hand I like it. It provides us with a
> QUIC only solution for encrypted SNI, encrypted ALPN, and encrypted TP. It
> prevents third parties from interfering with the QUIC handshake, much like
> the authenticated handshake draft. But then, it also prevents firewalls
> from inspecting outgoing Client Hellos, and incurs the risk that they just
> drop what they don't understand. How do we verify that this encrypted
> Initial mechanism can be deployed?
>
> -- Christian Huitema

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 24 Apr 2020 18:51:00 -0700

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.

---

From: Ian Swett <[email-masked]>
Date: Sun, 26 Apr 2020 11:05:50 -0400

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 <[email-masked]> 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.
>

---

From: Martin Duke <[email-masked]>
Date: Sun, 26 Apr 2020 09:02:24 -0700

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!

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Apr 2020 19:25:21 +0000

> easy, but someone who knows more than me about DNS will have to tell me if

DNS expects you to use the in-band dynamic update protocol for this (see RFC 
2136), if you have traditional zones, or else answer all questions for that 
name programmatically (like in the CDN world) if you don't have traditional 
zones.

-- 
Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 27 Apr 2020 10:21:53 +1000

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

We've recently realized that provision over HTTP and DNS have very different security characteristics.  The design that Martin envisages benefits greatly from individualized keys, which is great, but you can't do that with DNS.  A lot of this depends on your goals.  If this is just in pursuit of better protection against ossification, then that's very different from something that provides the same protections as ESNI/ECHO.