Subject: Spoofed Initial packets

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 15:41:10 +1100

Issue 1951 - https://github.com/quicwg/base-drafts/issues/1951 -
raises the question: what happens if you receive a badly formed
Initial packet after moving on to Handshake (or even 1-RTT) packets?
By the processing rules, you might generate CONNECTION_CLOSE.  But
that gives an attacker a fairly good opportunity to disrupt new
connections.  They don't need to race packets; sending a bad Initial
packet within 3RTO is much easier than winning a race.

I've opened a PR that implements Marten's suggestion from Bangkok:
https://github.com/quicwg/base-drafts/pull/2045

That PR implies some special rules around discarding Initial keys,
which is a non-zero cost.  The advantage is that once you have started
to use Handshake keys, spoofed packets are no longer able to disrupt
the connection.

When Marten Seeman presented we had 2 minutes, so this discussion
never terminated.  We got enough time for Kazuho to voice opposition
to making any changes and nothing more.  Kazuho now thinks this is a
good idea.

Should we take this, or should we leave this unspecified, and leave it
to implementations to classify and ignore bad Initial packets?  We did
previously discuss discard rules for keys and decided to keep the spec
simple (that was in Montreal, I think).  Specifically, we agreed not
to optimize for this case.

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Nov 2018 13:55:37 +0900

> to making any changes and nothing more.  Kazuho now thinks this is a

In Bangkok, my complaint against the idea was (is) that it revisits
our previous consensus in Kista to use explicit ACKs, and that the
change was groundless because QUIC stacks that are interested in
having countermeasures against Initial packet injection can implement
that regardless of what the specification says.

What I missed was the fact that the proposed approach is a
simplification for QUIC stacks that try to implement countermeasures.
Just dropping Initial packets once the handshake keys are obtained is
much easier than validating Initial packets to determine if you need
to send ACKs.

Generally speaking I am in favor of having a protocol resistant to
attacks, and considering the fact that the proposed change is easy to
implement, I am favor of adopting the PR.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 00:46:18 -0800

I know a lot of people are against implicit ACKs but it is also widely
understood that some attacks are hard to handle without implicit ACKs (in
handshake).

I don’t really understand the objections to implicit ACKs my guess are one
of:

1) unnecessary optimization / complication (but that predates attack
discussion)
2) we don’t try to protect the handshake disruption aggressively (but now
we do, if not too hard)
3) too late in the process vs. complexity
4) impact on congestion window and RTT estimates unclear
5) an attacker would need to be able to observe the path (but that only
require one compromised computer on a LAN)

Either way, I’m all for preventing DoS attacks on the handshake that are
easier for the attacker than brute force bandwidth saturation, and
especially those that are easier than racing packets.

Without mitigation, an attacker that is able to infects a single computer
on a LAN could censor connections to certain locations relatively
undetected without flooding the network. It would also be possible to
suppress security alerts and software updates aimed at protecting against
new viruses.

Mikkel

On 26 November 2018 at 05.56.03, Kazuho Oku ([email-masked]) wrote:

-- 
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 26 Nov 2018 19:54:54 -0800

This does stomp on our previous consensus to not do implicit acking, but I
don't think we had considered this attack at that time. We decided to do
what DTLS did: drop the keys after a timeout.

I'm in favor of this change, but we should explicitly describe the implicit
acking in the TLS draft, and why we believe it's safe to do it.

---

From: Ian Swett <[email-masked]>
Date: Thu, 29 Nov 2018 21:52:21 -0500

I expect implicit ACKing of Initial to be implemented by all(or almost all)
implementations, so the marginal complexity is very small.

The benefit is potentially substantial, since it closes off post-handshake
injection attacks.  Additionally, as Martin explained to me over VC, the
status quo requires implicit ACK, but it's not clearly documented, since
it's unclear what to do when the keys are dropped, but there's still
outstanding data at an encryption level.

That being said, I think the PR isn't quite ready yet, so I'll work with
Martin and others to improve it.

On Mon, Nov 26, 2018 at 10:55 PM Jana Iyengar <[email-masked]> wrote:

> don't think we had considered this attack at that time.. We decided to do
> I'm in favor of this change, but we should explicitly describe the
> implicit acking in the TLS draft, and why we believe it's safe to do it.
>
> On Mon, Nov 26, 2018 at 12:46 AM Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>
>> I don’t really understand the objections to implicit ACKs my guess are
>> one of:
>>