TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-05-21
|
19 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-12
|
19 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-02-15
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-01-29
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-01-28
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-01-28
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-01-11
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-08
|
19 | (System) | RFC Editor state changed to EDIT |
2019-01-08
|
19 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-01-08
|
19 | (System) | Announcement was received by RFC Editor |
2019-01-08
|
19 | (System) | IANA Action state changed to In Progress |
2019-01-08
|
19 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-01-08
|
19 | Amy Vezza | IESG has approved the document |
2019-01-08
|
19 | Amy Vezza | Closed "Approve" ballot |
2019-01-08
|
19 | Amy Vezza | Ballot approval text was generated |
2019-01-08
|
19 | Mirja Kühlewind | IESG state changed to Approved-announcement to be sent from Approved-announcement sent |
2019-01-08
|
19 | Mirja Kühlewind | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-01-08
|
19 | Mirja Kühlewind | RFC Editor Note was changed |
2019-01-08
|
19 | Mirja Kühlewind | RFC Editor Note was changed |
2019-01-08
|
19 | Mirja Kühlewind | RFC Editor Note for ballot was generated |
2019-01-08
|
19 | Mirja Kühlewind | RFC Editor Note for ballot was generated |
2019-01-08
|
19 | Mirja Kühlewind | Ballot writeup was changed |
2019-01-08
|
19 | Mirja Kühlewind | Ballot writeup was changed |
2018-06-29
|
19 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-19.txt |
2018-06-29
|
19 | (System) | New version approved |
2018-06-29
|
19 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2018-06-29
|
19 | David Mazieres | Uploaded new revision |
2017-12-19
|
18 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2017-11-30
|
18 | Jean Mahoney | Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2017-11-30
|
18 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2017-11-30
|
18 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2017-11-30
|
18 | Jean Mahoney | Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2017-11-30
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-11-30
|
18 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-18.txt |
2017-11-30
|
18 | (System) | New version approved |
2017-11-30
|
18 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-11-30
|
18 | David Mazieres | Uploaded new revision |
2017-11-30
|
17 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation - Defer |
2017-11-29
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-11-29
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-11-29
|
17 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-11-28
|
17 | Warren Kumari | [Ballot comment] I'd like to echo what others have said, especially Adam's Section 4 comment. I was also confused by the "option kind" - I'd … [Ballot comment] I'd like to echo what others have said, especially Adam's Section 4 comment. I was also confused by the "option kind" - I'd assumed that it was simply a term of art for TCP option, but seeing as Spencer is also mystified I'm guessing not -- for my own education, can you please explain? Also, once again a nice shepherd writeup from David. [ Edit: I'd somehow managed to confuse the experiment description in this document with that from a different doc (ippm-alt-mark) -- so many documents! ] |
2017-11-28
|
17 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2017-11-28
|
17 | Warren Kumari | [Ballot comment] I'd like to echo what others have said, especially Adam's Section 4 comment, and Benoit's "what is the actual experiment?" - if this … [Ballot comment] I'd like to echo what others have said, especially Adam's Section 4 comment, and Benoit's "what is the actual experiment?" - if this doesn't explain what the experiment will test, perhaps it should be Std Track? (Section 9, while nice, doesn't really cover this). Just because it is new / untested doesn't mean that it cannot be standard and then updated later. I was also confused by the "option kind" - I'd assumed that it was simply a term of art for TCP option, but seeing as Spencer is also mystified I'm guessing not -- for my own education, can you please explain? Also, once again a nice shepherd writeup from David. |
2017-11-28
|
17 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2017-11-27
|
17 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Watson Ladd. |
2017-11-26
|
17 | Alexey Melnikov | |
2017-11-26
|
17 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2017-11-18
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Watson Ladd |
2017-11-18
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Watson Ladd |
2017-11-18
|
17 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Watson Ladd. |
2017-11-17
|
17 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-17.txt |
2017-11-17
|
17 | (System) | New version approved |
2017-11-17
|
17 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-11-17
|
17 | David Mazieres | Uploaded new revision |
2017-11-16
|
16 | Eric Rescorla | [Ballot comment] This is looking good. A few small comments: ENO provides a framework in which two endpoints can agree on a TCP … [Ballot comment] This is looking good. A few small comments: ENO provides a framework in which two endpoints can agree on a TCP encryption protocol or _TEP_ out of multiple possible TEPs. For future compatibility, TEPs can vary widely in terms of wire format, Nit: instead of "or _TEP_" I would say (_TEP_). These are the same thing suboptions, which we term a _vacuous_ SYN-form ENO option. If either host sends a vacuous ENO option, it follows that there are no valid TEP identifiers for the connection and hence the connection MUST fall do you mean "vacuous SYN-form ENO option' here? (1) A -> B: SYN ENO (2) B -> A: SYN-ACK Oh, I now see why you were sad. I meant *b=0*, so it makes clear why the roles resolve properly. My bad. I agree you don't need to show a=0 all the time. So sorry. |
2017-11-16
|
16 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss |
2017-11-16
|
16 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-16.txt |
2017-11-16
|
16 | (System) | New version approved |
2017-11-16
|
16 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-11-16
|
16 | David Mazieres | Uploaded new revision |
2017-11-16
|
15 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-15.txt |
2017-11-16
|
15 | (System) | New version approved |
2017-11-16
|
15 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-11-16
|
15 | David Mazieres | Uploaded new revision |
2017-11-15
|
14 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-14.txt |
2017-11-15
|
14 | (System) | New version approved |
2017-11-15
|
14 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-11-15
|
14 | David Mazieres | Uploaded new revision |
2017-11-11
|
13 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-11-11
|
13 | Deborah Brungard | [Ballot comment] Agree with other ADs' comments on needed clarifications. |
2017-11-11
|
13 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-11-11
|
13 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft and experiment. I just have one comment that I don't think has been mentioned already. In … [Ballot comment] Thanks for your work on this draft and experiment. I just have one comment that I don't think has been mentioned already. In section 4, could you include reference to Opportunistic security, RFC7435. The definition has changed slightly over time and it would be good to link this to the current definition that is intended. The work on 7435 was painstaking and the definition varies a bit in older specs. I do realize you describe this more in the security considerations section, but it is much later in the document, so this seemed like an easy fix. |
2017-11-11
|
13 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2017-11-11
|
13 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft and experiement. I just have one comment that I don't think has been mentioned already. In … [Ballot comment] Thanks for your work on this draft and experiement. I just have one comment that I don't think has been mentioned already. In section 4, could you include reference to Opportunistic security, RFC7435. The definition has changed slightly over time and it would be good to link this to the current definition that is intended. The work on 7435 was painstaking and the definition varies a bit in older specs. I do realize you describe this more in the security considerations section, but it is much later in the document, so this seemed like an easy fix. |
2017-11-11
|
13 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2017-11-10
|
13 | Alissa Cooper | [Ballot comment] The Gen-ART review comments should be addressed. |
2017-11-10
|
13 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-11-10
|
13 | Eric Rescorla | [Ballot discuss] o TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. IMPORTANT: I … [Ballot discuss] o TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. IMPORTANT: I don't know what "significantly means". I wouldn't be making a point of this, but it's phrased as a normative requirement, so I don't know what conformance means. IMPORTANT: This actually seems to be a bit confusing about how to handle URG. Consider TCP-use-TLS, you would just process URG in the normal way and then generate errors if URG causes reordering at the TLS layer. This seems like a reasonable procedure but is at least arguably prohibited by this text. problems, TEPs MUST compute session IDs using only well-studied and conservative hash functions. That way, even if other parts of a TEP are vulnerable, it is still intractable for an attacker to induce IMPORTANT: this also does not seem to be unambiguous. |
2017-11-10
|
13 | Eric Rescorla | [Ballot comment] 4. Provide a standard negotiation transcript through which TEPs can defend against tampering with TCP-ENO. This … [Ballot comment] 4. Provide a standard negotiation transcript through which TEPs can defend against tampering with TCP-ENO. This was unclear to me when I first read this. Maybe "Export a standard negotiation transcript to TEPs which they can use to defend against" opportunistically. It uses a new TCP option kind to negotiate one among multiple possible TCP encryption protocols or TEPs. The negotiation involves hosts exchanging sets of supported TEPs, where Nit: I would say "one TEP out of multiple" Also, "TCP encryption protocols or TEPs." is confusing. If you feel the need to redefine, do "TCP encryption protocols (TEPs)" variable-length data. When "v = 0", the byte itself constitutes the entirety of the suboption. The 7-bit value "glt" expresses one of: I would say "the remaining 7-bit value, called "glt", may take on various meanings, as defined below" "b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" role. This would be clearer if it (a) explained the reasoning and (b) appeared before the packet formats. Perhaps something like "Because the passive opener MUST set b=1 and the active opener by default sets b=0, the normal cases is that the active opener is A and the passive opener is B. Applications which depend on simultaneous open and have some other way of breaking the tie can set one side to b=1 (even though it is the active opener) and thus arrange for correct role assignment. Otherwise, simultaneous opens will fail" If both sides of a connection set "b = 1" (which can happen if the active opener misconfigures "b" before calling "connect"), or both sides set "b = 0" (which can happen with simultaneous open), then Why is this "misconfigures"? You allow them to do so. initial suboption byte (see Figure 4). By default, suboption data extends to the end of the TCP option. Hence, if only one suboption requires data, the most compact way to encode it is to place it last Why is this "by default"? It just seems like another setting of glt. connection or when there is any ambiguity over the meaning of the SYN data. This requirement applies to hosts that implement ENO even when ENO has been disabled by configuration. However, note that I think you may mean to say "when the last SYN TEP is not eventually negotiated" o TEPs MUST NOT depend on long-lived secrets for data confidentiality, as implementations SHOULD provide forward secrecy some bounded, short time after the close of a TCP connection. Maybe "depend solely" because one might want to use a DH mode where a static DH key is mixed in with an ephemeral. probability detect a FIN flag that was set or cleared in transit and does not match the sender's intent. A TEP MAY discard a segment with such a corrupted FIN bit, or may abort the connection What is "high probability" that disable urgent data by default. The exception is when applications and protocols are known never to send urgent data. (4) B -> A: SYN-ACK ENO [rest of connection encrypted according to TEP Y] Can you show a=0 in line 1? |
2017-11-10
|
13 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2017-11-10
|
13 | Ben Campbell | [Ballot comment] I agree with Adam's comment on Section 4. |
2017-11-10
|
13 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2017-11-10
|
13 | Benoît Claise | [Ballot comment] Nothing against the publication of this document but ... as for any experimental RFCs, we must describe the criteria for a successful experiment … [Ballot comment] Nothing against the publication of this document but ... as for any experimental RFCs, we must describe the criteria for a successful experiment (evaluation)? Same remark for draft-ietf-tcpinc-tcpcrypt-09 I have seen section 9, which explains why this is experimental. It's only part of the info. Note sure that everybody has seen Eric Vyncke's OPS DIR review: The document describes an _experimental_ TCP option to negotiate at the TCP layer the use of opportunistic encryption at layer-4 for the transparent benefit of applications (which do not support TLS for example). Section 4.2 describes an 'application-aware' bit which seems to tell the other TCP party that the upper-layer are aware but to be honest the text describing this bit could really be improved. Does it allow a responder to signal that it supports TLS? Or something else? I like the idea of application giving hints to the other TCP party to avoid useless double encryption but the description of this bit is really unclear. The specification takes really care of the TCP option size by compressing a lot of the information pieces. I wonder whether allowing only 95 'TEP' (TCP encryption protocols) is not a constraint... suggestion to allow a specific TEP value signaling that the value is on 16 bits for example. This is an experimental protocol, so, we can guess that the authors will experiment around the following issues in order to improve the protocol: - Lack of authentication (and encryption without authentication has little value) even if section 5 talks about it - No wording around MSS negotiation (as encryption could potentially reduce the useful MSS) - The role of middle boxes will be important (see also section 8.1 where SLB proved to an annoyance), removing the ENO - Suggestion to also test NAT64 middle boxes I hope this helps to improve this useful proposal |
2017-11-10
|
13 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-11-06
|
13 | Adam Roach | [Ballot comment] Thanks for a well-thought-out and well written document. I'm looking forward to seeing how this experiment goes. I have a few minor comments … [Ballot comment] Thanks for a well-thought-out and well written document. I'm looking forward to seeing how this experiment goes. I have a few minor comments for possible improvements. Section 4 indicates that applications can be made aware of whether TCP encryption is occurring: o A bit available to higher-layer protocols at each endpoint for out-of-band negotiation of updated behavior in the presence of TCP encryption. I see that this is used to bind the TEP to certain application-level information, which is obviously good -- but I think some guidance in here cautioning about the hazards of exposing opportunistically encrypted connections to users as "secure" would be helpful. In general, because of the MITM considerations that are already covered, conveying opportunistic encryption to users as "secure" is dangerous. Section 4.2: b The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set "b = 1" before initiating an active open. (Manual configuration of "b" is only necessary to enable encryption with a simultaneous open.) I think this could be made clearer (thinking in particular of Spencer's question) if this text indicated that implementations making use of simultaneous open need to have some out-of-band negotiation of role before the TCP connection is attempted. |
2017-11-06
|
13 | Adam Roach | Ballot comment text updated for Adam Roach |
2017-11-06
|
13 | Adam Roach | [Ballot comment] Thanks for a well-thought-out and well written document. I'm looking forward to seeing how this experiment goes. I have a few minor comments … [Ballot comment] Thanks for a well-thought-out and well written document. I'm looking forward to seeing how this experiment goes. I have a few minor comments for possible improvements. Section 4 indicates that applications can be made aware of whether TCP encryption is occurring: o A bit available to higher-layer protocols at each endpoint for out-of-band negotiation of updated behavior in the presence of TCP encryption. I see that this is used to bind the TEP to certain TCP-ENO information, which is obviously good -- but I think some guidance in here cautioning about the hazards of exposing opportunistically encrypted connections to users as "secure" would be helpful. In general, because of the MITM considerations that are already covered, conveying opportunistic encryption to users as "secure" is dangerous. Section 4.2: b The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set "b = 1" before initiating an active open. (Manual configuration of "b" is only necessary to enable encryption with a simultaneous open.) I think this could be made clearer (thinking in particular of Spencer's question) if this text indicated that implementations making use of simultaneous open need to have some out-of-band negotiation of role before the TCP connection is attempted. |
2017-11-06
|
13 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2017-11-03
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2017-11-03
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2017-11-03
|
13 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Meral Shirazipour. |
2017-11-03
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-11-03
|
13 | Amy Vezza | New version available: draft-ietf-tcpinc-tcpeno-13.txt |
2017-11-03
|
13 | (System) | Secretariat manually posting. Approvals already received |
2017-11-03
|
13 | Amy Vezza | Uploaded new revision |
2017-10-29
|
12 | Min Ye | Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Papadimitriou Dimitri. Sent review to list. |
2017-10-26
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Watson Ladd |
2017-10-26
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Watson Ladd |
2017-10-25
|
12 | Spencer Dawkins | [Ballot comment] This draft was fairly easy for me to follow. I do have some questions, of course, but I'm a Yes. In Section 3, … [Ballot comment] This draft was fairly easy for me to follow. I do have some questions, of course, but I'm a Yes. In Section 3, Terminology, most of the terms were originally defined in RFC 793 (pretty much all, except for the last three, about TEP). I don't object to this document saying "this is how we are using these terms from RFC 793", but I do think it's worth providing an explicit pointer to the more detailed descriptions in RFC 793, which is already a normative reference but is only referenced for the description of TCP header options in Section 4.1. I'm having a little trouble figuring out what "kind" means in this text. It uses a new TCP option kind to negotiate one among multiple possible TCP encryption protocols or TEPs. Is this a term of art I haven't seen? I understand every word in this text, b The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set "b = 1" before initiating an active open. (Manual configuration of "b" is necessary to enable encryption with a simultaneous open.) but am not sure what you're telling implementers - is the point that a client application using a traditional client-server application protocol doesn't need to set "b = 1" for an active open, because servers won't also be attempting an active open simultaneously, but applications using peer-to-peer application protocols should? Could you give an example of the kind of "implementation considerations" that A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK segment. Hence, a passive opener SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD ensure this TEP identifier is valid. However, simultaneous open or implementation considerations can prevent host B from offering only one TEP. is envisioning? Perhaps A host MAY send a _vacuous_ SYN-form ENO option containing zero TEP identifier suboptions. would be an appropriate entry in the terminology section? I had to keep reading to understand what _vacuous_ meant in this sentence. I wonder what the understanding of "significantly less" in o TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. will be in practice. Could you help me understand why this isn't a specific number? I couldn't parse "provide forward secrecy some bounded, short time" in o TEPs MUST NOT depend on long-lived secrets for data confidentiality, as implementations SHOULD provide forward secrecy some bounded, short time after the close of a TCP connection. without guessing. Perhaps one or more words is missing? |
2017-10-25
|
12 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2017-10-25
|
12 | Amy Vezza | Deferred on behalf of Eric Rescorla. |
2017-10-25
|
12 | Amy Vezza | Telechat date has been changed to 2017-11-30 from 2017-10-26 |
2017-10-25
|
12 | Amy Vezza | IESG state changed to IESG Evaluation - Defer from Waiting for Writeup |
2017-10-25
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-10-25
|
12 | Alia Atlas | [Ballot comment] I would appreciate a paragraph/few sentences that explain the relationship of TCP-ENO to TCPC-AO. Obviously, this is for encryption and that is for … [Ballot comment] I would appreciate a paragraph/few sentences that explain the relationship of TCP-ENO to TCPC-AO. Obviously, this is for encryption and that is for authentication - but issues around the algorithms and keying seem like they would be related. |
2017-10-25
|
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-10-23
|
12 | Mirja Kühlewind | Ballot has been issued |
2017-10-23
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2017-10-23
|
12 | Mirja Kühlewind | Created "Approve" ballot |
2017-10-23
|
12 | Mirja Kühlewind | Ballot writeup was changed |
2017-10-23
|
12 | Mirja Kühlewind | Changed consensus to Yes from Unknown |
2017-10-22
|
12 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-12.txt |
2017-10-22
|
12 | (System) | New version approved |
2017-10-22
|
12 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-10-22
|
12 | David Mazieres | Uploaded new revision |
2017-10-20
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-10-20
|
11 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-11.txt |
2017-10-20
|
11 | (System) | New version approved |
2017-10-20
|
11 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-10-20
|
11 | David Mazieres | Uploaded new revision |
2017-10-19
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Watson Ladd. |
2017-10-19
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-10-18
|
10 | David Black | TCP-ENO: Encryption Negotiation Option draft-ietf-tcpinc-tcpeno-08 1. Summary Document Shepherd: David Black Responsible AD: Mirja Kuehlewind Despite growing adoption of TLS [RFC5246], a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The WG has requested Experimental status because this draft specifies a new protocol for which implementation and usage experience is desired before producing a proposed standard. 2. Review and Consensus In response to concerns about pervasive surveillance, the tcpinc WG was formed in 2014 to produce a TCP extension that provides unauthenticated (opportunistic) encryption of TCP streams. The goal is universal encryption of TCP streams, increasing the burden of pervasive surveillance from passive dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks. An inability to achieve consensus on a single approach best characterizes the first year and a half of the WG's existence. There were two competing proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and fully-realized protocols, this mooted any collaboration or compromise. This inability to achieve consensus damaged the WG, as parties looking for a solution in this space grew weary of the lack of progress. Many who initially expressed interest in working on independent implementations lost interest and moved on to other work. Some progress was made during this time, notably the WG decided to provide length information for all data sent (rather than relying on packet length) to protect against resegmentation in the network. The logjam was successfully broken by three WG actions in the second half of 2015. The first was that the TCP extension functionality of tcpcrypt was split off into a separate proposal called TCP-ENO (Encryption Negotiation Option). This extension notably has the ability to negotiate multiple TCP stream encryption protocols, allowing potentially for runtime negotiation of either tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol). This draft contains the resulting TCP-ENO specification. The second action was initiated by the chairs. After the Transport AD changed the WG chairs in July 2015, the new chairs made a call for adoption of both tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that both protocols could be concurrently deployed. The logjam was finally broken by competing demands for the TLS community, including for the editor of the tcpinc-use-TLS draft, especially for completion of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the resulting rough consensus of the WG was that the appropriate course of action was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure that ENO could eventually support a TLS profile. Following this decision, rough consensus was achieved fairly rapidly, with only minor tweaks to the protocol since March 2016. Mailing list traffic has been very quiet since September 2016, and no tcpinc session was held at IETF 98 in Chicago. Expert reviews were conducted by Jake Holland and Wes Eddy, with important additional feedback from transport experts who are members of the tcpinc WG. No fundamental blocking issues have been revealed through review. The chairs would like an additional review by the Security Area Directorate in conjunction with the tcpcrypt draft. There is only one current implementation of tcpcrypt, that being the reference implementation by the Stanford team. At least one other implementation effort is in progress. The WG chairs believe that a reliable implementation distributed as part of a major operating system is the best approach to rekindling interest in this project and for encouraging the development of additional interoperating implementations. 3. Intellectual Property Each draft author has stated his/her direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points The original implementation of tcpcrypt squatted on TCP option kind 69, which caused some controversy and animated discussion on the mailing list. After some negotiation with Joe Touch, it was decided that tcpcrypt would be willing to bear the cost of this decision by requesting the same option for assignment by IANA. This draft anticipates the assignment of TCP option kind 69 to TCP-ENO. Tcpcrypt requires the addition of an IANA registry with expert review for "TCP-ENO Protocol Identifiers", the initial values for which are listed in section 10: this is code point allocation for the encryption protocols negotiated by TCP-ENO. In the case of tcpcrypt, this negotiation also includes the algorithm for initial exchange of ephemeral keys. Expert reviewers for this registry should be able to analyze a proposed key exchange algorithm for compatibility with the cryptographic requirements of tcpcrypt, and be generally familiar with security protocol design when reviewing applications for values to be assigned for TEPs other than tcpcrypt. A common reviewer is suggested for this registry and the "tcpcrypt AEAD parameter" registry created by the tcpcrypt draft, as tcpcrypt cryptographic parameter and algorithm changes impact both registries. Minimum criteria for a move from Experimental to Proposed Standard status should include substantive deployment experience spanning multiple implementations and networks and a BCP document describing deployment challenges and mitigations, especially with respect to successfully transiting middle boxes. |
2017-10-17
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2017-10-17
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tcpinc-tcpeno-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tcpinc-tcpeno-10. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First in the TCP Option Kind Numbers registry on the Transmission Control Protocol (TCP) Parameters registry page located at: https://www.iana.org/assignments/tcp-parameters/ a new Option Kind is to be registered as follows: Kind: [ TBD-at-registration ] Length: N Meaning: Encryption Negotiation (TCP-ENO) Reference: [ RFC-to-be ] We note the authors' description of the unauthorized use of TCP Option Kind number 69 and will, instead, use an option kind number from a different range in the registry. Second, a new registry is to be created called the TCP encryption protocol identifiers registry. The new registry is to be located on the Transmission Control Protocol (TCP) Parameters registry page located at: https://www.iana.org/assignments/tcp-parameters/ The registry is to be managed via RFC Required as defined by [ RFC 8126 ]. There is a single, initial value in the new registry as follows: +-------+------------------+---------------+ | Value | Meaning | Reference | +-------+------------------+---------------+ | 0x20 | Experimental Use | [ RFC-to-be ] | +-------+------------------+---------------+ The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist |
2017-10-12
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-10-12
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-10-12
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2017-10-12
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2017-10-11
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Eric Vyncke |
2017-10-11
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Eric Vyncke |
2017-10-10
|
10 | Min Ye | Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri |
2017-10-10
|
10 | Min Ye | Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri |
2017-10-09
|
10 | Alvaro Retana | Requested Telechat review by RTGDIR |
2017-10-05
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-10-05
|
10 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-10-19): From: The IESG To: IETF-Announce CC: tcpinc@ietf.org, tcpinc-chairs@ietf.org, david.black@dell.com, ietf@kuehlewind.net, David … The following Last Call announcement was sent out (ends 2017-10-19): From: The IESG To: IETF-Announce CC: tcpinc@ietf.org, tcpinc-chairs@ietf.org, david.black@dell.com, ietf@kuehlewind.net, David Black , draft-ietf-tcpinc-tcpeno@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TCP-ENO: Encryption Negotiation Option) to Experimental RFC The IESG has received a request from the TCP Increased Security WG (tcpinc) to consider the following document: - 'TCP-ENO: Encryption Negotiation Option' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-10-05
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-10-05
|
10 | Mirja Kühlewind | Placed on agenda for telechat - 2017-10-26 |
2017-10-05
|
10 | Mirja Kühlewind | Last call was requested |
2017-10-05
|
10 | Mirja Kühlewind | Ballot approval text was generated |
2017-10-05
|
10 | Mirja Kühlewind | Ballot writeup was generated |
2017-10-05
|
10 | Mirja Kühlewind | IESG state changed to Last Call Requested from Publication Requested |
2017-10-05
|
10 | Mirja Kühlewind | Last call announcement was generated |
2017-10-04
|
10 | Daniel Giffin | New version available: draft-ietf-tcpinc-tcpeno-10.txt |
2017-10-04
|
10 | (System) | New version approved |
2017-10-04
|
10 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-10-04
|
10 | Daniel Giffin | Uploaded new revision |
2017-08-02
|
09 | Daniel Giffin | New version available: draft-ietf-tcpinc-tcpeno-09.txt |
2017-08-02
|
09 | (System) | New version approved |
2017-08-02
|
09 | (System) | Request for posting confirmation emailed to previous authors: tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-08-02
|
09 | Daniel Giffin | Uploaded new revision |
2017-06-08
|
08 | David Black | TCP-ENO: Encryption Negotiation Option draft-ietf-tcpinc-tcpeno-08 1. Summary Document Shepherd: David Black Responsible AD: Mirja Kuehlewind Despite growing adoption of TLS [RFC5246], a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The WG has requested Experimental status because this draft specifies a new protocol for which implementation and usage experience is desired before producing a proposed standard. 2. Review and Consensus In response to concerns about pervasive surveillance, the tcpinc WG was formed in 2014 to produce a TCP extension that provides unauthenticated (opportunistic) encryption of TCP streams. The goal is universal encryption of TCP streams, increasing the burden of pervasive surveillance from passive dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks. An inability to achieve consensus on a single approach best characterizes the first year and a half of the WG's existence. There were two competing proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and fully-realized protocols, this mooted any collaboration or compromise. This inability to achieve consensus damaged the WG, as parties looking for a solution in this space grew weary of the lack of progress. Many who initially expressed interest in working on independent implementations lost interest and moved on to other work. Some progress was made during this time, notably the WG decided to provide length information for all data sent (rather than relying on packet length) to protect against resegmentation in the network. The logjam was successfully broken by three WG actions in the second half of 2015. The first was that the TCP extension functionality of tcpcrypt was split off into a separate proposal called TCP-ENO (Encryption Negotiation Option). This extension notably has the ability to negotiate multiple TCP stream encryption protocols, allowing potentially for runtime negotiation of either tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol). This draft contains the resulting TCP-ENO specification. The second action was initiated by the chairs. After the Transport AD changed the WG chairs in July 2015, the new chairs made a call for adoption of both tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that both protocols could be concurrently deployed. The logjam was finally broken by competing demands for the TLS community, including for the editor of the tcpinc-use-TLS draft, especially for completion of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the resulting rough consensus of the WG was that the appropriate course of action was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure that ENO could eventually support a TLS profile. Following this decision, rough consensus was achieved fairly rapidly, with only minor tweaks to the protocol since March 2016. Mailing list traffic has been very quiet since September 2016, and no tcpinc session was held at IETF 98 in Chicago. Expert reviews were conducted by Jake Holland and Wes Eddy, with important additional feedback from transport experts who are members of the tcpinc WG. No fundamental blocking issues have been revealed through review. The chairs would like an additional review by the Security Area Directorate in conjunction with the tcpcrypt draft. There is only one current implementation of tcpcrypt, that being the reference implementation by the Stanford team. At least one other implementation effort is in progress. The WG chairs believe that a reliable implementation distributed as part of a major operating system is the best approach to rekindling interest in this project and for encouraging the development of additional interoperating implementations. 3. Intellectual Property Each draft author has stated his/her direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points The original implementation of tcpcrypt squatted on TCP option kind 69, which caused some controversy and animated discussion on the mailing list. After some negotiation with Joe Touch, it was decided that tcpcrypt would be willing to bear the cost of this decision by requesting the same option for assignment by IANA. This draft requests the assignment of TCP option kind 69 to TCP-ENO. Tcpcrypt requires the addition of an IANA registry with expert review for "TCP-ENO Protocol Identifiers", the initial values for which are listed in section 10: this is code point allocation for the encryption protocols negotiated by TCP-ENO. In the case of tcpcrypt, this negotiation also includes the algorithm for initial exchange of ephemeral keys. Expert reviewers for this registry should be able to analyze a proposed key exchange algorithm for compatibility with the cryptographic requirements of tcpcrypt, and be generally familiar with security protocol design when reviewing applications for values to be assigned for TEPs other than tcpcrypt. A common reviewer is suggested for this registry and the "tcpcrypt AEAD parameter" registry created by the tcpcrypt draft, as tcpcrypt cryptographic parameter and algorithm changes impact both registries. Minimum criteria for a move from Experimental to Proposed Standard status should include substantive deployment experience spanning multiple implementations and networks and a BCP document describing deployment challenges and mitigations, especially with respect to successfully transiting middle boxes. |
2017-06-08
|
08 | David Black | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-06-08
|
08 | David Black | IESG state changed to Publication Requested from AD is watching |
2017-06-08
|
08 | David Black | TCP-ENO: Encryption Negotiation Option draft-ietf-tcpinc-tcpeno-08 1. Summary Document Shepherd: David Black Responsible AD: Mirja Kuehlewind Despite growing adoption of TLS [RFC5246], a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The WG has requested Experimental status because this draft specifies a new protocol for which implementation and usage experience is desired before producing a proposed standard. 2. Review and Consensus In response to concerns about pervasive surveillance, the tcpinc WG was formed in 2014 to produce a TCP extension that provides unauthenticated (opportunistic) encryption of TCP streams. The goal is universal encryption of TCP streams, increasing the burden of pervasive surveillance from passive dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks. An inability to achieve consensus on a single approach best characterizes the first year and a half of the WG's existence. There were two competing proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and fully-realized protocols, this mooted any collaboration or compromise. This inability to achieve consensus damaged the WG, as parties looking for a solution in this space grew weary of the lack of progress. Many who initially expressed interest in working on independent implementations lost interest and moved on to other work. Some progress was made during this time, notably the WG decided to provide length information for all data sent (rather than relying on packet length) to protect against resegmentation in the network. The logjam was successfully broken by three WG actions in the second half of 2015. The first was that the TCP extension functionality of tcpcrypt was split off into a separate proposal called TCP-ENO (Encryption Negotiation Option). This extension notably has the ability to negotiate multiple TCP stream encryption protocols, allowing potentially for runtime negotiation of either tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol). This draft contains the resulting TCP-ENO specification. The second action was initiated by the chairs. After the Transport AD changed the WG chairs in July 2015, the new chairs made a call for adoption of both tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that both protocols could be concurrently deployed. The logjam was finally broken by competing demands for the TLS community, including for the editor of the tcpinc-use-TLS draft, especially for completion of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the resulting rough consensus of the WG was that the appropriate course of action was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure that ENO could eventually support a TLS profile. Following this decision, rough consensus was achieved fairly rapidly, with only minor tweaks to the protocol since March 2016. Mailing list traffic has been very quiet since September 2016, and no tcpinc session was held at IETF 98 in Chicago. Expert reviews were conducted by Jake Holland and Wes Eddy, with important additional feedback from transport experts who are members of the tcpinc WG. No fundamental blocking issues have been revealed through review. The chairs would like an additional review by the Security Area Directorate in conjunction with the tcpcrypt draft. There is only one current implementation of tcpcrypt, that being the reference implementation by the Stanford team. At least one other implementation effort is in progress. The WG chairs believe that a reliable implementation distributed as part of a major operating system is the best approach to rekindling interest in this project and for encouraging the development of additional interoperating implementations. 3. Intellectual Property Each draft author has stated his/her direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points The original implementation of tcpcrypt squatted on TCP option kind 69, which caused some controversy and animated discussion on the mailing list. After some negotiation with Joe Touch, it was decided that tcpcrypt would be willing to bear the cost of this decision by requesting the same option for assignment by IANA. This draft requests the assignment of TCP option kind 69 to TCP-ENO. Tcpcrypt requires the addition of an IANA registry with expert review for "TCP-ENO Protocol Identifiers", the initial values for which are listed in section 10: this is code point allocation for the encryption protocols negotiated by TCP-ENO. In the case of tcpcrypt, this negotiation also includes the algorithm for initial exchange of ephemeral keys. Expert reviewers for this registry should be able to analyze a proposed key exchange algorithm for compatibility with the cryptographic requirements of tcpcrypt, and be generally familiar with security protocol design when reviewing applications for values to be assigned for TEPs other than tcpcrypt. A common reviewer is suggested for this registry and the "tcpcrypt AEAD parameter" registry created by the tcpcrypt draft, as tcpcrypt cryptographic parameter and algorithm changes impact both registries. Minimum criteria for a move from Experimental to Proposed Standard status should include substantive deployment experience spanning multiple implementations and networks and a BCP document describing deployment challenges and mitigations, especially with respect to successfully transiting middle boxes. |
2017-06-07
|
08 | David Black | TCP-ENO: Encryption Negotiation Option draft-ietf-tcpinc-tcpeno-08 1. Summary Document Shepherd: David Balck Responsible AD: Mirja Kühlewind Despite growing adoption of TLS [RFC5246], a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The WG has requested Experimental status because this draft specifies a new protocol for which implementation and usage experience is desired before producing a proposed standard. 2. Review and Consensus In response to concerns about pervasive surveillance, the tcpinc WG was formed in 2014 to produce a TCP extension that provides unauthenticated (opportunistic) encryption of TCP streams. The goal is universal encryption of TCP streams, increasing the burden of pervasive surveillance from passive dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks. An inability to achieve consensus on a single approach best characterizes the first year and a half of the WG's existence. There were two competing proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and fully-realized protocols, this mooted any collaboration or compromise. This inability to achieve consensus damaged the WG, as parties looking for a solution in this space grew weary of the lack of progress. Many who initially expressed interest in working on independent implementations lost interest and moved on to other work. Some progress was made during this time, notably the WG decided to provide length information for all data sent (rather than relying on packet length) to protect against resegmentation in the network. The logjam was successfully broken by three WG actions in the second half of 2015. The first was that the TCP extension functionality of tcpcrypt was split off into a separate proposal called TCP-ENO (Encryption Negotiation Option). This extension notably has the ability to negotiate multiple TCP stream encryption protocols, allowing potentially for runtime negotiation of either tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol). This draft contains the resulting TCP-ENO specification. The second action was initiated by the chairs. After the Transport AD changed the WG chairs in July 2015, the new chairs made a call for adoption of both tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that both protocols could be concurrently deployed. The logjam was finally broken by competing demands for the TLS community, including for the editor of the tcpinc-use-TLS draft, especially for completion of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the resulting rough consensus of the WG was that the appropriate course of action was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure that ENO could eventually support a TLS profile. Following this decision, rough consensus was achieved fairly rapidly, with only minor tweaks to the protocol since March 2016. Mailing list traffic has been very quiet since September 2016, and no tcpinc session was held at IETF 98 in Chicago. Expert reviews were conducted by Jake Holland and Wes Eddy, with important additional feedback from transport experts who are members of the tcpinc WG No fundamental blocking issues have been revealed through review. The chairs would like an additional review by the Security Area Directorate in conjunction wiht the tcpcrypt draft. There is only one current implementation of tcpcrypt, that being the reference implementation by the Stanford team. At least one other implementation effort is in progress. The WG chairs believe that a reliable implementation distributed as part of a major operating system is the best approach to rekindling interest in this project and for encouraging the development of additional interoperating implementations. 3. Intellectual Property Each draft author has stated his/her direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points The original implementation of tcpcrypt squatted on TCP option kind 69, which caused some controversy and animated discussion on the mailing list. After some negotiation with Joe Touch, it was decided that tcpcrypt would be willing to bear the cost of this decision by requesting the same option for assignment by IANA. This draft request the assignemnt of TCP option kind 69 to TCP-ENO Tcpcrypt requires the addition of an IANA registry with expert review for "TCP-ENO Protocol Identifiers", the initial values for which are listed in section 10: this is code point allocation for the encryption protocols negotiated by TCP-ENO. In the case of tcpcrypt, this negotiation also includes the elliptic curve used for the initial exchange of ephemeral keys. Expert reviewers for this registry should understand cryptographic techniques for and be familiar with security protocol design that achieve the unauthenticated encryption and related properties provided by TCP-ENO and tcpcrypt as the first example. A common reviewer is suggested for this registry and the "tcpcrypt AEAD parameter" registry created by the tcpcrypt draft, as tcpcrypt cryptographic parameter and algorithm changes impact both registries. Minimum criteria for a move from Experimental to Proposed Standard status should include substantive deployment experience spanning multiple implementations and networks and a BCP document describing deployment challenges and mitigations, especially with respect to successfully transiting middle boxes. |
2017-03-29
|
08 | David Black | Notification list changed to David Black <david.black@dell.com> |
2017-03-29
|
08 | David Black | Document shepherd changed to David L. Black |
2017-03-29
|
08 | David Black | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-03-08
|
08 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-08.txt |
2017-03-08
|
08 | (System) | New version approved |
2017-03-08
|
08 | (System) | Request for posting confirmation emailed to previous authors: Dan Boneh , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , … Request for posting confirmation emailed to previous authors: Dan Boneh , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley |
2017-03-08
|
08 | David Mazieres | Uploaded new revision |
2017-01-19
|
07 | Daniel Giffin | New version available: draft-ietf-tcpinc-tcpeno-07.txt |
2017-01-19
|
07 | (System) | New version approved |
2017-01-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , … Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , "Mark Handley" |
2017-01-19
|
07 | Daniel Giffin | Uploaded new revision |
2016-10-31
|
06 | Daniel Giffin | New version available: draft-ietf-tcpinc-tcpeno-06.txt |
2016-10-31
|
06 | (System) | New version approved |
2016-10-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , … Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , "Mark Handley" |
2016-10-31
|
05 | Daniel Giffin | Uploaded new revision |
2016-10-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , … Request for posting confirmation emailed to previous authors: "Andrea Bittau" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "David Mazieres" , "Dan Boneh" , "Mark Handley" |
2016-10-31
|
05 | David Mazieres | Uploaded new revision |
2016-10-25
|
05 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-05.txt |
2016-10-25
|
05 | (System) | New version approved |
2016-10-25
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "Andrea Bittau" , "David Mazieres" , "Dan Boneh" , … Request for posting confirmation emailed to previous authors: "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "Andrea Bittau" , "David Mazieres" , "Dan Boneh" , "Mark Handley" |
2016-10-25
|
04 | David Mazieres | Uploaded new revision |
2016-07-29
|
04 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-04.txt |
2016-07-08
|
03 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-03.txt |
2016-06-29
|
02 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-02.txt |
2016-04-06
|
01 | Cindy Morgan | Shepherding AD changed to Mirja Kühlewind |
2016-02-21
|
01 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-01.txt |
2015-10-14
|
00 | (System) | Notify list changed from draft-ietf-tcpinc-tcpeno.ad@ietf.org, tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpeno.shepherd@ietf.org, draft-ietf-tcpinc-tcpeno@ietf.org to (None) |
2015-10-01
|
00 | Martin Stiemerling | IESG process started in state AD is watching |
2015-10-01
|
00 | (System) | Earlier history may be found in the Comment Log for /doc/draft-bittau-tcpinc-tcpeno/ |
2015-09-30
|
00 | Mirja Kühlewind | Intended Status changed to Experimental from None |
2015-09-30
|
00 | Mirja Kühlewind | This document now replaces draft-bittau-tcpinc-tcpeno instead of None |
2015-09-30
|
00 | David Mazieres | New version available: draft-ietf-tcpinc-tcpeno-00.txt |