[tcpinc] New tcpcrypt, API drafts posted
Daniel B Giffin <dbg@scs.stanford.edu> Thu, 03 November 2016 03:40 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 821061296AC for <tcpinc@ietfa.amsl.com>; Wed, 2 Nov 2016 20:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 VTkR35sQR48p for <tcpinc@ietfa.amsl.com>; Wed, 2 Nov 2016 20:40:43 -0700 (PDT)
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 47F6012946F for <tcpinc@ietf.org>; Wed, 2 Nov 2016 20:40:43 -0700 (PDT)
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 uA33egIh051995 for <tcpinc@ietf.org>; Wed, 2 Nov 2016 20:40:42 -0700 (PDT)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id uA33egZl063815 for tcpinc@ietf.org; Wed, 2 Nov 2016 20:40:42 -0700 (PDT)
Date: Wed, 02 Nov 2016 20:40:42 -0700
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: tcpinc <tcpinc@ietf.org>
Message-ID: <20161103034042.GB39379@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/LdQvYzm6upxJW6w5qJMxAMqbNrU>
Subject: [tcpinc] New tcpcrypt, API drafts posted
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <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, 03 Nov 2016 03:40:45 -0000
A couple days ago we submitted updates to these two drafts: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ https://datatracker.ietf.org/doc/draft-ietf-tcpinc-api/ The API section of tcpcrypt has been merged into draft-ietf-tcpinc-api. The other significant changes to tcpcrypt are: - Adopt the nomenclature changes ("TEP", "glt", etc.) made to the most recent draft of TCP-ENO - 3.2 Protocol negotiation: Clarify the semantics of signaling for session caching, explaining that "sending a resumption suboption also implies willingness to perform fresh key-exchange with the indicated TEP." - 3.4 Session caching: Constrain the circumstances in which resumption suboptions may be sent: In a particular SYN segment, a host SHOULD NOT send more than one resumption suboption, and MUST NOT send more than one resumption suboption with the same TEP identifier. But in addition to any resumption suboptions, an active opener MAY include non-resumption suboptions describing other key-agreement schemes it supports (in addition to that indicated by the TEP in the resumption suboption). Regarding interactions with TFO: The tcpcrypt specification does not define the semantics of data in a SYN+ENO segment, so the new language in TCP-ENO's section on "Data in SYN segments" dictates that a tcpcrypt implementation MUST NOT send such data.
- [tcpinc] New tcpcrypt, API drafts posted Daniel B Giffin