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

IMO, the point below is a useful way to compare candidate approaches.

These all fall under effectiveness and cost, and we don't need the 
charter to state such to consider those issues.

Joe

On 5/2/2014 6:41 AM, Erik Nygren wrote:
> 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
>
>
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>