On Fri, Jul 17, 2015 at 10:37 PM, Andrea Bittau <[email protected]> wrote: > I think that we can make progress as long as the format of the meeting > isn't: > > > "Here's TLS-option ; Here's tcpcrypt ; Which should we use?" > > > Even though it's been a long stalemate, tcpcrypt itself did benefit from the > WG > > and some progress has been made. For example, at IETF 91 we (the WG) > decided > > not to MAC the header. At IETF 92 we decided to use TLV. Both resulted in > new > > tcpcrypt drafts and code. I hope that at this IETF we can continue this > design > > effort, though in a more concentrated way. > > > It's clear that by November the WG needs to produce a substantial result and > not > > just keep debating. I suggest that we use this meeting to define this > result. > > Specifically, we should: > > > 1) Define what we want from TLS-option (e.g., a profile?, code?, etc.). > > > 2) Define what we want from tcpcrypt (e.g., some handshake feature?). > > > 3) Discuss a generic "start encryption" TCP option that can select any > > tcpinc protocol. > > > For both #1 and #2 we should spend time designing and discussing the > > protocol (as if it were the only contender) to see WG dynamics when > asked to > > work on a specific protocol. > > > The protocols can then be developed in the coming months and in November we > can > > check to see if one result is superior. If none is, the generic "start > > encryption" option might be the best way forward, leaving it to natural > > selection to decide which particular encryption option becomes most popular.
This option has serious costs: it forces operating systems to ship both stacks for compatibility reasons, and delays widespread adoption and use even further. I used to think Buridan's Ass was a fable. Now I realize it was prophecy. > > > On Fri, Jul 17, 2015 at 1:01 PM, Stephen Farrell <[email protected]> > wrote: >> >> >> >> On 17/07/15 18:31, Joe Touch wrote: >> > >> > I see your point, but would include other context in comparing the two >> > approaches - e.g., based on well-established mechanisms vs. not, not >> > implemented but relatively clean interaction with TCP vs. not, which >> > puts them on a much more equal footing (which is part of why the WG has >> > not converged). >> >> Yep, that's fair, I wasn't trying to include all context and the above >> points are clearly why deciding has been hard. My point though against >> option 1 is that deciding won't get easier in 4 months. >> >> S. >> >> _______________________________________________ >> Tcpinc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc > > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
