Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Sat, 04 February 2017 19:40 UTC
Return-Path: <dm-list-tcpcrypt@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 AF0F612947B for <tcpinc@ietfa.amsl.com>; Sat, 4 Feb 2017 11:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 byhMRuSFyFwA for <tcpinc@ietfa.amsl.com>; Sat, 4 Feb 2017 11:40:50 -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 E33461294F6 for <tcpinc@ietf.org>; Sat, 4 Feb 2017 11:40:50 -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 v14JemFT001927; Sat, 4 Feb 2017 11:40:48 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v14JemQi005035; Sat, 4 Feb 2017 11:40:48 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Holland, Jake" <jholland@akamai.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>
In-Reply-To: <A0905A32-A224-4F51-8AC3-8CA01E259AE2@akamai.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com> <87o9yin11j.fsf@ta.scs.stanford.edu> <A0905A32-A224-4F51-8AC3-8CA01E259AE2@akamai.com>
Date: Sat, 04 Feb 2017 11:40:45 -0800
Message-ID: <87bmuh218i.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/_C9jlHfbDODxvIyA5iZxagGXekk>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-05 PDT <mazieres-gj57ihurinrx3a8rbkcc6pdpia@temporary-address.scs.stanford.edu>
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: Sat, 04 Feb 2017 19:40:52 -0000
Okay, here is some proposed language. For the definition of the "a" bit: a Legacy applications can benefit from updating their behavior to take advantage of TCP-level encryption, for instance by improving endpoint authentication or avoiding double encryption. The application-aware bit "a" is an out-of-band signal that such applications can use to indicate support for ENO-specific updates when high-layer protocols lack a backwards-compatible means of doing so. Implementations MUST set this bit to 0 by default, and SHOULD provide an API through which applications can change the value of the bit as well as examine the value of the bit sent by the remote host. Implementations SHOULD furthermore support a _mandatory_ application-aware mode in which TCP-ENO is automatically disabled if the remote host does not set "a = 1". For security considerations: Achieving stronger security with TCP-ENO requires verifying session IDs. Any application relying on ENO for communications security MUST incorporate session IDs into its endpoint authentication. By way of example, an authentication mechanism based on keyed digests (such Digest Access Authentication [RFC7616]) can be extended to include the role and session ID in the input of the keyed digest. Applications MAY use the application-aware "a" bit to negotiate the inclusion of session IDs in authentication even when there is no in- band way to carry out such a negotiation. Because there is only one "a" bit, however, a protocol extension that specifies use of the "a" bit will likely require a built-in versioning or negotiation mechanism to accommodate crypto agility and future updates. Added the third sentence to the first paragraph of 5.1 (Session IDs): Each TEP MUST define a session ID that is computable by both endpoints and uniquely identifies each encrypted TCP connection. Implementations MUST expose the session ID to applications via an API extension. The API extension MUST return an error when no session ID is available because ENO has failed to negotiate encryption or because no connection is yet established. Applications that are aware of TCP-ENO SHOULD, when practical, authenticate the TCP endpoints by incorporating the values of the session ID and TCP-ENO role (A or B) into higher-layer authentication mechanisms. So now it is clear that you can check for an error on the call to retrieve the session ID (meaning TCP-ENO succeeded if and only if you get a session ID). I also got rid of the citations to internet drafts. Now 7.1 (future developments) reads: Various proposals exist to increase the maximum space for options in the TCP header. Though these proposals are highly experimental-- particularly those that apply to SYN segments--TCP-layer encryption could significantly benefit from the availability of increased SYN option space. In particular, if future TEPs can perform key agreement by embedding public keys or Diffie-Hellman parameters within suboption data, it will simplify protocols and reduce the number of round trips required for connection setup. With large options, the 32-byte limit on length bytes could prove insufficient. This draft intentionally aborts TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. Any document updating TCP's option size limit can also define the format of larger suboptions by updating this draft to assign meaning to such currently undefined byte sequences. I also changed manual to explicit, as you suggested. Thanks, David
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Scharf, Michael (Nokia - DE)
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Scharf, Michael (Nokia - DE)
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Black, David