TCP-ENO: Encryption Negotiation Option

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) Yes

Comment (2017-11-10 for -13)
No email
send info
I agree with Adam's comment on Section 4.

(Spencer Dawkins) Yes

Comment (2017-10-25 for -12)
No email
send info
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,

      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?


  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?

Warren Kumari Yes

Comment (2017-11-28 for -17)
No email
send info
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! ]

(Mirja Kühlewind) Yes

(Alexey Melnikov) Yes

Comment (2017-11-26 for -17)
No email
send info
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.

(Kathleen Moriarty) Yes

Comment (2017-11-11 for -13)
No email
send info
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.

(Adam Roach) Yes

Comment (2017-11-06 for -13)
No email
send info
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

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:
      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

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.

(Alia Atlas) No Objection

Comment (2017-10-25 for -12)
No email
send info
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.

Deborah Brungard No Objection

Comment (2017-11-11 for -13)
No email
send info
Agree with other ADs' comments on needed clarifications.

(Benoît Claise) No Objection

Comment (2017-11-10 for -13)
No email
send info
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

Alissa Cooper No Objection

Comment (2017-11-10 for -13)
No email
send info
The Gen-ART review comments should be addressed.

(Suresh Krishnan) No Objection

(Terry Manderson) No Objection

(Eric Rescorla) (was Discuss) No Objection

Comment (2017-11-16 for -16)
No email
send info
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<a=0,X,Y>
                (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.

Alvaro Retana No Objection