Subject: [tcpinc] Summary of changes: draft-ietf-tcpinc-tcpcrypt-11

From: Daniel B Giffin <[email-masked]>
Date: Wed, 29 Nov 2017 17:54:50 -0800

We've submitted a new tcpcrypt draft:

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

Here's a summary of the changes from -10 to -11:

  - Several typographical/wording improvements (due to Dale
    Worley's second review)

  - A note about reneging on SACKed segments when choosing
    to drop due to encryption failure or spurious FIN (due
    to Ekr's comment)

  - Resumption identifiers of unexpected size are now
    explicitly treated the same as any unrecognized
    resumption identifer: they are treated as a bare TEP
    (i.e., invitation to fresh key exchange).  This may
    permit some agility in how resumption is done in future.

  - Nonce size, previously fixed, is now determined by
    choice of AEAD, and "Frame ID" is zero-padded up to the
    nonce size (due to Ekr's comment)

  - Move Implementation-specific AEAD params out of IANA
    Considerations.  There are now two AEAD tables: one in
    IANA giving just the identifiers (and defining the new
    registry), and one in the protocol section that gives
    length parameters and implementation requirements.

  - This new text in section 3.3 Key Exchange (due to an
    oversight):

			 Implementations SHOULD provide an interface allowing the user to
			 specify, for a particular connection, the set of AEAD algorithms to
			 advertize in "sym_cipher_list" (when playing role "A") and also the
			 order of preference to use when selecting an algorithm from those
			 offered (when playing role "B").  A companion document
			 [I-D.ietf-tcpinc-api] describes recommended interfaces for this
			 purpose.

  - For consistency, uses of "session key" were changed to
    "session secret", and uses of "pre-session key" were
    changed to "original session secret"

Please speak up if any of this causes concern, and please
also see Kyle Rose's "Resumption safety" thread for
discussion of that last major design question.

daniel