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

From: Erik Nygren <[email-masked]>
Date: Fri, 2 May 2014 09:41:37 -0400

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 May 2014 08:04:39 -0700

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:
> 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?
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>