Martin Thomson <[email protected]> writes: > A simpler design would mimic ALPN. The initial SYN, would include a list > of options. The SYN+ACK would contain the selected option. A single octet > each should suffice for the option. tcpcrypt would need but a single > codepoint, as would tcp-use-tls.
TCP-ENO can be used this way. Indeed, if you don't use the configuration byte or variable-length suboptions, then you get one octet per offered option in the SYN, and one byte for the accepted option in the SYN+ACK. However, there is a good design rationale for the configuration byte and variable-length suboptions. Having the configuration byte standardized across protocols ensures that the most important OS-level API changes (extra getsockopt/setsockopt calls) can be amortized over multiple versions of TCPINC. In particular, the Application Aware bits are as fundamental as the session ID, so really need to be handled at the negotiation level. If people want to get rid of the "p" bit, we'd certainly be open to suggestions on how to handle simultaneous open. There are other ways to do it, but having one bit and requiring applications to set it properly was just the simplest thing we could think of. Well, okay, simpler would be to sort the spec identifiers and pick the lowest- or highest-numbered spec identifier common to both SYNs. However, we think people need to be able to configure spec priority. Plus, most encryption specs are likely to need symmetry breaking anyway, so we might as well solve the problem once. Variable-length options are critical to low latency. Tcpcrypt needs to include a few bytes in the SYN and SYN+ACK packets for public key cipher negotiation and for session caching. Removing this feature would incur an extra round trip before data can be exchanged in tcpcrypt or any future protocol. That would be particularly unfortunate if we ever get large option support in SYN segments or make a tailored TCPINC for fast open. Because variable-length options are optional, you don't have to use them if you don't need them. We allocated two fixed and two variable length suboptions each to tcpinc and TLS to err on the side of generosity, so people working on each spec have maximum flexibility until we see how this plays out in practice. I'd be surprised if any spec actually used all four of its suboptions. David Ted Hardie <[email protected]> (Fri. 10:24) () Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option To: David Mazieres expires 2015-10-28 PDT <mazieres-smik22bifyijpbqpizhkbhs...@temporary-address.scs.stanford.edu> Cc: tcpinc <[email protected]> Date: Fri, 31 Jul 2015 10:24:51 -0700 [ multipart/alternative ] [ text/plain ] I have read the draft, and I strongly support its adoption. This is exactly the sort of work that I believe that the working group can make progress on even as there is ongoing discussion of the key agreement and wire format. There are a few places where I disagree with the draft's technical choices, but that is, in my opinion, a good reason to adopt it: it is already concrete enough to start discussing the technical details. Let's get it on board and get to work, regards, Ted On Thu, Jul 30, 2015 at 3:26 PM, David Mazieres < [email protected]> wrote: > The tcpcrypt team is as committed as ever to contributing to continued > improvement, standardization, and deployment of tcpcrypt should the [ 49 more citation lines. Click/Enter to show. ] > draft be adopted by the TCPINC working group. > > However, we have decided that it may be preferable to specify tcpcrypt > in two separate documents: one concerning the negotiation of > encryption, the other concerning key agreement and data transmission > formats. > > The downside of splitting the draft is that the previous document was > already in good shape and has essentially been more-or-less > "ready-to-go" for over a year (with periodic revisions to meet working > group decisions). If the working group decides to adopt the existing > tcpcrypt document tomorrow, we believe it would make a great starting > point for an RFC. Of course, once the working group assumes ownership > of the document, we anticipate continued improvements, which may > ultimately include splitting the document anyway. > > The upside of splitting the draft is twofold. First, throughout the > TCPINC process, we have heard of ongoing standardization efforts (such > as large options) that could benefit TCPINC. Unfortunately, those > technologies are not yet ready for deployment. Separating negotiation > from encryption leaves us maximum flexibility to evolve TCPINC to > exploit future TCP enhancements in a backward-compatible way. > > Second, we believe that the TCPINC working group has considerable > agreement on what needs to happen for encryption negotiation, and that > most of the disagreement has revolved around key agreement and wire > formats. It is our hope that if the working group can agree on a > negotiation mechanism, this will constitute concrete progress that can > inject momentum into the whole TCPINC standardization process. > > The new draft, called draft-bittau-tcpinc-tcpeno-00 (TCP-ENO), is > available at the following URL: > > https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/ > > Unless people either strenuously object to this draft (or kill > tcpcrypt), we will shortly release an revised tcpcrypt draft built on > TCP-ENO. We encourage everyone who has not yet voted on this list to > vote to adopt tcpcrypt tomorrow. But now you can additionally vote to > adopt TCP-ENO. Even if you voted for TCP-use-TLS, I would encourage you > to consider voting for TCP-ENO as well, as those two drafts could also > be made to work together. > > My vote is to adopt both TCP-ENO and tcpcrypt, which together provide an > obvious path for harmonization. > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc [ text/html (hidden) ] John-Mark Gurney <[email protected]> (Today 10:37) (replied) Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option To: David Mazieres expires 2015-10-28 PDT <mazieres-smik22bifyijpbqpizhkbhs...@temporary-address.scs.stanford.edu> Cc: [email protected] Date: Sun, 02 Aug 2015 10:37:33 -0700 David Mazieres wrote this message on Thu, Jul 30, 2015 at 15:26 -0700: > My vote is to adopt both TCP-ENO and tcpcrypt, which together provide an > obvious path for harmonization. Is the goal of this draft to get down to one spec? or to allow both specs to become standards? >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. 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. So, as far as I can see, this draft runs counter to the WG charter and should not be considered... [ 4-line signature. Click/Enter to show. ] -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." David Mazieres expires 2015-10-31 PDT <[email protected]> (Today 12:08) (inbox replied) Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option To: John-Mark Gurney <[email protected]> Cc: [email protected] Date: Sun, 02 Aug 2015 12:08:22 -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. > 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 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. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
