Hi Watson. The charter calls for the group to “develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams” and “define an unauthenticated key exchange mechanism." This pretty much calls for design by committee.
As for shortcomings of tcpcrypt, there are two varieties to these shortcomings: Security shortcomings - here I wholeheartedly agree that security mechanisms are best developed by one or a few of the right people, with everybody else just examining and looking for issues. That’s why in CFRG we’re not designing curves be committee, but arguing the pros and cons of several proposed curves. Similarly here, all proposals have their own key exchange and crypto mechanisms, and the discussions of the group are not designing them, merely comparing them. Deployability shortcomings - this is where claims are made in the vein of “your proposal works well in the lab, but it won’t work in this or that scenario in the real world.”, or “when blocked, your proposal does not fall back gracefully to unencrypted”. Unfortunately the Internet is full of boxes that don’t behave the way we expect them, and you do need a committee to consider all of the ways a connection might be broken because of deploying the proposed mechanism. The obvious ones are NAT devices and firewalls, but mandatory proxies are not far behind in the amount of trouble they cause. You can see a lot of that in httpbis, and some of that in TLS’s 1.3 discussion. It’s not very pretty, but it turns out to be necessary to get something widely deployed. Yoav On Aug 2, 2014, at 9:46 PM, Watson Ladd <[email protected]> wrote: > Dear all, > > We seem to have a charter. > We seem to have a working implementation: tcpcrypt. > 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? > > Sincerely, > Watson Ladd _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
