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

["Black, David" <[e-mail]>]

Quick follow-up on this item:

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

It's fine to cite that draft as an informative reference - the resulting reference in the tcpcrypt RFC will (correctly) indicate that the API is work in progress.   Adding that reference would be a good thing to do.

OTOH, that draft should not be cited as a normative reference, for reasons that include the inappropriateness of mandating that API for all implementations.

Thanks, --David

> -----Original Message-----
> From: Daniel B Giffin [mailto:[e-mail]]
> Sent: Friday, October 20, 2017 9:37 PM
> To: Stephen Kent <[e-mail]>
> Cc: [e-mail]; Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: SECDIR review of draft-ietf-t cpinc-tcpcrypt-07
> 
> 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