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

Daniel B Giffin <dbg@scs.stanford.edu> Fri, 17 November 2017 07:32 UTC

Date: Thu, 16 Nov 2017 23:32:31 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Ben Campbell <ben@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, Kyle Rose <krose@krose.org>, tcpinc-chairs@ietf.org, tcpinc@ietf.org
Message-ID: <20171117073231.GB57159@scs.stanford.edu>
References: <151038195719.16096.10304916264269485497.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <151038195719.16096.10304916264269485497.idtracker@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/cwEuFAzsRfRx4-1A1lHQZFieDVY>
Subject: Re: [tcpinc] Ben Campbell's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
Precedence: list

Ben Campbell wrote:
> ----------------------------------------------------------------------
> 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?

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

[tcpinc] Ben Campbell's Yes on draft-ietf-tcpinc-… Ben Campbell
Re: [tcpinc] Ben Campbell's Yes on draft-ietf-tcp… Daniel B Giffin