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

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Oct 2017 12:55:40 -0400

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 …

---

From: Daniel B Giffin <[email-masked]>
Date: Fri, 20 Oct 2017 18:37:02 -0700

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

> 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

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.

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

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

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

> Thus, tcpcrypt specifies a way … -> To counter this threat, tcpcrypt

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Oct 2017 11:30:38 -0400

Daniel,

Thanks for the response.
> policy for assignment of TEP identifiers lives in TCP-ENO.
OK.
>    with tcpcrypt, following the assignment policy specified
Great.
>     may later establish a new connection without public-key operations
Good.
>     was the active opener or played the "A" role in the previous session.
Great.
> 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.
>     selected during the negotiation described in Section 3.3.
Good.
>> The last sentence of 3.7 should be broken into several sentences; it is
thanks.
>     transmitted, regardless of the current local generation number.
that's better.
> merely a note to help implementations avoid offending TCP.
good.
>    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,  ... :-)
> necessary for the security of the AEAD algorithms specified
yes, that's a good clarification.
> 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.
> RFC 4086 to replace the details of the first three
OK.
>     minimize the number of past connections that are vulnerable.
Much better!

Steve

---

From: Daniel B Giffin <[email-masked]>
Date: Tue, 24 Oct 2017 00:07:59 -0700

Hi Stephen et al.,

Below is some discussion about the number of bits devoted to
negotiating the symmetric cipher (currently eight for
tcpcrypt) ...

Stephen Kent wrote:
> 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

If you could let us know what protocols you mean, that would
be a helpful point of comparison.  It looks like the main
TLS 1.3 document specifies only five symmetric algorithms,
but of course other documents could supplement this
arbitrarily; I guess I should look at OpenSSL or something
to see how many are actually supported.

Concerning "nation-specific algorithms", do you mean that
the number of needed symmetric-encryption algorithms could
be on the same order as the number of countries in the
world?

If there's a need to mention how the code-space for
symmetric ciphers could be expanded, maybe we should
seriously consider allocating 16 bits to this; I just don't
have a good handle on the order of magnitude that is
plausibly needed.

daniel

---

From: "Black, David" <[email-masked]>
Date: Tue, 24 Oct 2017 13:44:28 +0000

Stephen,

> > > > smaller range of values that used in protocols like TLS. The

This does not appear to be a significant problem in practice - a quick scan of the TLS ciphersuite registry (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) turns up less than half-a-dozen encryption algorithms that appear to be nation-specific.

The two primary reasons for the massive size of that TLS registry are:
	a) a bunch of obsolete cr*p that SHOULD NOT be used (e.g., RC4, DES and  EXPORT ciphersuites); and
	b) the combinatorics of registering all the possible TLS ciphersuites, courtesy of the number of components in a TLS ciphersuite.
Neither of those apply to tcpcrypt.

> > > TCP-ENO is a big escape-hatch in terms of extensibility.

Thanks, --David

> -----Original Message-----
> From: Daniel B Giffin [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2017 3:08 AM
> To: Stephen Kent <[email-masked]>
> Cc: [email-masked]; Black, David <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: SECDIR review of draft-ietf-t cpinc-tcpcrypt-07
> 
> Hi Stephen et al.,
> 
> tcpcrypt,

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Oct 2017 17:02:36 -0400

Daniel,

> to see how many are actually supported.
My comments are based on my experiences with IPsec (ESP and AH). If you 
look at RFCs 4305,
4835,  and 7321, you see a set of algs that have been recommended, and 
ones that have been
deprecated over many years. There are a fair number of them when one 
looks at the need
to specify both an encryption alg and an integrity alg. We started with 
DEC-CBC and MD5,
moved on to triple DES-CBC and several SHA-based MACs, then AES-CBC (in 
3 key lengths) with
SHA MACs, plus AES-GMAC (3 key lenghts) and AES-GCM (3 key lengths).  
Don't forget outliers
like SKIPKACK, RC4, RC5, Blowfiosh, Twofish, Threefish, CAST, and IDEA. 
One might add Salsa20, ChaCha, Poly1305-AES to the list of more recent 
options, if anyone wanted to register them.
Note that even when we deprecate an alg it may live on for a long time 
in implementations.

> be on the same order as the number of countries in the
not likely, but potentially, and I would not like to have IANA rejecting 
a national
alg because of limited ID space. In the IPsec arena, we had SEED (South 
Korea),
GOST symmetric crypto and MAC algs (Russia), and Camilla (Japan) all 
defined for
use ion the IPsec environment. Nothing makes for a good international 
incident like
having the IETF reject some country's request for an alg ID.
> have a good handle on the order of magnitude that is
I'd prefer 16 bits, just to be safe, based on the IPsec experiences and 
a strong desire
to NEVER reuse IDs.

Steve