Subject: Consensus call for Request Forgery Attacks (#3995)

From: Lucas Pardue <[email-masked]>
Date: Wed, 2 Sep 2020 22:40:37 +0100

Folks,

During the last consensus call, discussion of issue #3995 indicated some
pushback to the proposal <https://github.com/quicwg/base-drafts/pull/3996>.
The conclusion of the call stated that this issue would be put back into
the Late-Stage Process.

Subsequent discussion about the issue and the proposal has occurred. It
seems that the different parties are tending towards consensus on the
proposal as it was originally presented. Therefore, this email marks the
start of a short consensus call for this issue alone. The call will end at
CoP Friday September 4, Anywhere on Earth. Absent pushback, we'll direct
the editors to incorporate the proposal.

Cheers,
Lars, Lucas and Mark
QUIC WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Sep 2020 15:51:32 -0700

> the editors to incorporate the proposal.

This is phrased as about issues, so it's not quite clear to me what the
impact of this is. For clarity, let me state my position affirmatively. I
think further investigation is needed to determine the potential impact of
this form of attack before we decide not to do anything about it. I agree
that this PR is accurate and if the editors wish to merge it in the
interest of avoiding rebasing and the like, that's fine, but I do not
believe that we should close the issue.

-Ekr

---

From: David Schinazi <[email-masked]>
Date: Wed, 2 Sep 2020 17:47:18 -0700

As someone who sent quite a few comments on this PR, I just wanted to say
that all my non-editorial concerns have been addressed, and I personally
believe that the PR is ready to be merged and the issue closed.
I think that further investigation into determining the potential impact of
this form of attack can happen outside of the scope of this issue; if
someone has new information, that'll warrant opening a new issue.

David

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 3 Sep 2020 21:06:42 +0100

Thanks for your views both.

The construction of the issue is mildly unfortunate given our Late-Stage
Process which is oriented around landing PRs that close issues. The PR is
labelled as design, so strictly we cannot merge it unless it closes a
design issue. Perhaps there is a way to carve the issue or the PR so that
we land editorial change. However, I'm conscious of the extra work this
would require.

My understanding is that the issue says "document the attacks and add some
small mitigations". The PR lays out the attack(s) and provides some basic
countermeasures. My impression is there might be opportunity or need to do
more in this space but until someone does the work, we won't know. As an
outcome of the issue, we can create a new issue now to capture any thoughts
raised during the discussion. Alternatively, the process continues to allow
someone to come with new information and have the WG consider it.

Cheers
Lucas

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 4 Sep 2020 14:08:49 -0700

The broader issue could perhaps use some thinking, but I don't think that
ought to hold back the closing of this issue. As Lucas notes, the issue is
specific to documenting the attack, and I would say the PR does that quite
well and should close the issue.

On the question of whether to do more work, it's not clear to me whether
there is wg interest to further investigate the potential impact of such
attacks. At a minimum, I think we should separate this question out for the
wg. If there is enough interest and people willing to put in the effort,
then I can't imagine why a new issue couldn't be used to dig deeper.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Sep 2020 14:44:10 -0700

> we land editorial change. However, I'm conscious of the extra work this

The process needs to work for us here, not constrain us. Why not just
create a new issue that is editorial about documenting this and we can then
land the PR against that.

> more in this space but until someone does the work, we won't know.
>

I would phrase the situation a bit differently:
- We know this attack exists and as a general matter it appears possible to
craft mostly attacker-controlled packets.
- We have some candidate countermeasures which are somewhat invasive in
terms of protocol engineering but should have minimal performance
consequences.

What we don't know is the size of the set of potential victims for this
attack because it depends on the ambient network environment. So yeah,
someone would have to do that work, but I don't think the right resolution
is just to presume this is a non-issue until that happens.

-Ekr

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 5 Sep 2020 00:32:52 +0100

Hey EKR,

> land the PR against that.

PR #3996 in its current form steps beyond editorial because it introduces
normative language. So to make it editorial we'd have to ask Martin to do
some work to split things. I don't know if that might be easy or it's hard.
We'll also be asking the people who have reviewed this PR already to take
another look.

> - We know this attack exists and as a general matter it appears possible
> to craft mostly attacker-controlled packets.

I apologise but I don't fully understand how the set of potential victims
relates to the countermeasures. Are you saying that the assumptions made in
the PR may not hold and therefore invalidate some of the presented
countermeasures?
If that's not the case, and you think the countermeasures are ok but that
the QUIC spec should do more, I don't see that as a need to block adding
this text -- given that others have indicated they are happy with it.

Cheers
Lucas

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Sep 2020 17:26:32 -0700

On Fri, Sep 4, 2020 at 4:33 PM Lucas Pardue <[email-masked]>
wrote:

>> My understanding is that the issue says "document the attacks and add
>>> some small mitigations". The PR lays out the attack(s) and provides some
>>> basic countermeasures. My impression is there might be opportunity or need
>>> to do more in this space but until someone does the work, we won't know.
>>>
>>
> this text -- given that others have indicated they are happy with it.

I don't think I understand the question you are asking.

What I am saying is that the countermeasures described in the PR will not
in practice prevent attacks based on spoofed migration. Specifically, an
implementation *could* choose to probe before sending to the new address,
but as the PR notes this will have negative performance impacts, so
implementations likely will not. Therefore this leaves a large window for
attack with the specification as currently written.

Assuming that that is correct (and it seems to me that the PR says it is),
we can do one of two things:
1. Add more technical countermeasures
2. Decide that even though we know you can mount this kind of attack with
QUIC, it's not that useful an attack in practice (which goes to the size of
the victim set).

Again, I don't object to landing this text, but I do not believe that it
fully addresses the issue, so we still need to discuss that.

-Ekr

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 5 Sep 2020 16:19:49 +0100

> fully addresses the issue, so we still need to discuss that.

Thanks for the added detail. Since you're happy with the current text in PR
3996, I genuinely think it would be clearer for the WG to capture your
suggested options in a new issue with a narrower focus of discussion. We
can make that a prerequisite action to closing issue 3995.

Cheers
Lucas

---

From: Ian Swett <[email-masked]>
Date: Sat, 5 Sep 2020 15:36:15 -0400

I realize this comment is very late, but I re-read the PR to better
understand EKRs comments and I'm concerned about a newly introduced SHOULD
NOT:

"Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame
from
one server address in an Initial packet that is sent to a different server
address."

I believe this greatly limits the value of NEW_TOKEN for anyone not using
anycast DNS.  If 0-RTT resumption succeeds, but there's no token, then the
response is limited to a few packets  I realize there are suggestions on
cases when it may be OK to send the Token to a different address, but they
seem quite narrow and I don't think in practice they cover a case a CDN
decides to send traffic for foo.com to New York instead of Chicago due to
load/latency/etc.

I'm also not convinced this is a very practical attack given the client
puts 8+ bytes into it, but I'd rather understand the implications of this
text first, since they seem fairly serious to me and substantially more
restrictive than what Chrome does today for draft 29.

On Sat, Sep 5, 2020 at 11:20 AM Lucas Pardue <[email-masked]>
wrote:

>> Assuming that that is correct (and it seems to me that the PR says it
>> is), we can do one of two things:
> Thanks for the added detail. Since you're happy with the current text in
> PR 3996, I genuinely think it would be clearer for the WG to capture your

---

From: Ian Swett <[email-masked]>
Date: Sat, 5 Sep 2020 20:17:33 -0400

> one server address in an Initial packet that is sent to a different server

In the interest in moving this along, I'd suggest "MUST NOT send a token
received in one address space to IPs within another address space." and
cite RFC4291, RFC1918, and RFC4193.  If we think this is a real threat, I'd
prefer a MUST NOT with a clear definition of when this is ok over a SHOULD
NOT.  As I mentioned in the PR, I'd also prefer this statement be present
in the earlier text discussing re-use of tokens, opposed to only the
security considerations.  I have no objection to duplicative normative
statements in security considerations, but only putting them there risks
implementers missing them.

A similar concern was raised previously by Igor Lubashev, sorry for missing
that.

>>> If that's not the case, and you think the countermeasures are ok but
>>>> that the QUIC spec should do more, I don't see that as a need to block
>>>> adding this text -- given that others have indicated they are happy with it.
>>>>
>>>
>>> What I am saying is that the countermeasures described in the PR will
>>> not in practice prevent attacks based on spoofed migration. Specifically,
>>> an implementation *could* choose to probe before sending to the new
>>> address, but as the PR notes this will have negative performance impacts,
>>> so implementations likely will not. Therefore this leaves a large window
>>> for attack with the specification as currently written.
>>>
>>> 2. Decide that even though we know you can mount this kind of attack
>>> with QUIC, it's not that useful an attack in practice (which goes to the
>>> size of the victim set).
>>>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 07 Sep 2020 11:50:21 +1000

On Sun, Sep 6, 2020, at 10:17, Ian Swett wrote:
> I realize this comment is very late, but I re-read the PR to better understand EKRs comments and I'm concerned about a newly introduced SHOULD NOT:
> 
> > "Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from
> In the interest in moving this along, I'd suggest "MUST NOT send a 
> token received in one address space to IPs within another address 
> space." and cite RFC4291, RFC1918, and RFC4193.

The thing you are concerned about losing here is one round trip worth of advantage over the 3x anti-amplification limit when the client sends 0-RTT toward a new server address.  Creating an exception here leads to all sorts of fuzziness in the same way that we have fuzziness around changes of address for NAT rebinding.  People do deploy vulnerable services using global address space.

Can I request that we open a separate issue for this?  I don't think that Ian's suggestion is necessary, but it seems like we might need to do some rapid hand-waving here.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 07 Sep 2020 11:59:30 +1000

On Sun, Sep 6, 2020, at 01:19, Lucas Pardue wrote:
> > Again, I don't object to landing this text, but I do not believe that it fully addresses the issue, so we still need to discuss that.
> 
> Thanks for the added detail. Since you're happy with the current text 
> in PR 3996, I genuinely think it would be clearer for the WG to capture 
> your suggested options in a new issue with a narrower focus of 
> discussion. We can make that a prerequisite action to closing issue 
> 3995.

I think that this is fine, but I'm going to suggest that we close that issue with no action.

What this asks is for some indistinct and therefore unbounded research to occur in order to satisfy ourselves that server deployments aren't vulnerable to this sort of request forgery.  I would prefer, as I proposed in the pull request and original issue, that we let server deployments manage this risk.

This specific issue only affects people deploying servers that might need to handle NAT rebinding from clients.  If those servers are deployed in privileged locations and can access UDP services that might be vulnerable to request spoofing, then my position is that people can not deploy QUIC in those environments.

The risks here are different than for clients (which also includes entities that assume a server role in peer-to-peer) where the deployments are likely to be far less controlled.

This just isn't worth delaying this process further.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 7 Sep 2020 14:56:02 +0300

Hi,

On 2020-9-5, at 18:19, Lucas Pardue <[email-masked]> wrote:
> Since you're happy with the current text in PR 3996, I genuinely think it would be clearer for the WG to capture your suggested options in a new issue with a narrower focus of discussion. We can make that a prerequisite action to closing issue 3995.

based on the follow-on discussion on this thread, we've decided to go forward with this, i.e., merge 3996, close 3995 as a consequence, and require any additional desired changes to go through a new issue for clarity.

Thanks,
Lars

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Sep 2020 15:42:52 -0700

OK. I'll file a new issue soon (probably tomorrow)

-Ekr

On Mon, Sep 7, 2020 at 4:56 AM Lars Eggert <[email-masked]> wrote:

> > Since you're happy with the current text in PR 3996, I genuinely think
> it would be clearer for the WG to capture your suggested options in a new
> issue with a narrower focus of discussion. We can make that a prerequisite
> action to closing issue 3995.
>
> based on the follow-on discussion on this thread, we've decided to go
> forward with this, i.e., merge 3996, close 3995 as a consequence, and
> require any additional desired changes to go through a new issue for
> clarity.
>
> Thanks,
> Lars
>