Subject: Update on Version Aliasing, ECHO for QUIC

From: Martin Duke <[email-masked]>
Date: Wed, 5 May 2021 08:00:06 -0700

You may recall that at IETF 109 I presented my version aliasing draft. (The
server sends a transport parameter with a random version number and salt
that the client can use next time, which greases the version and [I claim]
secures Initial Packets). It was well received, but I haven't gotten much
in the way of reviews (especially a much-needed security review) since.

There's a new version of this draft
https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/
that has only minor changes.

However, I wrote a new companion draft that mangles the ECHO design to
encrypt initial packets beginning with the first connection. This would be
a new version of QUIC, leveraging some of the lessons from last month's v2
exercise:
https://datatracker.ietf.org/doc/draft-duke-quic-protected-initial/

I wrestled with the crypto piece for a long while, and it could really use
a look from an expert.

Thanks,
Martin

---

From: David Schinazi <[email-masked]>
Date: Wed, 5 May 2021 13:26:48 -0700

Thanks for writing these drafts Martin, I'm interested in seeing these
progress and would like to implement them.

I took a closer look at draft-duke-quic-protected-initial and filed a
couple issues (#17
<https://github.com/martinduke/quic-version-aliasing/issues/17> and #18
<https://github.com/martinduke/quic-version-aliasing/issues/18>), but
overall it seems sound*.

* I am not a crypto expert, more of an enthusiast...

David

On Wed, May 5, 2021 at 8:00 AM Martin Duke <[email-masked]> wrote:

> You may recall that at IETF 109 I presented my version aliasing draft.
> (The server sends a transport parameter with a random version number and
> salt that the client can use next time, which greases the version and [I
> claim] secures Initial Packets). It was well received, but I haven't gotten
> much in the way of reviews (especially a much-needed security review) since.
>