[tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-tcpinc-tcpcrypt-09: 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-tcpcrypt/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a well-written document. I have some suggestions for improvement
(two minor, and one significant).

This document has several references to tables that are quite distant from the
table being referenced. It might be useful to readers if these were phrased
something like "Table 4 in section 7," so they know where to go looking for the
table.

Section 3.5 says:

   If an active opener receives a resumption suboption for a particular
   TEP and the received identifier-half does not match the "resume[i]"
   value whose other half it previously sent in a resumption suboption
   for the same TEP, it MUST ignore that suboption.  In the typical case
   that this was the only ENO suboption received, this means the host
   MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more
   ENO options and MUST NOT encrypt the connection.

I think the text here would benefit from pointing out that the client MUST NOT
attempt to resume a session with this host for the next TCP connection attempt.

____

Section 3.6 stipulates:

   When a frame is received, tcpcrypt reconstructs the associated data
   and frame nonce values (the former contains only data sent in the
   clear, and the latter is implicit in the TCP stream), and provides
   these and the ciphertext value to the the AEAD decryption operation.
   The output of this operation is either a plaintext value "P" or the
   special symbol FAIL.  In the latter case, the implementation MUST
   either drop the TCP segment(s) containing the frame or abort the
   connection; but if it aborts, the implementation MUST raise an error
   condition distinct from the end-of-file condition.

In the text above, the choice to "drop the TCP segment(s)" seems a little
underspecified, and both ways that I can interpret it are problematic.

In one interpretation, the TCP stack acts as if those packets were never
received, and so they are never acknowledged. Since retransmissions will
contain the same contents and also fail to decrypt, this is basically just
going to cause a connection failure upon expiration of the retransmission timer
-- in which case an immediate failure is clearly preferable.

The other interpretation is that the TCP packet is processed as received, but
that all of the data that could not be decrypted is elided from the stream of
bytes provided to the receiving application. This is also a problem, since many
applications rely on the in-order delivery aspects of TCP. The prospect that a
sender could provide "Message A", "Message B", and then"Message C" to its TCP
socket and the receiver only get "Message A" followed immediately by "Message
C" is not something that applications will generally be capable of handling. As
before, a connection reset would be preferable to violating the in-order
delivery guarantees of TCP.

Unless my analysis here is confused, I think this text needs to be changed to
conclude:

   In the latter case, the implementation MUST
   abort the connection and raise an error
   condition distinct from the end-of-file condition.