[tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpeno-12: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/



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