Subject: Re: Consensus call for Late-Stage documents, pre-IETF 108 edition

From: Christian Huitema <[email-masked]>
Date: Tue, 1 Sep 2020 00:20:04 -0700

On 8/31/2020 11:42 PM, Martin Thomson wrote:
> Let's not try to design a complicated solution for a problem that is - as yet theoretical.  As I said when I raised the issue, I'm not aware of any service that might be vulnerable in this way.
Yes indeed.
>
> Ekr's suggested design is good, but it is more complexity, and it requires a fairly significant amount of surgery for a case that will not be exercised often.  We would have to find extra bits in the header, define new fields, and then apply additional processing to packets.  If this were TCP, I'd argue we have to do something; TCP full of boxes that apply the Robustness Principle well beyond its intended meaning.  For UDP, we have no direct evidence of attack.
>
> In addition, as noted, the worst attack is the spoofed migration, which only affects server deployments.  My expectation is that servers will be more able to implement defenses for adjacent services before deploying QUIC.  A note in the manageability or applicability documents regarding this might help if someone were so inclined. 
Yes.
>
> I'm going to propose being much clearer about the fact that we're not designing a robust defense against request forgery attacks into the protocol.  We could, following the suggested design, but I would prefer to finish the protocol than spend another few months doing that.
>
> On Tue, Sep 1, 2020, at 14:31, Christian Huitema wrote:
>> A "defensive" peer can also advance the sequence number by some random
>> value before sending packets to a not-yet-validated address. As the
>> sequence number is injected in the IV, this will make the ciphertext
>> much harder to predict without causing a lot of transmission overhead.
> You need to skip at least N^2 packets where N is the number of attempts the peer might have to perform a spoofing attack.  Right now, that number is based on the initial window, or maybe the existing congestion window, plus maybe some packets sent on PTO, which is to say ¯\(°_o)/¯.  And with small safety margins, you probably need extra to guard against multiple tries.  Our packet numbers only go to 2^32, which gives us less than 2^30 as a maximum gap, and so we have much less entropy than we typically require for path validation (2^64 is our baseline for both ODCID and PATH_CHALLENGE).

Yes, but we are not dealing with path validation. Defenses like PN skip
force the attacker to spoof a large number of packets in order to get
one predicted output. The attacking server has just one preferred
address try per connection, so even simple defenses will work. An
attacking client would have more possibilities, but that's still very
limited if servers limit the frequency which will they try to follow NAT
traversal.

But as Kazuho and Igor pointed out before, there are simple defenses
against spoofing internal addresses on the server side. I agree that we
should not try to engineer this.

-- Christian Huitema

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Sep 2020 16:27:27 +0300

Hi,

On 2020-9-1, at 3:11, Lucas Pardue <[email-masked]> wrote:
> Proposals 3945 and 3990 received some comments but we think we're close to addressing those and that they'll have consensus very soon.

I've updated 3945 to restore the MUST that was changed to a SHOULD, which I think was the last contentious point: https://github.com/quicwg/base-drafts/pull/3945

Lars

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Sep 2020 11:16:45 -0700

On Mon, Aug 31, 2020 at 9:31 PM Christian Huitema <[email-masked]>
wrote:

> On 8/31/2020 9:00 AM, Eric Rescorla wrote:
>
> > I wanted to add that there is a pretty straightforward mitigation for
> > the false migration version of this (sorry if this was suggested on
> > the thread, but I don't recall): prior to having validated the
> > address, the sender prepends a random value M to the packet (e.g.,
> > between the number and the payload). M is used to randomize the
> > ciphertext [0]. We can borrow a bit from the reserved bits in the
> > header to indicate this and because it only needs to be done prior to
> > probing, overhead should be acceptably low. This only addresses the
> > forged content attack not the forged DCID attack, though if we were
> > serious we could actually provide a defense against that as well by
> > having *all* pre-validation packets have a randomizer; this would be a
> > larger change, of course.
>

Perhaps. This is pretty low entropy and I'm not sure how big a deal
transmission overhead is here.

Incidentally, MT and I talked this over yesterday and came to the
conclusion that under the (strong,
but not totally implausible) assumption that the attacker can control the
entire plaintext, then they can
probably control nearly all of the short packet. Specifically:

- They can control the DCID
- They can control the ciphertext by means of the plaintext
- They cannot control the authentication tag
- They can control the encrypted bits of the first byte and the PN by
mutating the plaintext until they get an auth tag (and hence the header
encryption) until they get a desired value [this is possible because the
amount of data to be encrypted is short and so a result can be obtained in
a reasonable number of trials]

Effectively, this leaves some of the bits of the first byte which are
predictable but not controllable and then the auth tag which is predictable
but not really controllable (though the attacker can set a few bits by the
plaintext mutation trick). Whether this is enough depends on the protocol
being attacked, but the presence of some uncontrolled bits need not to be
prohibitive because the attacker can construct the rest of the packet to
have them interpreted in some "safe" fashion (similar techniques are
already in use for constructing hash collisions and malware payloads).

Of course, this doesn't tell us whether this is a serious attack or not,
but I generally think that we should not assume that it will not be
possible to craft a given UDP packet via QUIC.

-Ekr

-Ekr