John-Mark Gurney <[email protected]> writes: >> 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?
Two reasons. First, a draft is just a draft. We don't expect it to stay that way. But to the extent that people like TCP-ENO yet still aren't sure about tcpcrypt vs. TCP-use-TLS, it seemed kind of impolite not to allocate separate numbers to both protocols so that people could tinker with implementations of both in parallel. Second, note that we actually allocated the 4 numbers to the TLS working group, not to TCP-use-TLS. They could potentially make use of that for application-level instead of transport-level encryption. But again, it's just a draft, and for a draft it seems better to err on the side of inclusiveness (and have the working group whittle things down) than vice versa. >> 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... Well, TLS can provide authentication, but it can't do it with only information expressed through existing transport-level APIs (i.e., basically just a sockaddr_in[6]). So I think TCP-use-TLS are pretty much in the same boat when it comes to authentication, except that tcpcrypt has application-aware bits that allow authentication to be done in a backwards compatible way. One of the advantages of TCP-ENO's approach is that it standardizes the notion of application-aware bits, thereby facilitating the transition from opportunistic encryption to authenticated endpoints. > 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. Yup, that's a totally valid concern. My only quibble is that library-level code wouldn't be implementing TCPINC (which would be either tcpcrypt or TCP-use-TLS), but would have implemented TCP-ENO. Once you buy into a library-level implementation, there is no reason to stick to the transport-level API--e.g., the library should have access to DNS names, etc., so it wouldn't be TCPINC. That said, the risk you outline is not a certainty. While ending up with a valid TCP option for tcpcrypt doesn't guarantee deployment, staying deadlocked and/or waiting for TLS1.3 to catch up does guarantee no deployment of transport-layer encryption any time soon. There are worse outcomes than triggering a friendly competition between the TLS and TCPINC working groups to see whether we can deploy opportunistic encryption faster at the transport layer or the application layer: at the point the two efforts collide, 99% of TCP traffic will be encrypted. Remember it's not just that the room was pretty split in Prague, it's that a noticeable majority of people in the room hummed they would not change their minds. We are deadlocked on the question of tcpcrypt vs. TCP-use-TLS. TCP-ENO is an attempt to change the question to one we might not be deadlocked on, and to provide advantages to TLS even if TCP-use-TLS is not selected. Allocating a few suboptions to the TLS working group means that standardizing TCP-ENO + tcpcrypt would benefit TLS more than TCPINC standardizing nothing at all. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
