Re: [Tcpcrypt] Initial questions

marcelo bagnulo braun <marcelo@it.uc3m.es> Thu, 19 June 2014 05:43 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 AFC5B1A0172 for <tcpcrypt@ietfa.amsl.com>; Wed, 18 Jun 2014 22:43:40 -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 KfxzevrsEj3B for <tcpcrypt@ietfa.amsl.com>; Wed, 18 Jun 2014 22:43:37 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CA41A0343 for <tcpcrypt@ietf.org>; Wed, 18 Jun 2014 22:43:35 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 28CC98B5DE3 for <tcpcrypt@ietf.org>; Thu, 19 Jun 2014 07:43:34 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [10.0.1.2] (37.120.220.87.dynamic.jazztel.es [87.220.120.37]) (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 042A9766F9E for <tcpcrypt@ietf.org>; Thu, 19 Jun 2014 07:43:33 +0200 (CEST)
Message-ID: <53A27886.9070402@it.uc3m.es>
Date: Thu, 19 Jun 2014 07:43:34 +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.6.0
MIME-Version: 1.0
To: tcpcrypt@ietf.org
References: <CACXcFmmQCgTu6-QLJZdH8Q+ZST97ugoTaUWCUV0S6AWsjvCGfg@mail.gmail.com> <53A2040B.7000804@isi.edu>
In-Reply-To: <53A2040B.7000804@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-20766.004
X-TM-AS-Result: No--28.840-7.0-31-1
X-imss-scan-details: No--28.840-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Iacj8yuT8PhT-ySA_n2wOGPjUTM
Subject: Re: [Tcpcrypt] Initial questions
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: Thu, 19 Jun 2014 05:43:40 -0000

Yes, exactly what Joe said.

This is the extract of one email that cuased this particular piece of 
text in the charter:

On Thu, Mar 13, 2014 at 10:21:55AM +0100, marcelo bagnulo braun wrote:

(the original charter text used to say)

> - the protocol must gracefully fall-back to TCP if the remote peer
> does not support the proposed extensions
> - the protocol must always provide forward secrecy.
> - the protocol must always provide integrity protection of the

(then someone commented)

Cool! How do you reconcile the first point with the last two? If it falls
back to normal TCP, it would also need SSL or similar to always provide
forward secrecy and integrity protection.  Or is this part of the TCPcrypt
API that the application must be careful to check?


So, we changed it to what is currently in the charter.
Hope this clarifies this particular point.
Regards, marcelo


El 18/06/14 23:26, Joe Touch escribió:
>
>
> On 6/18/2014 2:15 PM, Sandy Harris wrote:
>> This is basically a fine idea & I'm glad to see people working on it.
>>
>> Some comments in the archive had me somewhat worried, and the current
>> draft charter has the following:
>>
>> - When encryption is enabled, it must at least provide protection 
>> against
>>    passive eavesdropping by default,
>> ...
>> When encryption is enabled, then the protocol:
>> - must always provide forward secrecy.
>> - must always provide integrity protection of the payload data ...
>> - must always provide payload encryption.
>>
>> Why on Earth do these have "When encryption is enabled"? As others
>> have said quite eloquently in various posts, there is no reason at all
>> to even consider a null encryption mode; anyone who needs that can
>> just fall back to TCP.
>
> That's what "when encryption is enabled" means - i.e., there are (at 
> least) two valid modes:
>
>     use TCPCRYPT
>
>     do not use TCPCRYPT
>
> Regardless of what this WG develops, the latter will always need to be 
> an alternative. The charter is perhaps being overly pedantic in noting 
> that the gains claimed occur only when the methods indicated are in use.
>
> Joe
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>