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

Return-Path: <dbg@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9320A128C81; Thu, 16 Nov 2017 23:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYyNZos2kMBZ; Thu, 16 Nov 2017 23:32:32 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1646012741D; Thu, 16 Nov 2017 23:32:32 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAH7WVQS061115; Thu, 16 Nov 2017 23:32:31 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAH7WVsg082876; Thu, 16 Nov 2017 23:32:31 -0800 (PST)
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)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2017 07:32:34 -0000

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