Subject: [quicwg/base-drafts] Guard initial packet against amplification attack via compression (#596)

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 07:55:00 -0700

If an attacker has access to a network with efficient IP payload compression, it may be comparatively cheap for the sender to transmit Client Initial packets even if the packets are required to be 1280 bytes long. This can be mitigated by replacing padding with random data, or a some pattern that is not trivially compressible.

I am not familiar with options today, but the following RFC do discuss such a compression technology, and other options may appear in the future:
https://tools.ietf.org/html/rfc3173

-- 
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/issues/596

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 08:12:45 -0700

Why do you think that an attacker would want to follow your advice to randomly pad?  I would have thought that allowing randomized data would give them a greater advantage in constructing a packet that is otherwise valid, but that decompresses to something insane.

FWIW, I don't think that this is worth worrying about.

-- 
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/issues/596#issuecomment-306517872

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 08:17:06 -0700

It would be a pseudorandom verifiable sequence, such as the fibbonnachi sequence of some initial seed.

I don't know if this is worth worrying about or not, I am just raising the potential issue. Attacks appear to come frome the most unexpected angles.

-- 
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/issues/596#issuecomment-306519296

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 08:25:12 -0700

Related: there may be other ways to deal with this, such as proof of work instead of large packet size, but that obviously has its own issues.

-- 
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/issues/596#issuecomment-306521997

---

From: ianswett <[email-masked]>
Date: Tue, 06 Jun 2017 14:28:54 -0700

To clarify, you're imagining an attacker behind a proxy which compresses packets?  Given the vast majority of packets flowing through 443 are encrypted, and a large portion of the rest is the TLS handshake(which encrypts poorly), I'm not sure why one would deploy such a proxy?

If there is no reason to believe this sort of proxy is common, I would tend to agree with Martin that this isn't worth worrying about.

-- 
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/issues/596#issuecomment-306622855

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 15:38:31 -0700

I am, for example, imagining a large cloud hosting environment with high bandwidth compressed backbone for inter-datacenter links. You could feed outbound traffic at high rates that condense at server elsewhere. Such a backbone would have no concern for port 443 at the point of compression and if a common server vulnerability was found, many hosted services could join in a DDoS attack.

For comparison, some storage networks for iSCSI do terminate TCP connections near sender and internally transfer packets using larger MTUs and possible with hardware compression to move large data volumes over a distance.

Still, I am no saying this is a major concern, just pointing out the possibillity.

-- 
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/issues/596#issuecomment-306637444

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 15:45:46 -0700

Another example would be government controlled internet backbones used in cyber warfare that exploit a backbone compression standard at IP level or below.

-- 
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/issues/596#issuecomment-306638734

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 15:48:04 -0700

https://arstechnica.com/security/2015/03/massive-denial-of-service-attack-on-github-tied-to-chinese-government/

-- 
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/issues/596#issuecomment-306639140

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Jun 2017 08:54:57 -0700

If this is indeed a problem, then it is a generic IP problem.  We need to constrain what it is that we want to solve.  I'm going to risk the wrath of our chairs and close this as out of scope.

-- 
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/issues/596#issuecomment-306839583

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Jun 2017 08:54:55 -0700

Closed #596.

-- 
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/issues/596#event-1113940380