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

[Daniel B Giffin <[e-mail]>]

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.

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.

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

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

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.

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

> 
> The last sentence of 3.7 should be broken into several sentences; it is
> currently 7 lines long!

Ha, indeed ... done!

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

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.

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

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

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

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

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

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

Great, I've adopted the first and third suggestions.

Thanks again for your very thoughtful review!  I think this
has significantly improved the draft in quite a few ways.

daniel