RE: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt

[Mike Bishop <[e-mail]>]

I had to puzzle through a few pieces of this, but this approach seems promising.  However, I would be very sad to tie the use of QUICv1 to the successful deployment of ESNI keys (particularly for the reasons we're already concerned about ESNI's current structure in a multi-CDN context).  For that reason, I think a separate version (either v2 or an alternative to v1) is the right choice.



I'm also wondering whether this actually *needs* to use ESNI as the publication mechanism.  For example, an extension to QUICv1 could be defined to relay the server’s keyshare for use on future connections.  However, ESNI permits you to delegate issues of lifetime, pinning, revocation, etc. to the DNS, which is certainly attractive.



-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Kazuho Oku
Sent: Thursday, December 13, 2018 6:34 PM
To: IETF QUIC WG <[e-mail]>
Cc: Christian Huitema <[e-mail]>
Subject: Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt



TL;DR: Christian and I have submitted an I-D that proposes a flavor of QUIC v1 that uses the Encrypted SNI key to authenticate Initial packets. Initial packets are no longer vulnerable to man-on-the-side attacks; the entire handshake process becomes tamper-proof.



https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/



## Background



So far, we have spent multiple efforts to make QUIC resistant to man-on-the-side attacks. Among them, mitigating injection attacks of Initial packets has been the biggest head-ache.



There have been various proposals (including #2045, #2053, #2076), but the question has always been if it's worth the effort, because there are so many attack vectors (e.g. injection of a packet carrying a corrupt header, invalid or unknown frames, ACKs with unsent PNs, crafted TLS Hellos, HelloRetryRequests, crafted Version Negotiation or Retry packets) and it is doubtful if having mitigations for just one or few types of attacks are meaningful. We want to close all the attack vectors, however it is like building house of cards.



## The Proposed Approach



The draft introduces a different approach. It relies on the Encrypted SNI [1]. For people not familiar with Encrypted SNI, it is an extension of TLS 1.3 that uses a public key distributed using DNS to encrypt the SNI. Encrypted SNI is currently a TLS WG draft, has multiple implementations, and it is already deployed by Cloudflare and Mozilla.



The approach proposed by the draft is to use a shared secret that is derived from the Encrypted SNI key to authenticate the Initial packets, using HMAC. Because the shared key can only be calculated by the endpoints, an attacker cannot spoof the Initial packets. Spoofed packets will be detected by HMAC and will be to dropped.



The draft disables Version Negotiation (because the DNS record of Encrypted SNI can carry a list of QUIC versions supported by the server), a different client-side behavior for handling Retry packets, and also introduces a CONNECTION_CLOSE packet to communicate handshake failures without affecting the transport state.



And of course, it also uses a different QUIC version number in the long packet header field so that the Initial packets of QUIC v1 and the authenticated Initial packets of the proposal can be handled differently.



Other than that, the protocol is identical to QUIC v1, including the handling of 0-RTT, Handshake, 1-RTT packets and the frames being contained by them. IMO, the differences are small and isolated well enough that QUIC v1 stacks can easily add support for the flavor proposed by the I-D.



There are other benefits too. We have always hoped to have multiple versions of QUIC being deployed from early days in order to prevent ossification. The proposal makes that happen. Besides, one interesting aspect of the proposed protection of Initial packets is that MITM boxes (with root certificates) would not be possible to terminate the connection _unless_ they also block the distribution of Encrypted SNI DNS records, and that even then, the existence of such MITM boxes is detectable. Raising the bar of implementing and deploying MITM boxes as well as detecting them is beneficial for the evolution of the protocol.



The downside of the proposal is that it only protects QUIC connections going to servers that provide the Encrypted SNI DNS records. But considering our failing attempts to address the Initial packet injection attacks, and considering the amount of interest we have seen for Encrypted SNI, I think that the proposed approach is the way forward.



Please let us know what you think. Thank you in advance.



PS. The GitHub repository of the I-D is:

https://github.com/kazuho/draft-kazuho-quic-authenticated-handshake



---------- Forwarded message ---------

From: <[e-mail]<mailto:[e-mail]>>

Date: 2018年12月14日(金) 11:30

Subject: New Version Notification for

draft-kazuho-quic-authenticated-handshake-00.txt

To: Kazuho Oku <[e-mail]<mailto:[e-mail]>>, Christian Huitema <[e-mail]<mailto:[e-mail]>>







A new version of I-D, draft-kazuho-quic-authenticated-handshake-00.txt

has been successfully submitted by Kazuho Oku and posted to the IETF repository.



Name:           draft-kazuho-quic-authenticated-handshake

Revision:       00

Title:          Authenticated Handshake for QUIC

Document date:  2018-12-14

Group:          Individual Submission

Pages:          9

URL:

https://www.ietf.org/internet-drafts/draft-kazuho-quic-authenticated-handshake-00.txt

Status:

https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/

Htmlized:

https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-00

Htmlized:

https://datatracker.ietf.org/doc/html/draft-kazuho-quic-authenticated-handshake





Abstract:

   This document explains a variant of QUIC protocol version 1 that uses

   the ESNI Keys to authenticate the Initial packets thereby making the

   entire handshake tamper-proof.









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







--

Kazuho Oku