Skip to main content

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
[Ballot comment]
In Section 10 RFC 5802 would be a better example than RFC 7616, because the former already has a slot for "channel …
[Ballot comment]
In Section 10 RFC 5802 would be a better example than RFC 7616, because the former already has a slot for "channel binding" (session-id being an example) information and generally improves on security properties of Digest.
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. …
                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. …
                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. …
                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. …
                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