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

[Kazuho Oku <[e-mail]>]

Hi Mike,

Thank you for your comments. My responses inline.

2018年12月15日(土) 9:07 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 share the same view. QUIC v1 should not rely on the standardization of ESNI.

In fact, one of the reasons I started working on QUIC-AH (the proposed
I-D) is to spin off the attempts to have mitigations against
man-on-the-side attacks during handshake in QUIC v1.

Let's ship v1 knowing that it does not mitigate the attack (by having
post-handshake MOTS attack resistance, QUICv1 is already much better
than TLS over TCP), then close the remaining attack vector, possibly
by using ESNI.

FWIW, regarding ESNI in multi-CDN context, my understanding is that we
are trying to fix problem in TLS WG.

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

That's an interesting idea.

Actually, ESNI records can be published by something other than DNS. I
think that a server can send it's ESNI record as a post-handshake
message of TLS. The record would be considered valid for the server's
IP address for the validity period expressed in the record itself (we
have not_before and not_after fields).

OTOH, I would like to point out that the risk of relying on a
pre-shared public key to protect the handshake is that loss of the
public key results in service disruption. I am not sure having a
"casual" method of distributing such pre-shared key raises the risk.

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



-- 
Kazuho Oku