On Jul 31, 2015 3:38 AM, "Stephen Farrell" <[email protected]> wrote: > > > As previously stated I think tcpcrypt is a better starting point > for tcpinc. > > For those confused about this poll, I'm not sure if this will help > but when we hummed in the room about which document to start from, > and the chairs didn't see rough consensus in the room, they were > asked to confirm that lack of consensus on the list. I believe this > poll is just that - to confirm that we don't have rough consensus > for one or the other. Assuming we still lack rough consensus, then > the WG I guess starts down the road covered by all the later > discussion in the room about stuff to do between now and Nov (that > is IMO hugely likely to end in a coin-toss;-(). > > My justification for wanting to start from tcpcrypt is in the end > down to the additional genetic diversity that would result. I think > we'll end up with almost exactly the same functionality regardless of > the starting point we choose but that starting from tcpcrypt has the > benefit that we're less likely to get the same protocol or ciphersuite > or implementation problems in both TLS and TCPINC at the same time. For > me, that means that TCPINC-starting-from-tcpcrypt is more likely to be > a backup for TLS for when stuff hits the fan again, which I think is > something beneficial, as stuff will always eventually hit the fan. > > Other than the genetic argument, I think most of the other arguments > for one or the other are not compelling. In particular, the "we've had > TLS for 20 years" one really does not apply here - TCPINC-starting- > from-TLS will be based on TLS1.3 which is brand new. > > It is true that TLS1.3 will have a *lot* more expert eyeballs looking > at it over the coming year or two, but that is something that's mostly > still to happen, but has not yet happened. So while I think it is true > that starting from TLS will ensure better and deeper security analysis, > that is not something we already have by any means.
No amount of expert review can make up for the harm of extra complexity, and I feel there's an unusual amount of forbearance being practiced to keep TLS in the running. We're being promised a simpler profile, with no sign of one. We're promised a way this will interact with traffic already TLS encrypted, with little explanation of why tcpcrypts solution is inadequate. Not all IETF protocols had equal security failures. SSH doesn't have any of the negotiation issues TLS is plagued with, because it's designed better. Plenty of TLS issues were identified and ignored, even as chances to fix them passed. Neither of them correctly understood symmetric key crypto when originally designed. > I also dislike the argument that tcpcrypt or TLS1.3 is new and > therefore more likely flawed. Since that argument applies equally to > both proposals, it is not useful for selecting a starting point. > And the IETF either is or is not able to design security protocols > well. If we can then we can do TCPINC based on either starting point. The question isn't "can you design a security protocol": tcpcrypt is already designed, and secure. Its "Can you refrain from screwing it up?". If people think there are problems, find them. > > If the IETF cannot design security protocols, then we should not be > doing TLS1.3. My belief is that we are far better now at designing > security protocols than we were 20 years ago, mainly due to the fact > they they are really widely used now, but then I would say that > wouldn't I:-) > > Lastly, from a purely IETF process perspective I would also prefer to > not see TCPINC and TLS1.3 tightly coupled. Timing and personnel issues > like that can lead to delay and friction. I'd hope that'd not happen > here, but even if not, I think that TLS1.3 is so important right now, > that I would prefer to not see TCPINC affect that work at all. Starting > from tcpcrypt is better from that POV. (Note though, that this is a > really weak argument that's only worth mentioning if you believe as I > do that either proposal is ok as a starting point.) > > Cheers, > S. > > > On 24/07/15 10:16, Martin Stiemerling wrote: > > > > Dear all, > > > > **Please use this CORRECTED version, as one option to choose from below > > didn't make it into the original.**** > > Thanks to Erik Rescola for pointing this out to me directly. > > > > This point got lost on the mailing list, but it has been decided in the > > WG session here at IETF-93 that there will be a Last Call for consensus > > about which document of the below ones to take as starting point for the > > WG. > > > > > > Here are the two drafts: > > a) draft-rescorla-tcpinc-tls-option-03 > > b) draft-bittau-tcpinc-tcpcrypt-03 > > > > Please respond to the tcpinc wg mailing list until > > > > July 31st, 2015 > > 1pm CEST > > > > on wether you prefer > > - either draft a) or b) > > - both drafts (a & b) as WG items > > - or none > > > > to be accepted as WG item(s). > > > > Please write also your brief reasoning on why you made your choice. > > > > Please note that accepting a draft is not the end of working on the > > technical content of the draft, but it is actually the starting point > > when the WG has full change control about the content of the draft! > > > > > > Regards, > > > > Martin Stiemerling > > Transport Area Director > > > > _______________________________________________ > > Tcpinc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tcpinc > > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
