David Mazieres expires 2015-10-31 PDT wrote this message on Sun, Aug 02, 2015 at 12:08 -0700: > John-Mark Gurney <[email protected]> writes: > > > Is the goal of this draft to get down to one spec? or to allow both > > specs to become standards? > > Well, the working group charter is to produce three documents > (framework, protocol, and API). Hence, unless we re-charter, we would > have to reorganize the documents. Part of TCP-ENO (like the normative > requirements for a Session ID) might move into the framework document, > which would then have to be classified as experimental rather than > informational. (The charter doesn't specify the status of the framework > document.) Then other parts of TCP-ENO would be merged with tcpcrypt or > TCP-use-TLS to produce a protocol document.
Then why does the draft allocate both id's to both, if it comes down to one or the other? Shouldn't we just allocate a range for the implementation that the WG decides upon? > > From what I see, this allows both specs to become standard, which is > > a bad idea... The WG charter specifically says: "to provide reasonable > > security for the majority of connections.", but if we adopt this, it > > will allow vendors to pick only one of two (or more), claim that they > > support always on encryption, and then a majority of connections will > > not be encrypted because there will be a protocol mismatch. > > I think this is absolutely a valid concern. The working group should > not standardize two transport-layer protocols and use TCP-ENO to switch > between them. At the same time, I think we should be highly mindful of > future developments and needs. So that means that while we could have > written TCP-ENO as just a simple cipher-suite negotiation mechanism, we > also wanted to account for the possibility that TCPINC may need to > evolve in much more radical ways than just cipher suites. > > A good example is what happens if someday we get large options in SYN > segments? Well, this would potentially allow us to shave round-trip > times from TCPINC, which is not the kind of performance win we'd want to > leave on the table. But the resulting changes would be different enough > from anything we have that we'd want to negotiate it straightaway in the > SYN using variable-length suboptions. > > Another issue is that TCPINC should be the transport-layer encryption > mechanism for the Internet. But TCP-ENO can potentially be used to > negotiate application-layer encryption as well. There's a plausible > scenario in which TLS can hugely benefit from just one out-of-band bit > to negotiate library-level use of TLS in a backwards compatible way. > > Looking back to Andrea's tcpcrypt slides from IETF89: > > http://www.ietf.org/proceedings/89/slides/slides-89-tcpm-9.pdf > > The goal he laid out was to attack the problem of unencrypted traffic on > two fronts--increase TLS adoption at the application layer as much as > possible, and then enable transport-level encryption for the remaining Correct, as TLS provides authentication... > cases. So while increasing TLS is not strictly within the TCPINC > charter, if there's room in TCPINC to reserve "one bit" for the TLS > working group, it might be prudent to do so. > > > Expecting OS vendors to implement all protocols again is not a good > > idea... They will want to put their eggs in one basket, and watch that > > basket closely, pay for security audit, etc. > > Again, I think this is absolutely a valid concern. To illustrate this > with some completely made up numbers, we could find ourselves in a > situation where giving one bit to the TLS working group allows people to > go from 50% to 70% adoption of TLS overnight, and that's enough of an > improvement that people lose interest in TCPINC. But if TCPINC had been > the only backwards compatible solution, then everyone would have > implemented it in their kernels and gotten us to 90% encryption. But > also if everyone implemented TCPINC and we gave TLS the extra bit, then > maybe we could get to 95% encryption. > > This is a question I'm a little ambivalent about because it requires > predicting the future. But with something like TCP-ENO, we have the > groundwork to go in whichever direction the working group decides, and > also more leeway to change our minds down the road. I do agree that giving the "bit" could increase TLS deployment, but from past experience, everyone will do the minimal amount to work to be compliant, so if there's an option of just using the bit, and saying, oh, we support and have implemented the TCPINC standard, but require applications to be modified, then then WG has failed... The scary part is that this is apparently the goal of the TLS-use-TCP spec, as it explicitly allows a conforming implementation to only do userland hand off: There are two primary implementation options for TCP-TLS: [...] o Implement just the TCP-TLS negotiation option in the operating system kernel with an interface to tell the application that TCP- TLS has been negotiated and therefore that the application must negotiate TLS. So, if TCP-ENO is adopted, and ths TLS-use-TCP draft is adopted, they just have to do TCP-ENO, and no other work, and they've fully implemented the TCPINC WG recommendations, but we have made very little headway to encrypting the internet traffic. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
