Ballot deferred by Amy Vezza on 2017-10-25.
Summary: Has enough positions to pass.Search Mailarchive
I agree with Adam's comment on Section 4.
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?
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.
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.
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.
Agree with other ADs' comments on needed clarifications.
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
The Gen-ART review comments should be addressed.
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.