hi David, thanks for this message; this seems like a good way forward. Jumping back into the thread, a couple of no-hat points inline...
> On 20 Jul 2015, at 05:31, David Mazieres <[email protected]> > wrote: > > The time to vote on this question is approaching. Forced to vote, I > chose #1 (keep both drafts going for now). But I think we must > appropriately modify the instructions to authors going forward so as to > avoid wasting four months. I agree with this completely -- I support (1) not because it's a good choice, but the less-bad of the two presented. > Keeping the bigger goal in mind, we should vote for the option that > results in the highest fraction of TCP connections carrying encrypted > traffic. The reason I think waiting four months (with the right actions > July 20) could further that goal is that TCPINC is really solving *two* > problems: > > 1. Let application authors adopt encryption even when protocols do not > contain room for negotiation (i.e., can't squeeze in a STARTTLS). > In this case, it is okay to have source code changes. > > 2. Let systems deploy encryption without modifying existing programs > or in cases where for whatever reason TLS does not fit. > > Having the AD just pick a winner tomorrow would be good for goal #1, > because both proposals provide the necessary out-of-band negotiation for > encryption, and an earlier decision would lead to earlier deployment. > However, I believe this would not be good for goal #2, particularly if > we go with TCP-use-TLS, which to my mind is tailor-made for a library > implementation. In fact, I'd go so far as to say that TCP-use-TLS could > actually be *improved* if it weren't hamstrung by the need to maintain > API compatibility with TCP. For instance, without such a restriction, > TCP-use-TLS applications could express information about domain names to > the protocol and benefit from TLS's certificate machinery. > > Tcpcrypt, by virtue of being designed to be implemented in TCP or as a > packet rewriter, is going to be easier to make work in case #2. There's > a reason that so far only tcpcrypt has provided an implementation that > works with unmodified binaries. > > All of this makes me wonder if there might not actually be room for both > protocols on the Internet. With that in mind, if we go forward with > both protocols, rather than charge the two groups with identical > instructions, we should task them with different requirements in the > hopes of getting out a pair of protocols that truly maximizes encryption > of TCP traffic. > > Specifically, suppose we instructed authors of the two drafts as > follows: > > * Tcpcrypt should be modified to provide application-level signaling > for TCP-use-TLS. It already has support for application-aware bits, > which means the draft must evolve to add support for an > "application-prefers-TLS" option and an > "application-declines-tcpcrypt-but-wants-TLS" option. We would > probably rework things so this mode negotiation is cleaner (a byte > with various option bits). This instruction also has the nice property that it supports the long transition from goal 2 to goal 1: protecting the confidentiality traffic of an application protocol while it transitions to providing confidentiality and authentication itself. > * TCP-use-TLS should be freed from the notion that it someday needs to > live in the TCP stack, and should therefore be optimized for a > library implementation. It's goal should be to achieve the best > design possible *with API changes*. So I'm not *quite* clear as to what you mean by "with API changes" here. What I think you mean is that there would be an additional API available to provide an environment between "it just works out of the box if you link it with a different library, allowing applications to 'ease in' to using TLS. If that's what you mean, then I would be very much in favor of it, as it leads to a design with an explicit provision for transition. > These goals can be furthered without making the two protocols dependent > on each other's success. ...though I would observe that the TCP options footprint used by the two protocols seems to have converged to having more or less the same properties in the face of middlebox interference; there may then be some advantage to both proposals using a common set of behaviors to fall back and work around here. This is perhaps bit much of an optimization at this point in time, but the point is there may be areas of common work between the two protocols... Thanks, cheers, Brian > The tcpcrypt protocol can make support for > TCP-layer encryption a SHOULD rather than a MUST, so that if TCP-use-TLS > end up far more popular, people don't have to stick the rest of tcpcrypt > into their kernels. Likewise, if tcpcrypt turns out to be preferable in > practice, people don't have to link their applications with the > TCP-use-TLS library. > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
