[Tcpcrypt] v3 of the charter
marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 30 April 2014 06:35 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: tcpcrypt@ietfa.amsl.com
Delivered-To: tcpcrypt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A336D1A6EE2 for <tcpcrypt@ietfa.amsl.com>; Tue, 29 Apr 2014 23:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.852
X-Spam-Level:
X-Spam-Status: No, score=-104.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 9ah_qPCJoIO6 for <tcpcrypt@ietfa.amsl.com>; Tue, 29 Apr 2014 23:35:14 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B68BF1A6EE0 for <tcpcrypt@ietf.org>; Tue, 29 Apr 2014 23:35:13 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7395CCD3DE6 for <tcpcrypt@ietf.org>; Wed, 30 Apr 2014 08:35:11 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from dummyhost11.it.uc3m.es (unknown [163.117.139.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 687A1CC5E82 for <tcpcrypt@ietf.org>; Wed, 30 Apr 2014 08:35:11 +0200 (CEST)
Message-ID: <536099A0.30900@it.uc3m.es>
Date: Wed, 30 Apr 2014 08:35:12 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: tcpcrypt@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20664.005
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/C3MLGRTk1SVfaWrX4s8SloD05AE
Subject: [Tcpcrypt] v3 of the charter
X-BeenThere: tcpcrypt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpcrypt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpcrypt/>
List-Post: <mailto:tcpcrypt@ietf.org>
List-Help: <mailto:tcpcrypt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 06:35:19 -0000
Hi, I have tried to incorporate the comments received. This resulted in quite a bit of changes, so, i would appreciate feedback (for example, feedback like "the charter looks great and is ready to go" would be nice, but if you have other feedback it will be welcome as well). TCP Increased Security (TCP Inc.) The TCP Inc. WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define an unauthenticated key exchange mechanism. In addition, the WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man-in-the-middle attacks. This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring (see draft-farrell-perpass-attack). The goal of this WG is to provide an additional security tool that complements existing protocols at other layers in the stack. The WG will be looking for the designs that find the right tradeoff spot between conflicting requirements: to provide reasonable security for the majority of connections. Because we are dealing with unprotected connections, we are more focussed on improving from baseline of no security than achieving the high standard of security that is already available to users of TLS. Providing unauthenticated encryption and integrity protection at the TCP layer will provide a set of features that cannot be achieved with existing tools, namely, encryption and integrity protection without modifications to the upper ayers (no API changes), encryption and integrity protection with forward secrecy with a per-connection granularity, simple NAT and firewall traversal capabilities, key rollover without significant impact to the TCP connection, lower overhead compared to solutions relying in stacking multiple protocols to achieve different features, no manual configuration required. A more detailed description of the motivations for TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925. The working group is looking to produce experimental documents specifying the required TCP extensions and any additional documents needed. The high-level requirements for the protocol for providing TCP unauthenticated encryption and integrity protection are: - Deployable and usable without significant changes to existing Internet infrastructure, in particular it must be compatible with NATs (at the very minimum with the NATs that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508); - The protocol must be usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be changed in a backward compatible way. It also provides some protection in scenarios where people are unwilling to do any change just for the sake of security (e.g., like configure encryption in an application). - The protocol must provide cryptographic algorithm agility. - Must gracefully fall-back to TCP if the remote peer does not support the proposed extensions - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Should attempt to use the least amount of TCP option space, especially in SYN segments. - Must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance. For example, the protocol may try to re-use existing cryptographic material for future communication between the same endpoints to avoid expensive public key operations on connection set up. When encryption is enabled, then the protocol: - must always provide forward secrecy. - must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or not be protected) - must always provide payload encryption. - must not provide extra linkability. When encryption is enabled the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same client when connecting to a remote peer on subsequent occasions. This should either be the default (clients cannot be "fingerprinted" by the server based on shared state) or some mechanism should be available for clients to drop or ignore shared state to avoid being fingerprintable any more than would be present for a cleartext session. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for unauthenticated encryption and integrity protection of TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with external authentication mechanisms, the expected protection, privacy considerations and residual threats. - Definition of the unauthenticated key exchange mechanism and the extensions to current TCP to utilize unauthenticated key to provide encryption and integrity protection. This covers all the protocol changes required. This will be an experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting external authentication will be defined in this document. This will be an informational document.
- Re: [Tcpcrypt] v3 of the charter David Mazieres
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter Stephen Farrell
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter ianG
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Tony Arcieri
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Tony Arcieri
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter David Mazieres
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter ianG
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Christian Huitema
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Erik Nygren
- Re: [Tcpcrypt] v3 of the charter David Mazieres