ACK validation during handshake

[mikkelfj]

How to ignore early packets without getting in conflict with requirement to drop connection on invalid ACKS:

During handshake a lot of packets may be silently ignored - either because they do not match the current state and could be from an adversary but could also be spurious retransmissions no longer relevant, or because of races where future protected packets races in front of a handshake and we dont' want to reserve a lot of, or any, state to packets we cannot verify immediately.

Keeping state of the dropped packets might be counter-productive - notably an adversary might shadow out valid packets by simply having a cleartext packer ignored. On the other hand dropped packets might be perfectly valid such as 1RTT protected, we just don't know it yet, and don't want to allocate a lot of state to find out later.

I suggest that ACK ranges received for untracked packets are ignored (not the entire ACK frame or packet). This means RTT estimation will remain unaffected and the connection will be vulnerable to attempts to suppress connection establishment.

A related issue is how to count MAX_DATA in this scenario, but I haven't thought much about this.

This very lengthy discussion on pull request is about when a connection SHOULD be upset with receiving unexpected ACKS, but does not really deal with the above issue: #565

[martinthomson]

Based on the principles in #645, I propose that we continue to validate ACK frames as normal AND drop the connection if they are invalid. If an attacker wants to disrupt the connection at this point, they are welcome to do so.

This includes ACK frames that acknowledge packets that were encrypted. If those arrive in cleartext packets, (a name we should retain even after #693), they are invalid and the connection is bad. As someone (Ian, I think) pointed out on another thread, at the point you discover that the ACK is bad, you might have processed a bunch of other frames, and backing out changes (particularly to TLS) is very difficult.

Dropping the connection is the most robust response. It also increases the chances that faults are discovered, absent the Alt-Svc curse.

[martinthomson]

With removal of timestamps from the ACK frame, safeguards on the use of the ACK delay field, and we decided not to worry specially about attacks on the handshake of this sort.