Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

2015-08-27 Thread Kyle Rose
I think maybe what Mirja is implying is that it's okay to break TCP (i.e., not fall back to unencrypted) if the two peers explicitly set their roles locally to the same thing. TCP-ENO-aware applications that set the role are assumed to get it right and not set both to A or both to B. Question re:

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

2015-08-27 Thread David Mazieres
Kyle Rose kr...@krose.org writes: I think maybe what Mirja is implying is that it's okay to break TCP (i.e., not fall back to unencrypted) if the two peers explicitly set their roles locally to the same thing. TCP-ENO-aware applications that set the role are assumed to get it right and not

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

2015-08-27 Thread Eric Rescorla
On Thu, Aug 27, 2015 at 10:32 AM, David Mazieres dm-list-tcpcr...@scs.stanford.edu wrote: Kyle Rose kr...@krose.org writes: I think maybe what Mirja is implying is that it's okay to break TCP (i.e., not fall back to unencrypted) if the two peers explicitly set their roles locally to the

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

2015-08-27 Thread dm-list-tcpcrypt
Mirja K=C3=BChlewind mirja.kuehlew...@tik.ee.ethz.ch writes: Hi David, I believe the point is, if you have already broken the tie via out-of-band signal and both endpoints have already decided who will be the opener (host A) and responder (host B), why do you still need to write this