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