[secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07

[Stephen Kent <[e-mail]>]

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 …