[tcpinc] New draft of tcpcrypt posted
Daniel B Giffin <dbg@scs.stanford.edu> Fri, 20 January 2017 04:14 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 8E3DB126BF7 for <tcpinc@ietfa.amsl.com>; Thu, 19 Jan 2017 20:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 QQ-rHIppdps5 for <tcpinc@ietfa.amsl.com>; Thu, 19 Jan 2017 20:14:49 -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 5A188126579 for <tcpinc@ietf.org>; Thu, 19 Jan 2017 20:14:49 -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 v0K4En5q044884 for <tcpinc@ietf.org>; Thu, 19 Jan 2017 20:14:49 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v0K4Em5m054869 for tcpinc@ietf.org; Thu, 19 Jan 2017 20:14:48 -0800 (PST)
Date: Thu, 19 Jan 2017 20:14:48 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: tcpinc <tcpinc@ietf.org>
Message-ID: <20170120041448.GA1063@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/KkX2ron7e1zllI2wcpi2E-vwbnA>
Subject: [tcpinc] New draft of tcpcrypt posted
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jan 2017 04:14:50 -0000
We've posted a new draft of tcpcrypt: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ In addition to general improvements to the language, the substantive changes to the protocol are as follows: 3.5. Session caching To identify a cached session for resumption, tcpcrypt previously sent a prefix of the session ID in the clear. But this conflicted with a requirement in TCP-ENO: o Unless and until applications disclose information about the session ID, all but the first byte MUST be computationally indistinguishable from random bytes to a network eavesdropper. So the new tcpcrypt draft instead uses a distinct constant to derive a "resumption identifier" from the relevant session secret: resume[i] = CPRF(ss[i], CONST_RESUME, 18) Furthermore, where previously the active opener sent a nine-byte identifier for the cached session and a passive opener agreed to resume that session by sending an ENO suboption with `v = 1` but zero suboption data, it now sends a *further* nine bytes of the identifier (the second half of `resume[i]` above) in order to agree. This provides much more assurance against a collision of resumption identifiers that would lead hosts to attempt communication with incorrect keys. It also avoids the need to permit zero-length data in variable-length ENO suboptions. Resumption continues to work with simultaneous open, as described in the document. 3.7. TCP header protection Where previously the document required recipients always to "ignore" the TCP FIN flag in favor of the integrity-protected FINp, it now says: When "FINp" is set, it indicates that the sender will send no more application data after this frame. When the TCP FIN flag differs from "FINp", a receiving host MUST either ignore the segment altogether or abort the connection and raise an error condition distinct from the end-of-file condition.
- [tcpinc] New draft of tcpcrypt posted Daniel B Giffin
- [tcpinc] New draft of TCP-ENO David Mazieres