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

[Eric Rescorla <[e-mail]>]

Kazuho,

Thanks for sending this. I think it's a very interesting direction. I have
some comments below.

DEPLOYMENT MODEL
It seems to me that there are two models to consider here. In the
first, the server *only* supports authenticated handshakes (AH) and in
the second, it supports both authenticated and unauthenticated
handshakes. In general, I think the second case is far more likely,
because in general we can't assume that clients can receive the
ESNIKeys records, and that means that some clients will not use AH.


THREAT MODEL
This leads us directly to the question of the threat model. I assume
that we have what I termed a Class (3) attacker, which can inject
packets and will always win the race but cannot delete packets.
With that, you get the following pattern:


Client                  Attacker                Server

CInitial ->
                        CInitial' ->
                        CInitial  ->
                                           <- SInitial
                        <- SInitial'
                        <- SInitial

CHandshake ->
                        CHandshake ->

Our objective is to have the handshake survive this treatment. In an
ideal world, we would cause the server and client to reject X' and
process X but this isn't possible, with the design you suggest,
because the attacker can always take CInitial, replace the CRYPTO
frames with his own and then send it to the server, computing
a new MAC based on *his* Zx. Note that this won't necessarily have
the right ESNI but that doesn't matter, because it will have
the same [SC]CID, and so will cause cause CInitial to be discarded
when it is received. As far as I can tell, your current design
does not prevent this. If I'm missing something here, let me
know [0]



FIRST CLIENT INITIAL
It seems like the obvious defense is the one you suggest in S 3.2.2,
namely to treat each distinct CInitial as its own handshake and create
separate state on the server for each one. Then this will cause the
server to send two SInitials, one in response to CInitial and one
in response to CInitial'. This gives us the diagram below.

Client                  Attacker                Server

CInitial ->
                        CInitial' ->
                                           <- SInitialX   // Corresponds to
CInitial'

                        <- SInitialX'
                        <- SInitialX

                        CInitial  ->
                                            <- Sinitial   // Corresponds to
CInitial
                        <- Sinitial'
                        <- SInitial

CHandshake ->
                        CHandshake ->

Note that the attacker can duplicate and tamper with any message
either side sends so because the server sends two SInitials, the
attacker ends up potentially sending 4.


SERVER INITIAL FLIGHT
So, what we need at this point is to ensure that the client rejects
(a) SInitial', SInitialX' and (b) SInitialX, and accepts SInitial (I'm
ignoring subsequent Initial packets from the Client at this point),
but I'll get there shortly. Rejecting SInitial' happens automatically
in your design. The attacker doesn't have Zx and so SInitial' will not
deprotect correctly.

Rejecting SInitialX is harder, but I think can be fixed by mixing CInitial1
into the the key schedule. I.e., the initial key would be something
like:

  IS = HKDF-Extract(0xef4fb0abb47470c41befcf8031334fae485e09a0,
                    Zx)

  initial_secret = HKDF-Extract(HKDF-Expand(IS, ...),
                                F(CInitial))

Where F(CInitial is some sanitized version of CInitial, that is
invariant under retransmission, perhaps the payload + the CIDs.

The result of this is that SInitialX and SInitial will be encrypted
with separate keys (with only the one for SInitial being the one
that the client expects) and the client will discard SInitialX
after it fails to decrypt.


SUBSEQUENT CLIENT INITIALS
The diagram looks like this

Client                  Attacker                Server

CInitial ->
                        CInitial' ->
                                           <- SInitialX   // Corresponds to
SInitial'
                        CInitial  ->
                                            <- Sinitial

                        <- SInitialX'
                        <- SInitialX
                        <- SInitial
                        <- Sinitial'

CInitial2 ->
                        CInitial2' ->
                        CInitial2 ->

There are actually two types of subsequent client Initials


1. Those after SH that contain ACKs (and the like) for server
   Initial.
2. Those after HRR

With case (1), we should just rekey off of Initial secret. The server
can sort out which keys to use based on trial decryption or perhaps
some extra flag in the packet (probably the second is better).

Case (2) (HRR) is more complicated. Trying to use data in the ESNI
extension when you're not going to use g^x is tricky (though maybe
possible), so we could potentially handle this as in case (1). Another
alternative is to use the same general strategy we used for the
first Initial and bucket the CInitial1/CInitial2 pairs. This is easiest done
if we force each CInitial2 to commit to a specific CInitial1 (thus avoiding
the need to do combinatoric explosion on the server). You could
do this by including a hash of CInitial1 in CInitial2. The attacker
can obviously bind CInitial2' to any CInitial he wants, but he has
to transmit one message for each, so the result is the same as
sending N CInitial1s.


VERSION NEGOTIATION
In your design you move version negotiation to the client and forbid
VN:

   A client MUST ignore Version Negotiation packets.  When the client
   gives up of establishing a connection, it MAY report the failure
   differently based on the receipt of (or lack of) Version Negotiation
   packets.

More concerning, this moves the QUIC version negotiation to the ESNI
record, which permits downgrade attacks by that server (or anyone who
controls DNS). We've generally avoided this in TLS ESNI. It could
be solved by having the true origin sign the ESNIKeys structure
(as we have discussed for semi-static).

It's worth noting that this is a consequence of QUIC's VN design. With
the simplified VN design I suggested in PR #2113, you wouldn't have
this problem: the server would commit to its *minimum* version (this
is implicit in ESNIKeys already, as it requires TLS 1.3) and then you
could upward negotiate as expected.


[0] Another possibility with your current design is for the attacker
to tamper with CH, for instance by adding a dummy extension, because
the ESNI extension doesn't protect all of CH, just g^x. This will
cause the server's Handshake messages to deprotect incorrectly. One
could imagine a fix for this if the ESNI extensions covered more
of the CH.



On Thu, Dec 13, 2018 at 6:34 PM 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
>
>