Document request forgery

[martinthomson]

First cut at this, sorry about it being so long. It's fairly hard to
write this, particularly since the existing documentation is so sparse.
Hopefully this is clear enough. I haven't had time to properly
proof-read it, so it's probably not very good. But I thought I'd share
what I got.

This includes some basic countermeasures, but they aren't very good.
I think that's OK, but we should discuss.

Closes #3995.

[kazuho]

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

[huitema]

That's nice, but in many scenarios any of the node addresses can be used to reach services local to the node, in the same way as loopback addresses. In server farm scenarios, this requires guessing the local IP of the specific server, but that can probably be done. Same for clients behind NAT.

[igorlord]

@huitema This is certainly a way to mount an attack on services that assume that they are serving friendly clients and the network perimeter is secure. It happens, especially when services listen only on RFC1918/unique-local or link-local IPs. It happens even more often with services only listen to loopback and, therefore, think they are immune to any threats coming from outside of the host.

That's why the following is generalizing "non-loopback -> loopback" to “globally routable IP space” -> “RFC1918/unique-local IP space” -> “link-local” -> “loopback”.

[LPardue]

This para's grammar hurts my head. Alternative might be

"Initial packet protection provides resilience to control of contents by servers. Client choice of an unpredictable Destination Connection ID ensures servers are unable to control any of the encrypted portion of Initial packets."

[LPardue]

Then I might concate the next paragraph to this and say

"However, the Token field is open to control and does allow a server to use clients to mount request forgery attacks."

[huitema]

There is indeed a valid scenario for client and server discovering that they are behind the same NAT. Wasn't that scenario addressed in Web-RTC using a discovery protocol involving temporary names, in an attempt at privacy?

[DavidSchinazi]

I think you're referring to draft-ietf-rtcweb-mdns-ice-candidates. For us to do something like that we'd need a way to convey hostnames in preferred_address or elsewhere, and I'm not sure we should be doing that.

[martinthomson]

I agree with David. I don't see any way that the MDNS thing would make sense except in a very narrow domain (which WebRTC is). Nothing stopping someone from defining an extension, of course.

[huitema]

I like the general text. I am worried that the response to these attacks may need to evolve over time as we understand them better. I was looking at ways to say that. No specific suggestion yet.

[MikeBishop]

Eliminating it completely is infeasible. Limiting it certainly seems possible. As a simple precaution, an implementation might opt to break up large STREAM/CRYPTO frames and then randomize the order of frames while building the packet, distributing any padding to be added between frames instead of appending it.

There's no requirement or even substantial performance impact if the stream bytes are out-of-order within the packet.

[MikeBishop]

Suggested change

	any of the encryption portion of Initial packets.
	any of the encrypted portion of Initial packets.

[MikeBishop]

Suggested change

	The only field in an Initial packets that is open to server control is the
	The only field in Initial packets that is open to server control is the

[igorlord]

This MUST NOT is qualified by the subsequent text to a point of being unenforceable, especially due to "shared prefix of a sufficient length". Since it is up to implementations to choose what "sufficient" is, an implementation could deem "/0", to be "sufficient" and it would be valid. Since this is unenforceable, it probably warrants a "SHOULD NOT".

[janaiyengar]

Since there's a large escape hatch below, I agree that perhaps a SHOULD NOT is better here. The following text effectively explains why this isn't a MUST NOT.

[martinthomson]

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

[janaiyengar]

Thank you for writing this up! A few comments; almost all are editorial suggestions. Only a couple of questions.

[janaiyengar]

Suggested change

	A request forgery attack occurs where one endpoint causes its peer to perform
	A request forgery attack occurs where an endpoint causes its peer to perform

[janaiyengar]

I'm not clear on the terminology here, but isn't "request forgery" by definition limited to the action of issuing a request? If so, maybe this could be "causes its peer to issue a request towards a victim, where the request is crafted by the endpoint to inflict damage on the victim.".

[janaiyengar]

Suggested change

	forgery attack is often used to gain access to implicit authorization conferred
	by their peer's location in the network.
	forgery attack is often used to exploit any implicit authorization conferred
	on the peer by the victim due to the peer's location in the network.

[janaiyengar]

Suggested change

	what their peer sends, and where it is sent. If an attacker can target a
	what packets the peer sends, and to which target. If an attacker can target a

[janaiyengar]

Suggested change

	the network that indicates that sending datagrams to unvalidated addresses in a
	the network indicating that sending datagrams to unvalidated addresses in a

[janaiyengar]

Suggested change

	available over a different interface or the address was provided by a service
	available at a different address, or if the address was was provided by a service

[janaiyengar]

Suggested change

	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.
	frames in packets prior to completing address validation. Note that this does
	not prevent an attacker from using the Destination Connection ID field for
	an attack.

[janaiyengar]

Suggested change

	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
	them.
	attacks. Endpoints MAY avoid sending datagrams to these ports or not send
	datagrams that match these patterns prior to validating the destination address.
	Endpoints MAY retire connection IDs containing patterns known to be problematic
	without using them.

[janaiyengar]

Suggested change

	deploying network-based protections, as endpoints don't need to perform
	deploying network-based protections, as endpoints do not need to perform

[martinthomson]

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.

[martinthomson]

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.

[martinthomson]

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.

[martinthomson]

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

[martinthomson]

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

[martinthomson]

I'm good with MUST NOT.

[martinthomson]

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

[janaiyengar]

This is good. Thank you for working through the comments, @martinthomson !

[janaiyengar]

This has been around for a week now and I've heard no serious concerns but a fair bit of support. I'm marking this proposal-ready. Gah! This is the PR :-/ The issue's already been marked :-)

[kazuho]

@martinthomson Thank you for all the efforts that have gone into this PR.

Rereading it, I wonder if we should be talking about 0-RTT too, I think that 0-RTT can be also used as an attack vector. The attacker has the knowledge regarding the packet protection keys that will be used for 0-RTT, and it is easy to guess what packet number will be used.

Based on that, much like NEW_TOKEN tokens, I think it might be the case that we have to recommend to not use 0-RTT when the client resumes a connection to a different server address.

[martinthomson]

A server might be able to control 0-RTT content, but it can't control 0-RTT keys because those are derived from the ClientHello, which includes a nonce value the server can't predict (ClientHello.random). I note here that this is true for our TLS integration, but might not be true for other cryptographic handshakes.

[kazuho]

@martinthomson Thanks. Of course you are correct. I was only think about Early Secret, a value that can be estimated by the server. But in this case, it is client_early_traffic_secret that matters, and that incorporates ClientHello.

[ekr]

I don't believe that this is correct as written if there is a Retry because the server gets to control the next DCID. I don't think that this is relevant because you would need a round trip to make it work (I think!) but...

[DavidSchinazi]

This is mentioned in the last paragraph of this section. Perhaps we just need to reference that here?

[ekr]

Actually, I think not just DCID. Consider a (contrived) protocol in which the server was able to dictate the contents of the client's plaintext message. Because the server knows the keys, it can then produce any ciphertext of its choice.

[ekr]

While the above is contrived, the server does have control of some things. For instance, I can control some of the content of GETs or ACKs.

[DavidSchinazi]

Isn't that prevented by address validation?

[martinthomson]

No, this is general, but it is mentioned above. I will add a reminder.

[DavidSchinazi]

Overall I do think that this PR is going in the right direction, but I don't think it's quite ready to be merged yet.

[DavidSchinazi]

Do we have text that explicitly mandates that replies to a RETRY packet MUST be sent to the same address?

[martinthomson]

The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS].

Not sure if that is enough, as this is not directly a requirement, but more of an assumption.

[DavidSchinazi]

This is mentioned in the last paragraph of this section. Perhaps we just need to reference that here?

[DavidSchinazi]

Seeing this normative requirement in Security Considerations makes me uneasy as an implementer might miss it. Could we instead move the MUST NOT to the section that defines preferred_address and then only reference it here?

[martinthomson]

I think that repetition will do.

[DavidSchinazi]

Isn't that prevented by address validation?

[DavidSchinazi]

I do find it somewhat ironic that address validation might make this worse: the client sending a PATH_CHALLENGE to the server can pretty much guarantee that the server will send a PATH_RESPONSE with client-provided content to the client's spoofed source address. Should we mention that?

[martinthomson]

I considered it, but thought that the generic text was enough. Note also that there is no guarantee that PATH_RESPONSE is sent on the same path.

[DavidSchinazi]

I think you're referring to draft-ietf-rtcweb-mdns-ice-candidates. For us to do something like that we'd need a way to convey hostnames in preferred_address or elsewhere, and I'm not sure we should be doing that.

[DavidSchinazi]

Could we add a paragraph here that provides examples of real harm? What protocols are both UDP-based and non-authenticated in a way that would make them vulnerable to a request forgery from a QUIC stack?

[martinthomson]

I don't have anything concrete. Any example would be hard to describe with anything other than "this person/organization did something really unwise". Given the absence of a news-worthy example that would be easy to reference, this is really just a request to search for someone to shame.

[DavidSchinazi]

I'm not trying to shame anyone. I'm trying to ascertain whether this change is the right one: we're worsening the performance of the protocol (by requiring extra round-trips in some scenarios) and if the attack is purely theoretical then we shouldn't do that. Having a concrete example of actual harm would help motivate the performance degradation.

[martinthomson]

The only place this adds a round trip is for a migration to a preferred address, but that only delays migration, it doesn't prevent the connection from being used.

[MikeBishop]

The Message Send Service (RFC 1312) seems like a potential target.

This service is primarily intended for "open" environments:
controlled local area networks used by reasonably trusted
participants, in which security considerations may be relaxed in the
interests of ease of use and administration. In such an environment
it is appropriate to trust the user name and source IP address as
identifying the actual sender of the message.

[DavidSchinazi]

This depends on what you mean by efficient. Some of the recommendations in this section will add a round-trip which is not efficient.

[martinthomson]

I must be very confused, but your round trip point seems wrong. The key point here is that the round trip is not safe, so any time you attempt that you are exposing services to a potential attack. The point of this text is to describe heuristics that might block attacks without sending a packet at all.

[DavidSchinazi]

It's definitely possible that I'm the one confused. In my understanding, we have two ways of solving the "QUIC endpoint is sending attacker-controlled data to unvalidated address" issue:

1. the QUIC endpoint limits what it sends before validation
2. a magical network appliance verifies that the QUIC endpoint isn't sending evil packets where it shouldn't

I do agree with you that we want (1) instead of (2), but saying that (1) is more efficient than (2) isn't necessarily true if you measure efficiency as QUIC performance, because (1) can add a round trip but (2) doesn't

[martinthomson]

The first requires that the endpoint decide before it sends anything. It can't add a round trip, because that round trip would enable the attack.

[ianswett]

I'm concerned about this new SHOULD NOT, but maybe I'm misunderstanding it?

[ianswett]

To clarify, the NEW_TOKEN frame is not received from a server in an Initial packet, correct? The first few times I read this, I though that was what you intended.

Assuming I'm now reading this correctly, this SHOULD NOT would seem to be very restrictive for domains which use DNS to load balance traffic. Previously, I assumed that NEW_TOKEN would be used whenever hostnames matched. Am I understanding correctly?

If we're going to add this normative restriction, I would suggest placing the restriction in the section on address validation/etc and then referencing this section.