I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This document is the specification for tcpcrypt, which is targeted to be an Experimental RFC. It is generally very well written, but it could benefit from a few edits, as noted below. The introduction (section 2) is brief and well written, stating the goals for the design. Section 3 is much longer, providing a detailed description of the protocol. (Although the description is characterized as “abstract” it is very detailed, with only format details deferred to Section 4.) This section also is generally well-written. In 3.2 I suggest including a forward pointer to the IANA Considerations section, since that section describes how future TEPs may be added to the list in Table 2. In 3.5 the text says: When two hosts have previously negotiated a tcpcrypt session, either host may initiate session resumption regardless of which host was the active opener or played the "A" role in the previous session. It’s not clear to me in what time frame this comment is meant to apply, e.g., if two hosts established a tcpcrypt session a week ago, is this comment still supposed to be applicable? Some clarification here would be useful. The end of this section establishes a requirement for an interface to enable an application to control session caching. Are interfaces of this sort commonly provided to applications by an OS? If so, an example would be useful; if not, the authors should acknowledge that this requirement may be problematic, i.e., applications may require modification to make use of the mandated interface. In 3.6 the mention Table 3 also should refer to IANA Considerations, since that section describes how additions algorithms may be added. The last sentence of 3.7 should be broken into several sentences; it is currently 7 lines long! Section 3.8 describes a fairly complicated set of constraintsassociated with rekeying, some of which are inter-related. It might help to have a table here to describe how these constraints interact, e.g., when TCP-mandated retransmission takes place in the context of a rekey. I suggest the following editorial changes in section 3: … assigns different roles to -> … assigns the roles to the two hosts … ephemeral public keys for hosts A and B -> … ephemeral public key agreement keys for hosts A and B … whose length depends -> … the length of which depends … whose integer value -> … the integer value of which … security of the AEAD algorithm -> … security of every AEAD algorithm Section 4 describes the byte-level encoding for the data structures described in Section 3, as part of the tcpcrypt specification. In 4.1 found the description of the “ignored” data the INIT1_ and INIT2_ messages to be a bit confusing. I had to reread the descriptions to figure out that this was the authors’ way of saying that data beyond the end of the message (as indicated by the message_len field) is to be ignored upon reception. I don’t think the graphics used here are a great way to explain this. Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, in Table 2. Each algorithm is assigned a value in the 1-255 range, a much smaller range of values that used in protocols like TLS. The text in Section 7 might need to remind readers that this will argue against the registration of “vanity” AEAD algorithms for tcpcrypt. Security Considerations are described in Section 8. I found the phrase “Most implementations will rely on system-wide pseudo-random generators…” to be a bit confusing, because the ambiguity of the word “system” here. I presume this really refers to a single device in mots cases, e.g., a laptop, desktop, smartphone, right? I suggest a reference to RFC 4086 might be a good substitute for much of the text at the beginning of this section. I’d like the authors to provide a rationale for the advice: “…limit the lifetime of the private parameters, ideally to no more than two minutes.” This seems a bit arbitrary to me. Suggested editorial changes to Section 8: … is one on which -> is one for which … without guessing the content of the resumption identifier, -> without successfully guessing the value of the resumption identifier, Thus, tcpcrypt specifies a way … -> To counter this threat, tcpcrypt specifies a way …