[tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-tcpinc-tcpcrypt-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I really like this draft, and I can understand it fairly well. I do have some
questions to go along with my Yes ballot.

This SHOULD NOT

  o  "PK_A", "PK_B": ephemeral public keys for hosts A and B,
      respectively.  These, as well as their corresponding private keys,
      are short-lived values that SHOULD be refreshed periodically.  The
      private keys SHOULD NOT ever be written to persistent storage.

is just begging for some justification as to why this is important enough to be
a SHOULD NOT, and not important enough to be a MUST NOT. Could you give an
example of a reason why this would be a good idea?

It's likely that everyone but me knows why

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

is "18" and not some other integer, but there's no explanation or reference
that I could find explaining why.

It would be helpful to explain why

  In a particular SYN segment, a host SHOULD NOT send more than one
   resumption suboption,

is a SHOULD NOT, since it's allowed, so doing so must have some purpose.

This

  A host SHOULD NOT initiate more than one concurrent re-key operation
   if it has no data to send; that is, it should not initiate re-keying
   with an empty encryption frame more than once while its record of the
   remote generation number is less than its own.

is allowed - could you explain why a host would need to violate that SHOULD NOT?

Just for my benefit - Section 8.3 explains why ECDHE using Curve25519 has been
chosen as MTI, but also explains why ECDHE using P-256 has not been chosen as a
second MTI. Is the intention to discourage use of ECDHE using P-256 at all,
based on the concerns expressed about making it MTI?

Also for my benefit, but somewhat more worrying - is the working group fairly
confident that a specifying second MTI key management scheme will be possible
at some point, that does not trip over the problems described in [nist-ecc] and
can be implemented in kernels, or is conforming to the guidance in [RFC7696]
going to be problematic? I see Mirja mentioned SEC discussions about only one
MTI key management mechanism being chosen now, but my question is a little
different - I'm asking if the situation is likely to improve anytime soon.