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