On Mon, Aug 18, 2014 at 5:27 PM, John-Mark Gurney <[email protected]> wrote:
> Nico Williams wrote this message on Mon, Aug 18, 2014 at 19:14 -0500: > > On Mon, Aug 18, 2014 at 03:52:07PM -0700, John-Mark Gurney wrote: > > > John-Mark Gurney wrote this message on Mon, Aug 18, 2014 at 15:42 > -0700: > > > > I have reviewed the security considerations on the other proposals, > > > > and I must say that they need to be fleshed out... The TLS one is > > > > especially lacking in details... It says nothing about various > attacks > > > > that it is vulnerable to... The others aren't much better... > > > > > > Just for the proposals, I feel that a minimum of the following should > > > be included in the security considerations section: > > > > > > 1. What happens upon spoofed packets, including fake and replayed > > > packets > > > 2. What happens upon deleted data > > > 3. How are attackers able to force close your connection, if any. > > > > > > I'm sure others have ideas of what should be included. > > > > Requirements are needed too. > > > > I realize now that we can't expect to defend well against RST attacks, > > as they are a DoS attack after all. A sufficiently well-equiped and > > There are mitigation tecniques, like timeout for unauthed RST and > the like... > > > positioned adversary can just stop all bits moving for the given > > connection or client/server pair. > > Agreed... > > > I'm having a harder time with confidentiality-but-not-integrity > > protection for the octet streams though. IMO integrity protection for > > the octet streams has to be a requirement, so that the answers to (1) > > must be "replays are detected and dropped" and "fake segments are > > dropped", while the answer to (2) must be the same as for plain TCP. > > Agreed, but some of the proposals like TLS's has nothing of the > above, and I just want to make sure that we have a minimum of what > must be said about how each proposal handles various attacks... > > For example, the only thing that the TLS's proposal says in it's > security considerations section is that it's vulnerable to attack > because they can remove the TCP-TLS option... Nothing about spoofed packets, or dropped packets, etc... > Spoofed/modified packets are covered Section 4: http://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-00#section-4 Dropped packets don't have any real impact, since TCP retransmits. I don't generally find it's that helpful to bundle all the security considerations at the end. As I said, I'll be happy to beef this up in future drafts. Note that this is a -00. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
