Subject: [tcpinc] Security Considerations (Re: Charter should mention channel binding (Re: why not just TLS on secure port numbers?))

From: John-Mark Gurney <[email-masked]>
Date: Mon, 18 Aug 2014 15:52:07 -0700

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.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Aug 2014 19:14:18 -0500

> 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
positioned adversary can just stop all bits moving for the given
connection or client/server pair.

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.

Nico
--

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 18 Aug 2014 17:27:12 -0700

> 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...

> connection or client/server pair.

Agreed...

> 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...

Not even a reference to TLS's security considerstaions...  Though
RFC5925's security considerations section is useless...  Please read
the whole doc for them (yes, they did call out Appendix D, E, and
F)... :(

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Aug 2014 20:18:21 -0700

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Aug 2014 12:14:58 +0100

Hiya,

> be included in the security considerations section:

Reasonable points, but just one caveat.

I hope we (as a WG) don't go down the road of asking the
authors of the various drafts to make them
section-by-section comparable. The problem with that is
that all the authors are smart folks who'll find a way
to include whatever's required, so the end result would
be a harder choice than we now face, between proposals
where there are few substantive but numerous "style"
differences. That'd also risk adding features that are
not really needed too, though in this case maybe that's
less of an issue.

The above behaviour has been seen before, for me most
recently in the now-closed NEA WG. In the end, that WG
got stuck, despite goodwill and good chairing and had to
ask their AD to just pick a winner, there being no
remaining substantive differences between their two "live"
proposals that affected folks technical opinions.

So I hope (and I think, since I asked 'em:-) the WG chairs
don't want to have that kind of beauty contest.

Cheers,
S.

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 21 Aug 2014 14:47:39 -0700

> to include whatever's required, so the end result would

I'm not says that you MUST address issues, I'm just saying you have to
say if you address the issues, you list it, and if you don't address
it, then you state that it is vulnerable to X...  The point of TCPINC
is security, so we need to make sure we know which proposals address
which issues and how...