Re: [quicwg/base-drafts] Document request forgery (#3996)

Martin Thomson <notifications@github.com> Wed, 19 August 2020 09:54 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEEC3A16FD for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 02:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level:
X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb16SNj7SnNl for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 02:54:48 -0700 (PDT)
Received: from out-25.smtp.github.com (out-25.smtp.github.com [192.30.252.208]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8B93A16FA for <quic-issues@ietf.org>; Wed, 19 Aug 2020 02:54:48 -0700 (PDT)
Received: from github-lowworker-52827f8.ash1-iad.github.net (github-lowworker-52827f8.ash1-iad.github.net [10.56.108.24]) by smtp.github.com (Postfix) with ESMTP id B48AE840922 for <quic-issues@ietf.org>; Wed, 19 Aug 2020 02:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597830887; bh=ERF19LYzXvpVMG2IYqCLqxfZac5FDPZ25NXBaBQFAXg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0gsR3rCJ6elBwhrwvyOUqKnOS+xWCnGPeFCHa7SWfmGnczgJYTD6s4LDg40GNu1S+ sNhoBmQatjFEE4o33pupkXsZzakKsl7pWRIT3efDuXLmipvWQEZ47e0Jdp4FV5VtkV iLD3NOeeGk50VuanrjFF92sHiZXCAqvQrZM5AtyQ=
Date: Wed, 19 Aug 2020 02:54:47 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7UWBOAF47T6HOLJFV5JDL6PEVBNHHCQ3GPNU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3996/review/470282935@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3996@github.com>
References: <quicwg/base-drafts/pull/3996@github.com>
Subject: Re: [quicwg/base-drafts] Document request forgery (#3996)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3cf6e7a5dae_58bb1964174562"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/GEFl_qUlKh5yWKrkkwfSet9in1s>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2020 09:54:51 -0000

@martinthomson commented on this pull request.

Thanks Jana,

I started applying these, then realized that I needed to rewrap and make other tweaks, so I've just made most of these changes, verbatim, as part of a manual commit.

> +
+Initial packet protection (Section 5.2 of {{QUIC-TLS}}) makes it difficult for
+servers to control the content of Initial packets. A client choosing an
+unpredictable Destination Connection ID ensures that servers are unable to
+control any of the encrypted portion of Initial packets. However, the Token
+field is open to server control and does allow a server to use clients to mount
+request forgery attacks.
+
+Use of tokens provided with the NEW_TOKEN frame ({{validate-future}}) offers
+the only option for request forgery during connection establishment.
+
+Clients are not obligated to use the NEW_TOKEN frame. Request forgery attacks
+that rely on the Token field can be avoided if clients do not include a value
+when the server address has changed from when the NEW_TOKEN frame was received.
+
+Clients MUST NOT send a token received in a NEW_TOKEN frame from one server

I'm at SHOULD NOT on my copy already.  I guess I forgot to push it.

> +For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}}
+exploits on the Web cause a client to issue requests that include authorization
+cookies {{?COOKIE=RFC6265}}, allowing one site access to information and
+actions that are intended to be restricted to a different site.

I wanted to connect this with something that has a lot of existing documentation and explanatory material.  I found relatively little good material on the subject.

> +otherwise be unavailable to the attacker. For a networking protocol, a request
+forgery attack is often used to gain access to implicit authorization conferred
+by their peer's location in the network.
+
+For request forgery to be effective, an attacker needs to be able to influence
+what their peer sends, and where it is sent. If an attacker can target a
+vulnerable service with a controlled payload, that service might perform
+actions that are attributed to the attacker's peer, but decided by the
+attacker.
+
+For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}}
+exploits on the Web cause a client to issue requests that include authorization
+cookies {{?COOKIE=RFC6265}}, allowing one site access to information and
+actions that are intended to be restricted to a different site.
+
+As QUIC runs over UDP, the primary attack modality of concern is one where an

I think I will pass on this one.  QUIC (this version, or invariants) run over UDP.

> +the data sent by QUIC endpoints is protected, this includes control over
+ciphertext. An attack is successful if an attacker can cause a peer to send a

We use a stream cipher, which is essentially an XOR with a predictable sequence.  If you know what the sequence is (this is trivial if you have the keys, just encrypt all zero values), then you know what the transform is and then, you can choose plaintext that is the XOR of the ciphertext you want.

> +encrypted portions of packets. It is necessary to assume that endpoints are
+able to control the contents of frames that a peer sends, especially those

This goes back to the encryption-by-XOR from above.  If I can control plaintext and make some good guesses about where it might appear, then I can control ciphertext.

> +This section assumes that limiting control over datagram content is not
+feasible. The focus of the mitigations in subsequent sections is on limiting

It would also be reasonable to implement some countermeasures that prevented control over datagram content.  The ciphertext fix does costs a lot though (it's a major change to the protocol that likely has a significant performance impact or requires the use of new ciphers) and it is not sufficient either as there are other more serious problems, like the SPA+connection ID one that I think we've agreed is too valuable a feature to dispense with (and options without this exposure are likely intractable for some server deployments).

I could write all of that down, but I thought it better to just state the assumption.

> +other types of packet to a destination that does not understand QUIC and is
+willing to accept connections.

I think that was supposed to be "....or is not willing to accept a QUIC connection"

> +the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server address,
+thereby preventing the use of subsequent Initial packets for request forgery.
+
+
+### Request Forgery with Preferred Addresses
+
+Servers can specify a preferred address, which clients then migrate to after
+confirming the handshake; see {{preferred-address}}.
+
+The Destination Connection ID field of packets that the client sends to a
+preferred address can be used for request forgery.
+
+A client SHOULD NOT send non-probing frames to a preferred address prior to

I'm good with MUST NOT.

> +This document does not offer any additional specific countermeasures that can
+be implemented by endpoints aside from the generic measures described in
+{{forgery-generic}}.

These countermeasures are not comprehensive.  Hence "additional".  Re-reading this though, I felt the need to reword...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996#pullrequestreview-470282935