Hi, > Am 26.08.2015 um 19:52 schrieb Stephen Farrell <stephen.farr...@cs.tcd.ie>: > > > Hiya, > > On 26/08/15 16:47, Mirja Kühlewind wrote: >> Hi Stephen, >> >> just to double-check if I understand correctly what you are saying: > > I don't think we're saying the same thing. My fault probably, but > I'll try again below:-)
Okay, thanks for clarification… I was just trying to figure out what your view is or rather what the implications for tcp-eno are. > >> >> You basically say that you would not support the tcp-eno approach >> because you would like to have for any tcpinc protocol (not matter if >> tcp-use-tls or tcpcrypt) only a very simple negotiation in a TCP >> option where both ends confirm that they support tcpinc and then all >> additional negotiation is done in the payload data space (and >> therefore an own document is not needed)? >> >> What’s about the argument, that I believe you’ve stated earlier >> yourself, that one could use tcp-eno to update to a new protocol >> version (not only a new cipher) in case we detect flaws in the >> general protocol design…? If you think this is useful to have, would >> it then make then to have an own document for it (and potentially >> take the tcp-eno proposal as a starting point)? > > Until the WG have selected between tcpcrypt and tcp-use-tls > I don't think it makes any sense for tcp-eno to delve into > ciphersuite or cryptographic algorithm details. I personally agree! > > After the WG have selected tcpcrypt or tcp-use-tls: > - if the WG pursue only tcpcrypt it may make sense to handle > algorithm agility in a TCP option (I'm not sure if it would > or not but it'd be worth a look) > - if the WG select tcp-use-tls I don't think it makes sense > to try handle any algorithm agility in a TCP option Okay. > > The reason is that adding ciphersuite details into tcp-eno when > tcp-use-tls might be used could mean negotiating the same thing > twice, once in a TCP option and the 2nd time in the TLS handshake. > That seems like a bad idea that could create potential new > vulnerabilities, or at least confusion, bugs and possible lack > of interop. Agreed. I don’t think anybody wants to negotiate the same thing twice here. And it definitely should be avoided. > > If tcp-eno is only negotiating (or indicating) that tcpcrypt or > tcp-use-tls will be used, or that version-N of one of those will > be used, that could work, but I'm not so keen on it as it might > move the wg towards pursuing both tcpcrypt and tcp-use-tls in > the longer term, and I think one of the things on which the wg > did have consensus was that tcpinc would be based on only one > of those and that the wg would not continue to work on both > options beyond the next IETF meeting. I guess tcpcrpyt and tcp-use-tls could be two different versions of tcpinc. So of course versioning would allow the wg to keep working on both approaches; which might be good or bad, but I anyway double you can easily keep people from working on one or the others. However, just to make this clear, we as a working group don’t need to work on both approaches at the same time (even though we can if that’s what the wg wants to do). Just as an examples, versioning, as it could be provided by tcp-eno, would for example allow the wg to specify tcpcrypt now because the wg believe that’s the quickest and straight-forward solution and then alterwards specify a next version that uses TLS as soon as 1.3 is ready and has proven to be well applicable to tcpinc. Or the wg could go for tcp-use-tls now and as soon as the new tcp-eno option has proven to be usable in the Internet, the wg could start working on a different negotiation that is better integrated with tcp and only use the actual data encryption of tls… I’m not saying we should go for any of these two examples; just saying that a way to update tcpinc basically completely as tcp-eno provides can be beneficial. > > Does that help? Yes, a lot. Thanks! Mirja > > Cheers, > S. > > > >> >> Mirja >> >> >> >> On 25.08.2015 22:03, Stephen Farrell wrote: >>> >>> On 25/08/15 17:54, David Mazieres wrote: >>>> TCP-ENO is an effort A) to make progress on common elements of >>>> TCP-use-TLS and tcpcrypt, >>> >>> The above is reasonable. >>> >>> ... >>>> Well, in order to make the choice between tcpcrypt and >>>> TCP-use-TLS the most salient, it seems worth maximizing the >>>> advantages of the two protocols. >>> >>> I think your goal (A) and "maximising the advantages" of tcpcrypt >>> (or of TLS) are incompatible goals at this point in time. >>> >>> If/when the WG adopt tcpcrypt optimisations relating to algorithm >>> agility will inevitably be explored. If/when the WG adopt TLS that >>> kind of change wouldn't make sense. >>> >>> In the meantime trying to squeeze discussion of loads of different >>> things into discussion about TCP-ENO seems mostly a distraction. >>> >>> S. >>> >>> _______________________________________________ Tcpinc mailing >>> list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc >>> >> _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
