David Mazieres wrote this message on Sun, Aug 02, 2015 at 14:04 -0700: > 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.
Ahh, I confused the TLS working group as TLS-use-TCP and not a seperate group, I appologize for misreading... I guess calling it tcpcrypt instead of tcpinc didn't help me either... I'd recommend renaming tcpcrypt to tcpinc to denote that it's the place holder for the output of this WG, not tcpcrypt specific... > >> 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. You're missing the point if the TCPINC standard allows for a conforming implementation to only support userland hand-off w/o requiring default support in libc or other layer so that automatic encryption always happens w/ a supported peer, then they HAVE implemented TCPINC to the letter, but not the spirit... THAT is my concern, that vendors will implement the letter, but not the spirit of the standard... > That said, the risk you outline is not a certainty. While ending up No, it's not, but neither is that what this WG outputs will achieve it's goals, I'd just like to have it air tight that a conforming implementation achieves this WG's goals... > 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. -- 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
