Re: [Tcpcrypt] Draft charter text

MARCELO BAGNULO BRAUN <marcelo@it.uc3m.es> Mon, 14 April 2014 20:32 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 673FE1A06E7 for <tcpcrypt@ietfa.amsl.com>; Mon, 14 Apr 2014 13:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.473
X-Spam-Level:
X-Spam-Status: No, score=-104.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aGfrKONC-_cH for <tcpcrypt@ietfa.amsl.com>; Mon, 14 Apr 2014 13:32:07 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7323D1A021F for <tcpcrypt@ietf.org>; Mon, 14 Apr 2014 13:32:07 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38234CD73DA; Mon, 14 Apr 2014 22:32:04 +0200 (CEST)
Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 273E6CD73C0; Mon, 14 Apr 2014 22:32:04 +0200 (CEST)
Received: from bdv75-2-81-57-250-123.fbx.proxad.net (bdv75-2-81-57-250-123.fbx.proxad.net [81.57.250.123]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 14 Apr 2014 22:32:04 +0200
Message-ID: <20140414223204.aeu1xthy6qsss0ww@webcartero01.uc3m.es>
Date: Mon, 14 Apr 2014 22:32:04 +0200
From: MARCELO BAGNULO BRAUN <marcelo@it.uc3m.es>
To: Joe Touch <touch@isi.edu>
References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <CABu4T3+yYoNReA+S7S057_aWBwia-Tw_y8YX8ALdup-_soN3Tw@mail.gmail.com> <534ACC3E.1020308@isi.edu> <CAKC-DJhG4n2gD5JdKi_+ODfaV826sw7+n8a1s=zyycgFvNKjTQ@mail.gmail.com> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> <534B6CCE.1030400@isi.edu> <20140414162526.GV34745@funkthat.com> <534C106A.1010504@isi.edu> <20140414172640.GB43976@funkthat.com> <534C1BD6.1030609@isi.edu> <20140414212000.v9ghsownjoc84c0o@webcartero01.uc3m.es> <534C3A29.2020606@isi.edu> <20140414221519.vg3o2epgg00w8scs@webcartero01.uc3m.es> <534C442D.2020000@isi.edu>
In-Reply-To: <534C442D.2020000@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Mon, 14 Apr 2014 22:32:04 +0200 (CEST)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/R6VZkP20b5YLKDN0ybvcAY6bu9U
Cc: Erik Nygren <erik+ietf@nygren.org>, John-Mark Gurney <jmg@funkthat.com>, tcpcrypt@ietf.org, Andrea Bittau <bittau@cs.stanford.edu>
Subject: Re: [Tcpcrypt] Draft 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: Mon, 14 Apr 2014 20:32:12 -0000

Hi,

Joe Touch <touch@isi.edu> dijo:

>
>
> On 4/14/2014 1:15 PM, MARCELO BAGNULO BRAUN wrote:
>> Joe Touch <touch@isi.edu> dijo:
>>
>>> On 4/14/2014 12:20 PM, MARCELO BAGNULO BRAUN wrote:
>>>> So, the goal of this effort is to create a WG to work on
>>>> anonymous/oportunistic encryption for TCP streams.
>>>
>>> That's not at all clear.
>>>
>>> I thought the goal was encryption for TCP streams, which may include
>>> anonymous, zero-ID (which isn't necessarily anonymous), opportunistic,
>>> or other solutions.
>>>
>>> Why the specific focus on anonymous/opportunistic?
>>>
>>> And why list those as if they are related or synonymous?
>>
>> ok, so i think we have a terminology issue here.
>> For me, what i have in mind when writing the charter text, the goal of
>> the work would be to enable encryption without necesarily requiring
>> authentication.
>> For me, anonymous and opportunistic meant the same thing, i was using
>> anonymous in order to stay away from the discussion on oportunistic
>> encryption.
>
> There are three terms:
>
> 	anonymous - which includes proof that a connection cannot be
> 	traced back to a given source, or different connections
> 	can't be correlated to a single source
>
> 	zero-ID - I think this is what you mean, i.e., PKI-free. That
> 	was the original intent of BTNS (RFC 5387), but later came to
> 	include links to channel binding when the WG got hold of it
> 	(RFC 5386).
>
> 	opportunistic - this originated with RFC 4322, which meant
> 	using keying info found in the DNS in the (opportunistic)
> 	hope that it would be useful, rather than negotiating
> 	it with the endpoint.
>


thanks for this.
Yes, i think zero-id as per the definition above is what we want.
I was just rechecking the btns charter and they use the term 
unauthenticated encryption, which would also fit what we are trying to 
do.

more below...

>> I think many of not all of these terms are overloaded. I was hoping
>> the goal of what we want to achieve here was clearer but i guess it
>> requires more precise wording. Is there any termonilogy that is well
>> defined that we can use?
>
> SAAG is currently trying to (re)define 'opportunistic security' to 
> include the original BTNS meaning (zero-ID). I've already pointed out 
> on that this list that such redefinition isn't productive, but they 
> are doing so anyway.
>
> I would suggest here that we use an accurate, meaningful term rather 
> than redefine terms already in (relatively wide) use.
>
> I would suggest zero-ID - akin to zero-configuration or zero-touch 
> network management - if you mean "avoiding PKI".
>
> I would not assume that zero-ID necessarily included links to 
> upper-layer protocol authentication - e.g., TLS - because that 
> doesn't get rid of PKI so much as move the problem to a different 
> layer, where it still isn't solved.
>

right, my concern if we use zero-id or unathenticated, is that it 
sounds as we are rpeventing the hooks for external authentication, but 
i guess it is something we can live with, as long we properly explain 
it in the charter.

makes sense?

Regards, marcelo


> Joe
>
>
>
>
>



-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid