Subject: [Masque] Fwd: New Version Notification for draft-duke-quic-version-aliasing-00.txt

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 17:24:41 -0700

I filed this individual draft that builds on Marten Seemann's idea to
prevent QUIC version ossification. This provides an alternate means of
concealing the client hello that may be relevant to MASQUE if we don't want
to use the h3 ALPN.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Apr 6, 2020 at 5:13 PM
Subject: New Version Notification for
draft-duke-quic-version-aliasing-00.txt
To: Martin Duke <[email-masked]>

A new version of I-D, draft-duke-quic-version-aliasing-00.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.

Name:           draft-duke-quic-version-aliasing
Revision:       00
Title:          QUIC Version Aliasing
Document date:  2020-04-06
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-duke-quic-version-aliasing-00.txt
Status:
https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/
Htmlized:
https://tools.ietf.org/html/draft-duke-quic-version-aliasing-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-duke-quic-version-aliasing

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

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: David Schinazi <[email-masked]>
Date: Tue, 7 Apr 2020 15:31:36 -0700

[sending this to the MASQUE list but not QUIC as this response is specific
to MASQUE]

Hi Martin,

Thanks for writing this. I do think it'll be useful as mechanism to help
reduce the risk of middleboxes ossifying QUIC.

However, it doesn't help MASQUE as it only provides privacy enhancements
for subsequent connections within the expiry time.
MASQUE negotiation needs to be indistinguishable from HTTP/3, even the
first time a client connects to a given MASQUE server.

I think it would be easier to reason about this document if it separated
anti-ossification concerns from privacy concerns.

Thanks,
David

On Mon, Apr 6, 2020 at 5:25 PM Martin Duke <[email-masked]> wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Apr 2020 21:10:38 -0700

On 4/7/2020 3:31 PM, David Schinazi wrote:
> [sending this to the MASQUE list but not QUIC as this response is
> specific to MASQUE]
>
> Hi Martin,
>
> Thanks for writing this. I do think it'll be useful as mechanism to
> help reduce the risk of middleboxes ossifying QUIC.
>
> However, it doesn't help MASQUE as it only provides privacy
> enhancements for subsequent connections within the expiry time.

I think that we need to study this a bit more, but I like the general
idea of receiving a token and using it later to either authenticate or
obfuscate subsequent handshakes.

Yes, this is a "second connection" solution. But then, one could
conceivably design an "off-line" service to get a bootstrap token. And
with that it would solve the first connection problem.

>
> I think it would be easier to reason about this document if it
> separated anti-ossification concerns from privacy concerns.

Maybe. I am not sure that the two are not tied.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Wed, 8 Apr 2020 15:10:02 -0700

You could definitely define something that works at encrypting the ALPN for
the first connection, but I don't think we need that for MASQUE.

David