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

[Stephen Kent <[e-mail]>]

Daniel,

Thanks for the response.
> Hi Stephen,
>
> Thanks very much for your detailed review!
>
> So that others can see how your notes will be incorporated
> into the next draft, I'll respond to them below.
>
> (Where I take an interactive tone below, I don't mean that
> you need to respond.  Although more discussion is welcome, I
> will go ahead with the changes I propose.)
>
>> 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.
> Well, although this document provides (in the IANA
> Considerations section) a policy for assignment of
> identifiers to the "tcpcrypt AEAD Algorithm" registry", the
> policy for assignment of TEP identifiers lives in TCP-ENO.
OK.
> How about changing the last sentence of the first paragraph
> of 3.2 from:
>
>    Future standards may associate additional identifiers with
>    tcpcrypt.
>
> to instead:
>
>    Future standards may associate additional TEP identifiers
>    with tcpcrypt, following the assignment policy specified
>    by TCP-ENO.
Great.
>
>> 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.
> Regarding the timeframe for resumption: I see how our
> language is confusing.  I'll replace the first sentence of
> the first paragraph of this section with:
>
>     If two hosts have previously negotiated a tcpcrypt session secret
>     "ss[i-1]", and have cached the derived session secret "ss[i]", they
>     may later establish a new connection without public-key operations
>     using "ss[i]".
Good.
>
> ... and then also replace the paragraph you mention with:
>
>     If two hosts have previously negotiated a tcpcrypt session, either
>     host may later initiate session resumption regardless of which host
>     was the active opener or played the "A" role in the previous session.
Great.
>
> These changes are subtle, but I hope they better convey
> (together with the rest of the section) that resumption with
> a particular session secret may be performed once, at any
> time later, provided that both hosts have cached the secret.
>
> Regarding interfaces: Although applications can benefit from
> tcpcrypt without knowledge of it (and thus without having to
> configure it), this document nevertheless requires
> implementations of tcpcrypt to provide an interface for
> configuring some aspects of its operation; this permits
> tcpcrypt-aware applications the control they need to build
> even-more-secure arrangements.
>
> The working group has an Informational draft suggesting how
> best to extend OS interfaces to include the configuration of
> TCP-ENO and tcpcrypt, using mechanisms (socket options and
> sysctls) present in most popular operating systems:
>
>    https://datatracker.ietf.org/doc/draft-ietf-tcpinc-api/
>
> I can see that reading the tcpcrypt document alone leaves
> questions about how to meet the API requirements; but of
> course we aren't in a position to cite the not-yet-published
> API draft.  I don't know enough about how related RFCs could
> be brought to the attention of readers, so suggestions to
> address this are welcome.
David's message explained how to refer to that I-D w/o making it a 
gating factor for this one.
>
>> In 3.6 the mention Table 3 also should refer to IANA Considerations, since
>> that section describes how additions algorithms may be added.
> Thanks, I'm changing the relevant paragraph to read:
>
>     This protection is provided via algorithms for Authenticated
>     Encryption with Associated Data (AEAD).  The particular algorithms
>     that may be used are listed in Table 3, and additional algorithms may
>     be specified according to the policy in Section 7.  One algorithm is
>     selected during the negotiation described in Section 3.3.
Good.
>
>> The last sentence of 3.7 should be broken into several sentences; it is
>> currently 7 lines long!
> Ha, indeed ... done!
thanks.
>
>> 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.
> Certainly that is a delicate section.  Although I can't
> quite picture the table you're suggesting, I have reworked
> the paragraph mentioning TCP retransmission as follows:
>
>     Note that when parts of the datastream are retransmitted, TCP
>     requires that implementations always send the same data bytes for the
>     same TCP sequence numbers.  Thus, frame data in retransmitted
>     segments must be encrypted with the same key as when it was first
>     transmitted, regardless of the current local generation number.
that's better.
>
> I'm hoping that makes it more clear that retransmission and
> rekeying shouldn't really interact at all: this paragraph
> doesn't impose any new constraints, and I've changed to a
> lower-case "must" to avoid the appearance of one.  It is
> merely a note to help implementations avoid offending TCP.
good.
>
>> 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
> Great, I've mostly incorporated these suggestions.
>
> Although I understand it might not sound quite right to
> every ear, I couldn't bring myself to abandon those
> applications of "whose" to inanimate objects.  I mean hey,
> two less words than "the _ of which"!  And although I don't
> want to argue by authority or precedent, these literary
> examples sound elegant and clear to me:
>
>    https://english.stackexchange.com/questions/23541/can-whose-refer-to-an-inanimate-object
I believe Strunk & White is more restrictive, but then I'm a guy who's 
picky about using which vs. that, fewer vs. less,  ... :-)
>
> And as for nonce-reuse in AEAD algorithms, I guess we
> shouldn't say it is strictly verboten for *every* algorithm,
> as there are new "nonce-misuse resistant" algs coming down
> the pipe.  So I've gone with: "Because it is strictly
> necessary for the security of the AEAD algorithms specified
> in this document, ..."
yes, that's a good clarification.
>
>> 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.
> Yes ... I'll try to find a better way.
>
>> 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.
> Hm yes, I see that TLS 1.3 uses a two-byte identifier for a
> similar purpose, although it looks like this specifies both
> an AEAD algorithm and an HKDF.
>
> Well, although the code-space used by tcpcrypt is small,
> TCP-ENO is a big escape-hatch in terms of extensibility.
> For example, tcpcrypt could be extended with additional TEPs
> whose only difference is to map the symmetric-cipher
> identifier-bytes to different meanings.  Not the prettiest
> solution, but perhaps acceptable if one is optimistic that
> exhaustion is unlikely anyway?
We've seen nation-specific algorithms proposed as optional for use with 
a number of
security protocols, which is why I mention this issue. An allusion to 
the potential
to expand this space, if needed, would be useful here.
>
>> 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.
> Right.  I'll clarify that, and also consider invoking
> RFC 4086 to replace the details of the first three
> paragraphs.
OK.
>
>> 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.
> Indeed.  I've reworked that paragraph as follows:
>
>     Tcpcrypt uses short-lived public keys to provide forward secrecy.
>     That is, once an implementation removes these keys from memory, a
>     compromise of the system will not provide any means to derive the
>     session keys for past connections.  All currently specified key
>     agreement schemes involve ECDHE-based key agreement, meaning a new
>     keypair can be efficiently computed for each connection.  If
>     implementations reuse these parameters, they SHOULD limit the
>     lifetime of the private parameters as far as practical in order to
>     minimize the number of past connections that are vulnerable.
Much better!


Steve