Re: [Tcpcrypt] New version of the charter text

marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 23 April 2014 19:00 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 DA4641A04DC for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 12:00:55 -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 K7DsvhMEyzik for <tcpcrypt@ietfa.amsl.com>; Wed, 23 Apr 2014 12:00:53 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id D7EF61A069E for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 12:00:48 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 85EE3868C43 for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 21:00:40 +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@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id A4F1E766F24 for <tcpcrypt@ietf.org>; Wed, 23 Apr 2014 21:00:36 +0200 (CEST)
Message-ID: <53580DFC.8030808@it.uc3m.es>
Date: Wed, 23 Apr 2014 21:01:16 +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> <5357F2AD.9070307@it.uc3m.es> <5357F5FD.4070103@isi.edu> <5357FE5E.3070307@it.uc3m.es> <535808A1.6020406@isi.edu>
In-Reply-To: <535808A1.6020406@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--11.915-7.0-31-1
X-imss-scan-details: No--11.915-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/BTpcILjr4lwuPkNG8JyQUtE7f_w
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 19:00:56 -0000

El 23/04/14 20:38, Joe Touch escribió:
>
>
> On 4/23/2014 10:54 AM, marcelo bagnulo braun wrote:
>> 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?
>
> Yes.
>
>> 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?)
>
> Sure- that's one possible way (i.e., that's what I meant by "in the 
> data of a previous TCP connection").
>
> I don't think we should pick in advance, though - let's see what 
> people suggest first.
>

Ok, so the WG will decide whether it is in band or else.
I will change the text in the charter to reflect this in the next version.

Regards, marcelo





> Joe
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>