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

Daniel B Giffin <dbg@scs.stanford.edu> Thu, 30 November 2017 01:54 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 85250127B5A for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 17:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 9jH2tYWqEZpI for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 17:54:51 -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 0847D126FDC for <tcpinc@ietf.org>; Wed, 29 Nov 2017 17:54:51 -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 vAU1sohU078792 for <tcpinc@ietf.org>; Wed, 29 Nov 2017 17:54:50 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAU1so8Z006672 for tcpinc@ietf.org; Wed, 29 Nov 2017 17:54:50 -0800 (PST)
Date: Wed, 29 Nov 2017 17:54:50 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: tcpinc <tcpinc@ietf.org>
Message-ID: <20171130015450.GA70986@scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/HFDas_2yGURDq_Ta_PzGDgZ5sIs>
Subject: [tcpinc] Summary of changes: draft-ietf-tcpinc-tcpcrypt-11
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: Thu, 30 Nov 2017 01:54:52 -0000

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