IETF Logo Mail Archive

Re: [Tcpcrypt] v3 of the charter

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 02 May 2014 06:02 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 225041A0776 for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 23:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.505
X-Spam-Level:
X-Spam-Status: No, score=-103.505 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.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 CDO5V-PcXkR4 for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 23:01:58 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 557B61A0684 for <tcpcrypt@ietf.org>; Thu, 1 May 2014 23:01:58 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F16C6912126 for <tcpcrypt@ietf.org>; Fri, 2 May 2014 08:01:54 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [10.0.1.2] (151.116.220.87.dynamic.jazztel.es [87.220.116.151]) (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 CA9F691211A for <tcpcrypt@ietf.org>; Fri, 2 May 2014 08:01:54 +0200 (CEST)
Message-ID: <536334D7.9080706@it.uc3m.es>
Date: Fri, 02 May 2014 08:01:59 +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: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362A891.1070300@it.uc3m.es> <046601cf65bf$e95cdd90$bc1698b0$@huitema.net>
In-Reply-To: <046601cf65bf$e95cdd90$bc1698b0$@huitema.net>
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-20668.005
X-TM-AS-Result: No--17.625-7.0-31-1
X-imss-scan-details: No--17.625-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Mb8WHhnipTm5a5XT1Ngs6J1Jgdc
Subject: Re: [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: Fri, 02 May 2014 06:02:02 -0000

El 02/05/14 06:35, Christian Huitema escribió:
>> However, i am uncovinced we should link this to the API at this stage.
>> I mean, current charter text basically says avoid additional
>> fingerprinting, doesnt link this to the API, i am dubious we should do
> this.
>> For instance, i would think legacy apps that dont support the extended
>> API would also want to avoid fingerprinting.
> The TCP Crypt draft has a powerful feature: the APi can retrieve a session
> identifier, which can then be used by applications to detect a MITM attack.
> It would be a shame to preclude that in the charter.

crypto material reuse and avoiding finger printing are contradictory 
requirements, i guess.
So, i guess it is up to the initiator to decide which one should it get, no?
This should be done through the API (which i guess is what David was 
referring to and i failed to understand)

I guess the difficulty is what should be the deafult behaviour i.e. when 
the upper layer donest support the extended API, but i dont think we 
need to nail this down in the charter....


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

v2.23.0 | Report a Bug | By Email