Re: [Tcpcrypt] New version of the charter text

marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 23 April 2014 17:54 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 C5B641A0464 for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 10:54:02 -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 LBb6P_TGCZTb for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 10:53:59 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FC1A045E for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 10:53:59 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2390F11C5C6B; Wed, 23 Apr 2014 19:53:52 +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@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id E2E6F11C5C69; Wed, 23 Apr 2014 19:53:51 +0200 (CEST)
Message-ID: <5357FE5E.3070307@it.uc3m.es>
Date: Wed, 23 Apr 2014 19:54:38 +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: Joe Touch <touch@isi.edu>, tcpcrypt@ietf.org
References: <53576572.5030805@it.uc3m.es> <5357F05C.3060507@isi.edu> <5357F2AD.9070307@it.uc3m.es> <5357F5FD.4070103@isi.edu>
In-Reply-To: <5357F5FD.4070103@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.001
X-TM-AS-Result: No--4.036-7.0-31-1
X-imss-scan-details: No--4.036-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/MFrrmHXEvhOzuVVGXKO-YhWOnPw
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:54:02 -0000

El 23/04/14 19:18, Joe Touch escribió:
>
>
> On 4/23/2014 10:04 AM, marcelo bagnulo braun wrote:
> ...
>>> > 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.
>
> That is orthogonal as to whether the key exchange is in-band.
>
> Yes, a key exchange mechanism needs to be defined as part of the 
> system, but not necessarily inside the connection being protected.

mmm, havent considered that.
So the key exchange mechanism would be part of the work of the WG, correct?

How do you envision doing it other than inside the connection? like 
having a control connection to negotiate these things?
(something like 
https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?)

Regards, marcelo


>
> Joe
>