On Sat, Aug 2, 2014 at 4:09 PM, Stephen Farrell <[email protected]> wrote: > > Watson, > > On 02/08/14 19:46, Watson Ladd wrote: >> design by committee? > > I guess you're using the above as a short-hand for the various > ways in which IETF WGs, or maybe any set of people, can screw up. > If so, that's ok-ish. > > However, I've also seen people use that phrase without any > understanding of how the IETF works, where they really seem to > believe they're dealing with a Robert's Rules clique sitting > around a table and not with a mailing list where what's required > is to make technically sound points in your emails, and nothing > else. > > I think it'd be better if we all here kept the latter to the > forefront of our minds and didn't get all wrapped up in the > problems of non-existent committees.
I'm using to refer to the failure mode where a group, rather than an individual or small team, tries to do something. Any fool can write data in a CSV. It takes a small group of fools to make an XML schema for the same data, and a slightly larger one to make ASN.1 instead. The reasons for this are of interest to psychologists and management consultants. > And speaking of which... > >> Why don't we attempt to determine which shortcomings need to be >> addressed and how to fix them with tcpcrypt, instead of design >> by committee? > > The WG now has four proposals to deal with. In a way that's a good > thing as it indicates a level of interest from serious proponents > of each of the solutions. It clearly does make the WG's task more > complicated though. Fairness requires a bit of due diligence before > down-selecting to one starting point for the WG. ISTM that the > chairs are doing that and without delay. What are the four proposals? What are their merits? As I see it the following have been discussed: -BTNS IPsec -tcpcrypt -using TLS in an unauthenticated mode with TCP signalling the initiation. The downfall of the first one is the need for open IKE ports, and some issues I don't understand about how IPsec works internally and NATs. (Something about colliding SAs, but I am probably totally off base here). The advantage is that this is already in the kernels: probably shorter path to turning on. It also has a latency hit: an IKE exchange before opening a TCP connection. The second one is implementable and deployable. It has the disadvantage of not being deployed yet, and the crypto could stand some major improvements: I've only just begun to look at it, and parts of it seem insecure. (Poly1305 MAC eats a nonce. Where is this nonce? It's not a PRF: does this break the XOR scheme? Note the security proof doesn't apply in this case) The third one has a major latency hit because TLS requires superfluous rounds of negotiation. Furthermore kernels are not going to put OpenSSL inside, so we need to implement a fairly complex protocol. The promised improvements to TLS 1.3 don't help: they rely on session caches unnecessarily. It does however get through firewalls that don't inspect the protocols above TCP, and the crypto is (thanks to the NSA) secure. Of these three proposals the first one will never traverse all firewalls. The third one is going to get a flat "No" from lots of people. What am I missing? Sincerely, Watson Ladd > > S. > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
