[Tcpcrypt] attack resilience (was "v3 of the charter")

[Erik Nygren <[e-mail]>]

At what stage should we discuss attack resilience, and in particular the
ability of one end-point to launch an asymmetric resource DDoS attack
against the other end-point?  This has historically been an area where
remediations have been critical for both TCP extensions as well as for
crypto systems.  Just look at SYN flood attack mitigations (eg,
SynCookies), the failure of TTCP and the additions to TFO to address those
gaps, the need for tokens in the DTLS handshake, and especially the
challenges in defending servers exposing TLS to DDoS attacks.  Mitigations
need to be traded off against added round-trips as well as privacy
exposures.

Should there be a line-item in the charter on this topic, or should this be
covered in post-charter discussions?

For example, a client clearly must not be able to force a server to do
expensive crypto operations until there has at least been one packet
handshake.  End-points under duress can also presumably chose to fallback
to plaintext TCP (although this could motivate an attacker to try and force
end-points into this mode).  Optional proof-of-work client puzzles (when
under duress) are also an option, but add complexity and potential risks in
regimes outside of client:server uses of TCP.

    Erik