[tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-13: Discuss

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/



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


----------------------------------------------------------------------
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<b=1,X,Y,Z>
             [rest of connection encrypted according to TEP Y]
Can you show a=0 in line 1?