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

Kazuho Oku <> Thu, 13 August 2020 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0F8C3A0BE6 for <>; Thu, 13 Aug 2020 05:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.101
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CsZevEJPGPZt for <>; Thu, 13 Aug 2020 05:20:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5139F3A0BE4 for <>; Thu, 13 Aug 2020 05:20:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3C3FD5E005D for <>; Thu, 13 Aug 2020 05:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1597321229; bh=aWUKMnfKkwrWIG63jDo15r/lj/VR7eVbLpaDhVzo9zg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZP1vNTdVF3yD+myGZUf8MgOOvwZugs7NHLguuv6s1z5jCu15DiYpd0QRamYXtjJKX rYbSzgfpP/xppnn2qiFyBjVIUC7SwVRx+QyA0Q4uocNcfpRfJyzn8idNokRMoq+g7s 60Meeln3tZrfEsD5ZVok6P5qbUC+okPBg52bvdac=
Date: Thu, 13 Aug 2020 05:20:29 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3996/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Document request forgery (#3996)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f35300d2cfc8_381916f83900f3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2020 12:20:32 -0000

@kazuho commented on this pull request.

I think there are some errors (left comments), but this looks good.

> +address validation; see {{address-validation}}.
+Outside of the encrypted portion of packets, QUIC offers an endpoint several
+options for controlling the content of UDP datagrams that a peer sends. The
+Destination Connection ID field offers direct control over early bytes of every
+packet sent by a peer; see {{connection-id}}. The Token field in Initial
+packets offers a server control over other bytes of Initial packets; see
+There are no measures in the protocol to prevent indirect control over the
+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
+frames that convey application data, such as STREAM frames. Though this depends
+to some degree on details of the application protocol, some control is possible
+in many protocol usage contexts. As the attacker has access to packet
+protection keys, they are able to predict how a peer will encrypt future

protection keys, they are likely to be capable of predicting how a peer will encrypt future

While it is true that all the cipher-suites defined in the TLS drafts share this property, I do not think that is a prerequisite of AEAD ciphers in general?

> +migration to a non-loopback address if the same service was previously
+available over a different interface or the address was provided by a service
+at a non-loopback address. Endpoints that depend on these capabilities could
+offer an option to disable these protections.
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate cases. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network that indicates that sending datagrams to unvalidated addresses in a
+given range is not safe.
+Endpoints MAY choose to reduce the risk of request forgery by not including
+values from NEW_TOKEN frames in Initial packets or by only sending non-probing

values from NEW_TOKEN frames in Initial packets or by only sending probing

> +frames in packets prior to completing address validation. Note that this might
+not constrain some attacks as it does not prevent an attacker from using the
+Destination Connection ID field.
+Endpoints are not expected to have specific information about the location of
+servers that could be vulnerable targets of a request forgery attack. However,
+it might be possible over time to identify specific UDP ports that are common
+targets of attacks or particular patterns in datagrams that are used for
+attacks. Endpoints MAY choose to avoid sending datagrams to these ports or that
+match these patterns prior to validating the target address. Endpoints MAY
+retire connection IDs containing patterns known to be problematic without using
+: Modifying endpoints to apply these protections is more efficient that

: Modifying endpoints to apply these protections is more efficient than

> +against attacks that use spoofing and originate from an external network.
+### Generic Request Forgery Countermeasures {#forgery-generic}
+The most effective defense against request forgery attacks is to modify
+vulnerable services to use strong authentication. However, this is not always
+possible when deploying QUIC. This section outlines some others steps that QUIC
+endpoints could take. These additional steps are all discretionary as,
+depending on circumstances, they could interfere with or prevent legitimate
+Services offered over loopback interfaces (that is, ::1 or often
+lack proper authentication. Endpoints MAY prevent connection attempts or
+migration to a loopback address. Endpoints SHOULD NOT allow connections or
+migration to a non-loopback address if the same service was previously

migration to a loopback address if the same service was previously

I'm not sure, but maybe this is the intent?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: