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

[Kazuho Oku <[e-mail]>]

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]>
Date: 2018年12月14日(金) 11:30
Subject: New Version Notification for
draft-kazuho-quic-authenticated-handshake-00.txt
To: Kazuho Oku <[e-mail]>, Christian Huitema <[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