Re: [Tcpcrypt] New version of the charter text
marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 23 April 2014 17:04 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 A14781A03D3 for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 10:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.126
X-Spam-Level:
X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 aNBiJ2MAgR9S for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 10:04:05 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D66C11A03B6 for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 10:04:04 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C4B40CD41C1 for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 19:03:58 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [10.0.1.2] (232.174.78.188.dynamic.jazztel.es [188.78.174.232]) (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 88936CD7826 for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 19:03:58 +0200 (CEST)
Message-ID: <5357F2AD.9070307@it.uc3m.es>
Date: Wed, 23 Apr 2014 19:04:45 +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
References: <53576572.5030805@it.uc3m.es> <5357F05C.3060507@isi.edu>
In-Reply-To: <5357F05C.3060507@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20652.000
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/x98CzUx3SuY-IZ-w4J3vNrFMajY
Subject: Re: [Tcpcrypt] New version of the charter text
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, 23 Apr 2014 17:04:08 -0000
El 23/04/14 18:54, Joe Touch escribió: > Hi, all, > > Comments below... > > Joe > > > On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote: > ... >> TCP Increased Security (TCP Inc.) > > I like the title, FWIW. > >> The TCP Inc. WG will develop the TCP extensions to provide >> unauthenticated >> encryption and integrity protection of TCP streams. > > OK so far... > > > The WG will define the >> TCP extensions to perform an unauthenticated key exchange resulting in >> encryption >> without authentication. > > This implies in-band. Yes, the idea here is to provide a fully automatic mechanism, that people simply install and dont need to configure keys or anything. I think this is a fundamental feature. I am ok with allowing the use of other keys if they are available, but i strongly believe key exchange is a core part of this. Regards, marcelo > I don't think in-band key exchange is viable; there's no way to > protect the SYNs, and it might sufficiently increase SYN processing > and server state to make a much larger attack surface. > > I would optimally prefer out-of-band exchange, perhaps that could be > bootstrapped with an initial in-band exchange. Less optimal would be > to leave this issue open for the WG to discuss, but I definitely don't > agree with mandating only in-band key exchange. > > I would thus prefer: > > 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). > > It also leverages the original principle of BTNS, FWIW. > >> The working group is looking to produce experimental documents >> specifying the >> required TCP extensions and any additional informational 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). >> >> - When encryption is enabled, it must at least provide protection >> against >> passive eavesdropping by default, >> >> - Must gracefully fall-back to TCP if the remote peer does not >> support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it 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) >> >> - When encryption is enabled, it must always provide payload encryption. >> >> - 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. >> >> - Hooks for allowing upper layers to disable encryption must be made >> available. >> The protocol may try to avoid redundant encryption when it is >> possible e.g. >> by detecting encryption performed by upper layers (notably, when TLS >> is used). > > When TLS is used, this defeats TCP-INC's ability to protect the TCP > header. > > It's OK to allow hooks to turn this off, but a better use case should > be provided as motivation. > >> - No 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. >> >> - Client 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. > > This should also include "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. >> >> - Extensions to current TCP to support unauthenticated key exchange and >> encryption and >> integrity protection. This covers all the protocol changes required. >> This will be a >> 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 and the hooks for disabling encryption. >> This will be an informational document. >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt >
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Scharf, Michael (Michael)
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text John-Mark Gurney
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text John-Mark Gurney
- Re: [Tcpcrypt] New version of the charter text Wesley Eddy
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text Tony Arcieri
- Re: [Tcpcrypt] New version of the charter text Stephen Farrell
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text ianG
- Re: [Tcpcrypt] New version of the charter text marcelo bagnulo braun
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen
- Re: [Tcpcrypt] New version of the charter text Joe Touch
- Re: [Tcpcrypt] New version of the charter text Tero Kivinen