Subject: Re: Spoofed Initial packets

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Dec 2018 18:31:49 -0800

On Thu, Nov 29, 2018 at 6:52 PM Ian Swett <ianswett=
[email-masked]> wrote:

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

It's not clear to me that its possible to have inconsistent implicit
ACKing. Do we have a demonstration that that's correct.

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.
>

I don't think that this is right. The connection will just fail in this
case, which is fine.

-Ekr

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:
>
>> 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.
>>
>> On Mon, Nov 26, 2018 at 12:46 AM Mikkel Fahnøe Jørgensen <
>> [email-masked]> wrote:
>>
>>> 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:
>>>
>>> 2018年11月26日(月) 13:41 Martin Thomson <[email-masked]>:
>>> >
>>> > 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.
>>>
>>> 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.
>>>
>>> >
>>> > 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.
>>> >
>>>
>>>
>>> --
>>> Kazuho Oku
>>>
>>>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 12 Dec 2018 18:15:18 -0800

> I don't think that this is right. The connection will just fail in this

Just so I understand you: are you suggesting that we close the connection
if this timer to drop the keys fires?

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