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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Some thoughts:

1. this is the only way to go both due to SNI privacy / censoring, and
injection attacks.
2. if this is not v1, we risk a split similar to http vs https, which could
defer acceptance for a decade - but OTOH there are is complexity to discuss
- maybe consider a simple v1 and a better v2.
3. depending on an external DNS service and signature design, this might be
more vulnerable to gov. coercion than TLS records alone. Does this matter?
4. text should consider alternative key distribution mechanisms for private
networks over public networks. I.e. I don’t trust/bother with DNS, but I
can install public keys at all clients, or shared symmetric keys.
5. I am concerned about DoS attacks on public key crypto - it may take time
to verify tag.
6. I don’t understand the initial crypto being the same as v1 - does this
mean that client TP is still externally visible - shouldn’t that be avoided?
7. is this tied too heavily in with TLS considering other versions that
might want to use more light weight crypto - e.g. version negotiation is
now after public crypto, and public crypto flavour might be unfriendly to
constrained devices.
8. The entire DNS infrastructure is in need of an overhaul, including
possibly DNS over QUIC. How does that work?
9. HMAC - what about new hashes like SHA-3? Yes - QUIC v1 also uses HMAC
same question, same answer.
10. This still doesn’t address rewriting source/target IP addresses either
as a replacement, or a race, in handshake and migration, so some analysis
is needed to state this is a significant improvement despite of this.

Mikkel

On 14 December 2018 at 03.34.20, Kazuho Oku ([e-mail]) wrote:

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