Subject: [tcpinc] Ben Campbell's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Nov 2017 22:32:37 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-tcpinc-tcpcrypt-09: 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:
----------------------------------------------------------------------

In section 3.3, the last bullet: Why are the SHOULDs not MUSTs? Do you envision
times where it might make sense not refresh an ephemeral public key, or write
one to persistent storage?

---

From: Daniel B Giffin <[email-masked]>
Date: Thu, 16 Nov 2017 23:32:31 -0800

No, I can't really envision the reason for persistent
storage, but it's conceivable there is some setting where
there is a safe way to cache private keys in something that
is technically "persistent".  Perhaps it is silly to worry
about allowing this, but I don't want to cause undue trouble
by specifying a MUST on something that would anyway be
difficult to detect from outside the implementation.

Anyway, I've strengthened the language to "MUST be refreshed
as frequently as practically possible" and also referenced
the Security Considerations section:

   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 MUST be refreshed as frequently as
      practically possible.  The private keys SHOULD NOT ever be written
      to persistent storage.  The security risks associated with the
      storage of these keys are discussed in Section 8.

The relevant paragraph of Security Considerations now reads:

   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 MUST limit the lifetime
   of the private parameters as far as practical in order to minimize
   the number of past connections that are vulnerable.  Of course,
   placing private keys in persistent storage introduces severe risks
   that they may not be destroyed reliably and in a timely fashion, and
   SHOULD be avoided at all costs. 

daniel