Subject: [tcpinc] New draft of tcpcrypt posted

From: Daniel B Giffin <[email-masked]>
Date: Thu, 19 Jan 2017 20:14:48 -0800

We've posted a new draft of tcpcrypt:

  https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/

In addition to general improvements to the language, the substantive
changes to the protocol are as follows:

3.5.  Session caching

To identify a cached session for resumption, tcpcrypt previously sent
a prefix of the session ID in the clear.  But this conflicted with a
requirement in TCP-ENO:

   o  Unless and until applications disclose information about the
      session ID, all but the first byte MUST be computationally
      indistinguishable from random bytes to a network eavesdropper.

So the new tcpcrypt draft instead uses a distinct constant to derive a
"resumption identifier" from the relevant session secret:

  resume[i] = CPRF(ss[i], CONST_RESUME, 18)

Furthermore, where previously the active opener sent a nine-byte
identifier for the cached session and a passive opener agreed to
resume that session by sending an ENO suboption with `v = 1` but zero
suboption data, it now sends a *further* nine bytes of the identifier
(the second half of `resume[i]` above) in order to agree.  This
provides much more assurance against a collision of resumption
identifiers that would lead hosts to attempt communication with
incorrect keys.  It also avoids the need to permit zero-length data in
variable-length ENO suboptions.

Resumption continues to work with simultaneous open, as described in
the document. 

3.7.  TCP header protection

Where previously the document required recipients always to "ignore"
the TCP FIN flag in favor of the integrity-protected FINp, it now
says:

   When "FINp" is set, it indicates that the sender will send no more
   application data after this frame.  When the TCP FIN flag differs
   from "FINp", a receiving host MUST either ignore the segment
   altogether or abort the connection and raise an error condition
   distinct from the end-of-file condition.

---

From: David Mazieres <[email-masked]>
Date: Fri, 20 Jan 2017 12:05:56 -0800

There is a new draft of TCP-ENO, here:

        https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

There are very few changes from the previous draft, and most of them are
just cosmetic improvements or clarifications.  At the last meeting,
there was some discussion about whether the draft should allow a host to
send an ENO option with zero suboptions.  Upon further reflection, it
appeared there was really nothing in the existing draft that would
prevent such usage.  Hence, the only action we took on this question was
to clarify the situation by adding the following paragraph to the end of
section 4.6:

        A host MAY send a _vacuous_ SYN-form ENO option containing zero
        TEP identifier suboptions.  If either host sends a vacuous ENO
        option, it follows that there are no valid TEP identifiers for
        the connection and hence the connection must fall back to
        unencrypted TCP.  Hosts MAY send vacuous ENO options to indicate
        that ENO is supported but unavailable by configuration, or to
        probe network paths for robustness to ENO options.  However, a
        passive opener MUST NOT send a vacuous ENO option in a SYN-ACK
        segment unless there was an ENO option in the SYN segment it
        received.  Moreover, a passive opener's SYN-form ENO option MUST
        still include a global suboption with "b = 1", as discussed in
        Section 4.3.

David