From nobody Wed Apr 2 09:01:13 2014 Return-Path: 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 CCBB91A032D for ; Wed, 2 Apr 2014 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.211 X-Spam-Level: X-Spam-Status: No, score=-104.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 U2o8_d-tDG3N for ; Wed, 2 Apr 2014 09:01:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id A490D1A0340 for ; Wed, 2 Apr 2014 08:59:20 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 73F991185288; Wed, 2 Apr 2014 17:59:15 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.94.92] (unknown [163.117.94.92]) (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 679239D4131; Wed, 2 Apr 2014 17:59:15 +0200 (CEST) Message-ID: <533C33D2.4060004@it.uc3m.es> Date: Wed, 02 Apr 2014 17:59:14 +0200 From: marcelo bagnulo braun 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20604.007 X-TM-AS-Result: No--15.893-7.0-31-1 X-imss-scan-details: No--15.893-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xoBwE7cNWA-Vhf8GKfLwfswdEB0 Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:01:12 -0000 Hi, It seems a good time to start talking about the charter. Please find an initial draft on a possible charter. Comments would be appreciated. TCP anonymous encryption (TAE) Anonymous encryption is an anonymous key exchange resulting in encryption without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man-in-the-middle attacks. This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring (see draft-farrell-perpass-attack). The TAE WG will define mechanisms for anonymous encryption of TCP connections. The WG will define the TCP extensions needed to provide privacy and integrity protection of TCP connections. The working group is looking to produce experimental documents specifying the required TCP extensions for anonymous encryption and any additional informational documents needed. The high-level requirements for the TCP anonymous encryption protocol are: - Deployable and usable without significant changes to existing Internet infrastructure; - Usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be changed in a backward compatible way. It also provides some protection in scenarios where people are unwilling to do any change just for the sake of security (e.g., like configure encryption in an application). - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Must gracefully fall-back to TCP if the remote peer does not support the proposed extensions - When encryption is enabled, it must always provide forward secrecy. - When encryption is enabled, it must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or not be protected) - When encryption is enabled, it must always provide payload encryption. - Should attempt to use the least amount of TCP option space. - Must not require any authentication or configuration from applications or users. However, hooks for higher-level authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance. For example, session caching should be used to avoid expensive public key operations on connection set up. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for anonimous encryption for TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with higher layer authentication mechanisms, the expected protection and residual threats. - Extensions to current TCP to support anonimous encryption. This covers all the protocol changes to support anonimous encryption. This will be a experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting higher layer authentication will be defined in this document. This will be an informational document. Regards, marcelo From dfawcus@employees.org Fri Apr 4 13:37:40 2014 Return-Path: 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 47C0F1A012D for ; Fri, 4 Apr 2014 13:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7yBzvRQtORbZ for ; Fri, 4 Apr 2014 13:37:35 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id BB23B1A002F for ; Fri, 4 Apr 2014 13:37:35 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E44C061DF for ; Fri, 4 Apr 2014 13:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=b1M4wJuRFMAMIg90Ea+LK06Anf4=; b=k5 PCYLoH5uhUrd9AfZWcYanOhI7/e69McfrcPpMMj0TTVSyZGDulvXNeE47uhSyN9v g/ZimaSYHgiEgTWuDaXJOwre9afStSNSEK2UFZnsaQmfs3QA3799pPbK9UbVG+Gt XuP+RVnXCHDSluanlkKiZ3sasGRIec3pAuxFTiMuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=ZW7/TAS7arSU/PALCixrM3cVxY6D pzKZ9qpvK6tXYxmylHN5yBkN2LX6ham8qoUZMt+TwxFTv39bUhQOwF74Ksf9V2Dv MnYLgDZsIj8IUN5lKI9UFH7Ccpjz7hmBqDitnYiNRW24sT5dSpkqjqlzXVzW8XGr cch2MPVM8f98t28= Received: by banjo.employees.org (Postfix, from userid 1736) id D1EE661D1; Fri, 4 Apr 2014 13:37:30 -0700 (PDT) Date: Fri, 4 Apr 2014 13:37:30 -0700 From: Derek Fawcus To: tcpcrypt@ietf.org Message-ID: <20140404203730.GA94387@banjo.employees.org> References: <533C33D2.4060004@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533C33D2.4060004@it.uc3m.es> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/6wEbfSl0Nty5FTUWgovmkesw5jo 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:41:49 -0000 On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote: > - When encryption is enabled, it must always provide integrity protection of the > payload data (it is open for discussion for the WG if the TCP header should or > not be protected) I'd suggest that the TCP header should also be protected; otherwise one can't easily detect the situation where a MitM spoofs FIN or RST to force a connection closed. As I recall (it's been a while since I last read it), the current tcpcrypt draft does provide such protection. So do you mean discuss wrt to if the charter should cover this, or keep charter as above and discuss within context of protocol discussions? .pdf From nobody Fri Apr 4 13:48:19 2014 Return-Path: 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 A60781A0116 for ; Fri, 4 Apr 2014 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aVE5GwTi3ac8 for ; Fri, 4 Apr 2014 13:48:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF651A010B for ; Fri, 4 Apr 2014 13:48:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 847314768E for ; Fri, 4 Apr 2014 20:48:08 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 77B9547689 for ; Fri, 4 Apr 2014 20:48:08 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 4CE18FE077 for ; Fri, 4 Apr 2014 20:48:08 +0000 (GMT) Message-ID: <533F1A86.9010701@akamai.com> Date: Fri, 04 Apr 2014 16:48:06 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <20140404203730.GA94387@banjo.employees.org> In-Reply-To: <20140404203730.GA94387@banjo.employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/u-4r2IKrNGeTNc8-qd1WmVvnD10 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:48:18 -0000 I read this to indicate discussion within the context of the protocol discussions. I think this requires some discussion and a resolution to the question shouldn't be required for approving the charter. --Brandon On 04/04/2014 04:37 PM, Derek Fawcus wrote: > On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote: >> - When encryption is enabled, it must always provide integrity protection of the >> payload data (it is open for discussion for the WG if the TCP header should or >> not be protected) > > I'd suggest that the TCP header should also be protected; > otherwise one can't easily detect the situation where a MitM spoofs > FIN or RST to force a connection closed. > > As I recall (it's been a while since I last read it), the current tcpcrypt > draft does provide such protection. > > So do you mean discuss wrt to if the charter should cover this, or keep charter > as above and discuss within context of protocol discussions? > > .pdf > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 4 23:50:09 2014 Return-Path: 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 BD5A01A0334 for ; Fri, 4 Apr 2014 23:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.211 X-Spam-Level: X-Spam-Status: No, score=-104.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7sDfGNE5lBPN for ; Fri, 4 Apr 2014 23:50:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 53B811A0331 for ; Fri, 4 Apr 2014 23:50:03 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 06DD2894346 for ; Sat, 5 Apr 2014 08:49:57 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (15.111.220.87.dynamic.jazztel.es [87.220.111.15]) (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 A27187684D4 for ; Sat, 5 Apr 2014 08:49:56 +0200 (CEST) Message-ID: <533FA793.7000908@it.uc3m.es> Date: Sat, 05 Apr 2014 08:49:55 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <20140404203730.GA94387@banjo.employees.org> <533F1A86.9010701@akamai.com> In-Reply-To: <533F1A86.9010701@akamai.com> 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-20610.005 X-TM-AS-Result: No--14.898-7.0-31-1 X-imss-scan-details: No--14.898-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aQaGmJyY-wfYo75HypHiQeXVt4Q 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 06:50:08 -0000 Yes, this is what the current text means to say. El 04/04/14 22:48, Brandon Williams escribió: > I read this to indicate discussion within the context of the protocol > discussions. I think this requires some discussion and a resolution to > the question shouldn't be required for approving the charter. > > --Brandon > > On 04/04/2014 04:37 PM, Derek Fawcus wrote: >> On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote: >>> - When encryption is enabled, it must always provide integrity >>> protection of the >>> payload data (it is open for discussion for the WG if the TCP >>> header should or >>> not be protected) >> >> I'd suggest that the TCP header should also be protected; >> otherwise one can't easily detect the situation where a MitM spoofs >> FIN or RST to force a connection closed. >> >> As I recall (it's been a while since I last read it), the current >> tcpcrypt >> draft does provide such protection. >> >> So do you mean discuss wrt to if the charter should cover this, or >> keep charter >> as above and discuss within context of protocol discussions? >> >> .pdf >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> > From nobody Tue Apr 8 14:52:15 2014 Return-Path: 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 30B791A0763 for ; Tue, 8 Apr 2014 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Dh-mi1NDUfkw for ; Tue, 8 Apr 2014 14:52:09 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 380B51A0300 for ; Tue, 8 Apr 2014 14:52:09 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s38LpQJM002999; Tue, 8 Apr 2014 14:52:06 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1k4gyq2ty1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Apr 2014 14:52:06 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 8 Apr 2014 14:52:04 -0700 From: Paul Lambert To: marcelo bagnulo braun , "tcpcrypt@ietf.org" Date: Tue, 8 Apr 2014 14:52:05 -0700 Thread-Topic: [Tcpcrypt] Draft charter text Thread-Index: Ac9TdMeGIvu4PveiTuG+7DTJKgPdPQ== Message-ID: References: <533C33D2.4060004@it.uc3m.es> In-Reply-To: <533C33D2.4060004@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-08_04:2014-04-08,2014-04-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404080216 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aCyONx0p00GmxNuk0Lf0M-3e8X4 Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:52:14 -0000 On 4/2/14, 8:59 AM, "marcelo bagnulo braun" wrote: >Hi, > >It seems a good time to start talking about the charter. >Please find an initial draft on a possible charter. >Comments would be appreciated. > >TCP anonymous encryption (TAE) > >Anonymous encryption is an anonymous key exchange resulting in encryption >without authentication. Is the key discovered used at all in a =B3sticky=B2 manner? That is, does the =B3anonymous" connection maintain the discovered key and associated state to ensure that subsequent connections to the same site use the same key? Hopefully yes =8A if not, this activity is a hazard. Paul >This is better than plain-text because it thwarts >passive eavesdropping, but is weaker than using authenticated keys, >because it >is vulnerable to man-in-the-middle attacks. This work is part of the IETF >effort to harness the Internet architecture given the latest events of >pervasive >monitoring (see draft-farrell-perpass-attack). > >The TAE WG will define mechanisms for anonymous encryption of TCP >connections. >The WG will define the TCP extensions needed to provide privacy and >integrity >protection of TCP connections. The working group is >looking to produce experimental documents specifying the required TCP >extensions >for anonymous encryption and any additional informational documents >needed. > >The high-level requirements for the TCP anonymous encryption protocol are: > >- Deployable and usable without significant changes to existing Internet > infrastructure; > >- Usable by unmodified applications. This effort is complementary to > other security protocols developed in the IETF (such as TLS) as it >protects > those applications and protocols that are difficult to change or may >even not > be changed in a backward compatible way. It also provides some >protection in > scenarios where people are unwilling to do any change just for the >sake of > security (e.g., like configure encryption in an application). > >- When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > >- Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > >- When encryption is enabled, it must always provide forward secrecy. > >- When encryption is enabled, it must always provide integrity >protection of the > payload data (it is open for discussion for the WG if the TCP header >should or > not be protected) > >- When encryption is enabled, it must always provide payload encryption. > >- Should attempt to use the least amount of TCP option space. > >- Must not require any authentication or configuration from > applications or users. However, hooks for higher-level >authentication must be > made available. The WG will not work on new authentication mechanisms. > >- The protocol must have acceptable performance. For example, session >caching > should be used to avoid expensive public key operations on connection >set up. > >Security features at the TCP-level can benefit other TCP extensions. For >example, both Multipath TCP and TCP Fast Open require proof that some >connections are >related. Session resumption and Message Authentication Codes (MACs) can >provide >this evidence. The working group should identify synergies and design the >security protocol in such a way that other TCP efforts can benefit from >it. Of >course, TCP extensions that break must be identified too, and kept to a >minimum. > >The working group will produce the following documents: > >- A framework for anonimous encryption for TCP connections. This >document will >describe basic design considerations, including the motivation and the >applicability >of the proposed mechanism, the interaction with other security >mechanisms in different >layers of the stack, the interaction with higher layer authentication >mechanisms, the >expected protection and residual threats. > >- Extensions to current TCP to support anonimous encryption. This covers >all the > protocol changes to support anonimous encryption. This will be a >experimental document. > >- An extended API describing how applications can obtain further >benefits of the >proposed extensions. In particular, the hooks for supporting higher >layer authentication >will be defined in this document. This will be an informational document. > > >Regards, marcelo > >_______________________________________________ >Tcpcrypt mailing list >Tcpcrypt@ietf.org >https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Tue Apr 8 22:09:58 2014 Return-Path: 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 2C90E1A00BC for ; Tue, 8 Apr 2014 22:09:57 -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 lhmrDI4Ivq_U for ; Tue, 8 Apr 2014 22:09:54 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id BD7131A00B0 for ; Tue, 8 Apr 2014 22:09:53 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 864A3C400FC for ; Wed, 9 Apr 2014 07:09:52 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (121.171.78.188.dynamic.jazztel.es [188.78.171.121]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 21DE5CC5EBD for ; Wed, 9 Apr 2014 07:09:52 +0200 (CEST) Message-ID: <5344D620.9070506@it.uc3m.es> Date: Wed, 09 Apr 2014 07:09:52 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20620.004 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/HMAZcuJWoxXpmWO7YG5rg1az8lk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 05:09:57 -0000 Yes, i agree, we should add this as a requirement and also to understand the security implications of that approach (i.e. once fooled, fooled for ever) I think we may want to include a directionality restriction on the re use of the keys i.e. a host can only re use the keys it obtained when establishing a tcpcrypt as a client only in connections that it is actively opening and not for the oens it is serving as a server. I think the reuse requirement shoudl be included in the charter in a mild way and leave how much it shold be limited for discussion in the WG? El 08/04/14 23:52, Paul Lambert escribió: > > On 4/2/14, 8:59 AM, "marcelo bagnulo braun" wrote: > >> Hi, >> >> It seems a good time to start talking about the charter. >> Please find an initial draft on a possible charter. >> Comments would be appreciated. >> >> TCP anonymous encryption (TAE) >> >> Anonymous encryption is an anonymous key exchange resulting in encryption >> without authentication. > Is the key discovered used at all in a ³sticky² manner? > > That is, does the ³anonymous" connection maintain the discovered key and > associated state to ensure that subsequent connections to the same site > use the same key? > > Hopefully yes Š if not, this activity is a hazard. > > > Paul > > >> This is better than plain-text because it thwarts >> passive eavesdropping, but is weaker than using authenticated keys, >> because it >> is vulnerable to man-in-the-middle attacks. This work is part of the IETF >> effort to harness the Internet architecture given the latest events of >> pervasive >> monitoring (see draft-farrell-perpass-attack). >> >> The TAE WG will define mechanisms for anonymous encryption of TCP >> connections. >> The WG will define the TCP extensions needed to provide privacy and >> integrity >> protection of TCP connections. The working group is >> looking to produce experimental documents specifying the required TCP >> extensions >> for anonymous encryption and any additional informational documents >> needed. >> >> The high-level requirements for the TCP anonymous encryption protocol are: >> >> - Deployable and usable without significant changes to existing Internet >> infrastructure; >> >> - Usable by unmodified applications. This effort is complementary to >> other security protocols developed in the IETF (such as TLS) as it >> protects >> those applications and protocols that are difficult to change or may >> even not >> be changed in a backward compatible way. It also provides some >> protection in >> scenarios where people are unwilling to do any change just for the >> sake of >> security (e.g., like configure encryption in an application). >> >> - When encryption is enabled, it must at least provide protection against >> passive eavesdropping by default, >> >> - Must gracefully fall-back to TCP if the remote peer does not support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it must always provide integrity >> protection of the >> payload data (it is open for discussion for the WG if the TCP header >> should or >> not be protected) >> >> - When encryption is enabled, it must always provide payload encryption. >> >> - Should attempt to use the least amount of TCP option space. >> >> - Must not require any authentication or configuration from >> applications or users. However, hooks for higher-level >> authentication must be >> made available. The WG will not work on new authentication mechanisms. >> >> - The protocol must have acceptable performance. For example, session >> caching >> should be used to avoid expensive public key operations on connection >> set up. >> >> Security features at the TCP-level can benefit other TCP extensions. For >> example, both Multipath TCP and TCP Fast Open require proof that some >> connections are >> related. Session resumption and Message Authentication Codes (MACs) can >> provide >> this evidence. The working group should identify synergies and design the >> security protocol in such a way that other TCP efforts can benefit from >> it. Of >> course, TCP extensions that break must be identified too, and kept to a >> minimum. >> >> The working group will produce the following documents: >> >> - A framework for anonimous encryption for TCP connections. This >> document will >> describe basic design considerations, including the motivation and the >> applicability >> of the proposed mechanism, the interaction with other security >> mechanisms in different >> layers of the stack, the interaction with higher layer authentication >> mechanisms, the >> expected protection and residual threats. >> >> - Extensions to current TCP to support anonimous encryption. This covers >> all the >> protocol changes to support anonimous encryption. This will be a >> experimental document. >> >> - An extended API describing how applications can obtain further >> benefits of the >> proposed extensions. In particular, the hooks for supporting higher >> layer authentication >> will be defined in this document. This will be an informational document. >> >> >> Regards, marcelo >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Apr 9 01:44:30 2014 Return-Path: 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 C514A1A01A5 for ; Wed, 9 Apr 2014 01:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 F9sis6qLJ0D2 for ; Wed, 9 Apr 2014 01:44:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 95F631A0160 for ; Wed, 9 Apr 2014 01:44:24 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 1443E6137 for ; Wed, 9 Apr 2014 01:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=DFdPsPMkwTLxJ3iIsITrh2g++2o=; b=fa talaWPAQJasAWsMiz01Ubz5+sBuamiJlcUkLydkEeTH+yU9JLxn1hP8A6Cg2BL3S sGcnbWRldtSl41OVZhIvWh2NzfT1Se1SF2tP9D5yaTsHL0HmaBIsXupjxLcyTHmF bP97jX2GZEKd+TYhCZKhMB49f57mihgE/VTIriLpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=T860/Tv4N8kPNmR/DDQ/o1EJ0CmF Uh0ff7LCjNvQt22QHCLAnH+Nwm5JyTwebAQtryCRNF4uSjOFOHoY3t5gH9xDGq4g nr+E4icLndlnhFQElc+qb4A9QPqXabNU3aSwciIzTRy2rzfnzLTRFNUsEZM8NfLM Ud4Xp14F0MFMHZE= Received: by banjo.employees.org (Postfix, from userid 1736) id EA77F6136; Wed, 9 Apr 2014 01:44:23 -0700 (PDT) Date: Wed, 9 Apr 2014 01:44:23 -0700 From: Derek Fawcus To: tcpcrypt@ietf.org Message-ID: <20140409084423.GA74559@banjo.employees.org> References: <533C33D2.4060004@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/GRydAU4P5oODogOhUaDbDo__fXE 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:44:28 -0000 On Tue, Apr 08, 2014 at 02:52:05PM -0700, Paul Lambert wrote: > On 4/2/14, 8:59 AM, "marcelo bagnulo braun" wrote: > >TCP anonymous encryption (TAE) > > > >Anonymous encryption is an anonymous key exchange resulting in encryption > >without authentication. > > Is the key discovered used at all in a "sticky" manner? > > That is, does the "anonymous" connection maintain the discovered key and > associated state to ensure that subsequent connections to the same site > use the same key? > > Hopefully yes - if not, this activity is a hazard. I take it in the above you're referring to the public key discovered? i.e. similar behaviour to how openssh records an public key for an unknown location in its known_hosts file, and checks for a change upon reconnect. (I initially read the above as session state caching ala SSL) .pdf From nobody Wed Apr 9 02:42:15 2014 Return-Path: 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 66FE01A01E6 for ; Wed, 9 Apr 2014 02:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no 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 scM_pEt-ozIx for ; Wed, 9 Apr 2014 02:42:08 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) by ietfa.amsl.com (Postfix) with ESMTP id 424261A01D6 for ; Wed, 9 Apr 2014 02:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1397036527; l=10067; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=QKhvGMoXFlaGIEcEovbJf5F9roQ=; b=gcskjoMetFo6s6TlPNpRkDDk666860z65gkd+QPHAc+xoxG2nq15okgXqH2VSO19ZsN t59iFSaxLLBJ9fXhpQE5vyc68z41sU/u5qZWuXoO9AnZvqtLutNWTUd64vAe/nsKy0V8G 2btsE28EuH1+mrcSGGrvoo4Nv3PgjqtW8ak= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSE4QZmxiJ X-RZG-CLASS-ID: mo00 Received: from mail-qc0-f169.google.com ([209.85.216.169]) by smtp.strato.de (RZmta 32.32 AUTH) with ESMTPSA id 501dbdq399g6E0I (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Wed, 9 Apr 2014 11:42:06 +0200 (CEST) Received: by mail-qc0-f169.google.com with SMTP id i17so2439868qcy.28 for ; Wed, 09 Apr 2014 02:42:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.82.167 with SMTP id h36mr10494129qgd.51.1397036525939; Wed, 09 Apr 2014 02:42:05 -0700 (PDT) Received: by 10.224.32.7 with HTTP; Wed, 9 Apr 2014 02:42:05 -0700 (PDT) In-Reply-To: <533C33D2.4060004@it.uc3m.es> References: <533C33D2.4060004@it.uc3m.es> Date: Wed, 9 Apr 2014 11:42:05 +0200 Message-ID: From: Sandeep Kumar To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a11c120cede2b3604f698e95a Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/y-O5S_YBBjgjSKLV9sFyPSgNNtA Cc: David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 09:42:12 -0000 --001a11c120cede2b3604f698e95a Content-Type: text/plain; charset=ISO-8859-1 Maybe off topic but will there be a similar effort for UDP? regards Sandeep On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun wrote: > Hi, > > It seems a good time to start talking about the charter. > Please find an initial draft on a possible charter. > Comments would be appreciated. > > TCP anonymous encryption (TAE) > > Anonymous encryption is an anonymous key exchange resulting in encryption > without authentication. This is better than plain-text because it thwarts > passive eavesdropping, but is weaker than using authenticated keys, > because it > is vulnerable to man-in-the-middle attacks. This work is part of the IETF > effort to harness the Internet architecture given the latest events of > pervasive > monitoring (see draft-farrell-perpass-attack). > > The TAE WG will define mechanisms for anonymous encryption of TCP > connections. > The WG will define the TCP extensions needed to provide privacy and > integrity > protection of TCP connections. The working group is > looking to produce experimental documents specifying the required TCP > extensions > for anonymous encryption and any additional informational documents needed. > > The high-level requirements for the TCP anonymous encryption protocol are: > > - Deployable and usable without significant changes to existing Internet > infrastructure; > > - Usable by unmodified applications. This effort is complementary to > other security protocols developed in the IETF (such as TLS) as it > protects > those applications and protocols that are difficult to change or may > even not > be changed in a backward compatible way. It also provides some > protection in > scenarios where people are unwilling to do any change just for the sake > of > security (e.g., like configure encryption in an application). > > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > - When encryption is enabled, it must always provide forward secrecy. > > - When encryption is enabled, it must always provide integrity protection > of the > payload data (it is open for discussion for the WG if the TCP header > should or > not be protected) > > - When encryption is enabled, it must always provide payload encryption. > > - Should attempt to use the least amount of TCP option space. > > - Must not require any authentication or configuration from > applications or users. However, hooks for higher-level authentication > must be > made available. The WG will not work on new authentication mechanisms. > > - The protocol must have acceptable performance. For example, session > caching > should be used to avoid expensive public key operations on connection > set up. > > Security features at the TCP-level can benefit other TCP extensions. For > example, both Multipath TCP and TCP Fast Open require proof that some > connections are > related. Session resumption and Message Authentication Codes (MACs) can > provide > this evidence. The working group should identify synergies and design the > security protocol in such a way that other TCP efforts can benefit from > it. Of > course, TCP extensions that break must be identified too, and kept to a > minimum. > > The working group will produce the following documents: > > - A framework for anonimous encryption for TCP connections. This document > will > describe basic design considerations, including the motivation and the > applicability > of the proposed mechanism, the interaction with other security mechanisms > in different > layers of the stack, the interaction with higher layer authentication > mechanisms, the > expected protection and residual threats. > > - Extensions to current TCP to support anonimous encryption. This covers > all the > protocol changes to support anonimous encryption. This will be a > experimental document. > > - An extended API describing how applications can obtain further benefits > of the > proposed extensions. In particular, the hooks for supporting higher layer > authentication > will be defined in this document. This will be an informational document. > > > Regards, marcelo > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > --001a11c120cede2b3604f698e95a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe off topic but will there be a similar effort fo= r UDP?

regards
Sandeep


On Wed, Apr 2, 2014 at 5:59 PM, marcelo= bagnulo braun <marcelo@it.uc3m.es> wrote:
Hi,

It seems a good time to start talking about the charter.
Please find an initial draft on a possible charter.
Comments would be appreciated.

TCP anonymous encryption (TAE)

Anonymous encryption is an anonymous key exchange resulting in encryption without authentication. =A0This is better than plain-text because it thwart= s
passive eavesdropping, but is weaker than using authenticated keys, because= it
is vulnerable to man-in-the-middle attacks. =A0This work is part of the IET= F
effort to harness the Internet architecture given the latest events of perv= asive
monitoring (see draft-farrell-perpass-attack).

The TAE WG will define mechanisms for anonymous encryption of TCP connectio= ns.
The WG will define the TCP extensions needed to provide privacy and integri= ty
protection of TCP connections. The working group is
looking to produce experimental documents specifying the required TCP exten= sions
for anonymous encryption and any additional informational documents needed.=

The high-level requirements for the TCP anonymous encryption protocol are:<= br>
- Deployable and usable without significant changes to existing Internet =A0 infrastructure;

- Usable by unmodified applications. =A0This effort is complementary to
=A0 other security protocols developed in the IETF (such as TLS) as it prot= ects
=A0 those applications and protocols that are difficult to change or may ev= en not
=A0 be changed in a backward compatible way. =A0It also provides some prote= ction in
=A0 scenarios where people are unwilling to do any change just for the sake= of
=A0 security (e.g., like configure encryption in an application).

- When encryption is enabled, it must at least provide protection against =A0 passive eavesdropping by default,

- Must gracefully fall-back to TCP if the remote peer does not support the<= br> =A0 proposed extensions

- When encryption is enabled, it must always provide forward secrecy.

- When encryption is enabled, it must always provide integrity protection o= f the
=A0 payload data (it is open for discussion for the WG if the TCP header sh= ould or
=A0 not be protected)

- When encryption is enabled, it must always provide payload encryption.
- Should attempt to use the least amount of TCP option space.

- Must not require any authentication or configuration from
=A0 applications or users. =A0However, hooks for higher-level authenticatio= n must be
=A0 made available. =A0The WG will not work on new authentication mechanism= s.

- The protocol must have acceptable performance. =A0For example, session ca= ching
=A0 should be used to avoid expensive public key operations on connection s= et up.

Security features at the TCP-level can benefit other TCP extensions. =A0For=
example, both Multipath TCP and TCP Fast Open require proof that some conne= ctions are
related. =A0Session resumption and Message Authentication Codes (MACs) can = provide
this evidence. =A0The working group should identify synergies and design th= e
security protocol in such a way that other TCP efforts can benefit from it.= =A0Of
course, TCP extensions that break must be identified too, and kept to a min= imum.

The working group will produce the following documents:

- A framework for anonimous encryption for TCP connections. This document w= ill
describe basic design considerations, including the motivation and the appl= icability
of the proposed mechanism, the interaction with other security mechanisms i= n different
layers of the stack, the interaction with higher layer authentication mecha= nisms, the
expected protection and residual threats.

- Extensions to current TCP to support anonimous encryption. This covers al= l the
=A0 protocol changes to support anonimous encryption. This will be a experi= mental document.

- An extended API describing how applications can obtain further benefits o= f the
proposed extensions. In particular, the hooks for supporting higher layer a= uthentication
will be defined in this document. This will be an informational document.

Regards, marcelo

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

--001a11c120cede2b3604f698e95a-- From nobody Wed Apr 9 05:44:48 2014 Return-Path: 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 528451A0136 for ; Wed, 9 Apr 2014 05:44:45 -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 ba_mIgit1rGk for ; Wed, 9 Apr 2014 05:44:41 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id CD2081A016D for ; Wed, 9 Apr 2014 05:44:40 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 36D358B6F56 for ; Wed, 9 Apr 2014 14:44:39 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (121.171.78.188.dynamic.jazztel.es [188.78.171.121]) (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 7F7CD860A87 for ; Wed, 9 Apr 2014 14:44:36 +0200 (CEST) Message-ID: <534540AC.3040601@it.uc3m.es> Date: Wed, 09 Apr 2014 14:44:28 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <20140409084423.GA74559@banjo.employees.org> In-Reply-To: <20140409084423.GA74559@banjo.employees.org> 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-20620.007 X-TM-AS-Result: No--13.972-7.0-31-1 X-imss-scan-details: No--13.972-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/lZTBzJ-qBV7ypvZqJF6J7yI7xig 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:44:45 -0000 El 09/04/14 10:44, Derek Fawcus escribió: > On Tue, Apr 08, 2014 at 02:52:05PM -0700, Paul Lambert wrote: >> On 4/2/14, 8:59 AM, "marcelo bagnulo braun" wrote: >>> TCP anonymous encryption (TAE) >>> >>> Anonymous encryption is an anonymous key exchange resulting in encryption >>> without authentication. >> Is the key discovered used at all in a "sticky" manner? >> >> That is, does the "anonymous" connection maintain the discovered key and >> associated state to ensure that subsequent connections to the same site >> use the same key? >> >> Hopefully yes - if not, this activity is a hazard. > I take it in the above you're referring to the public key discovered? > > i.e. similar behaviour to how openssh records an public key for an > unknown location in its known_hosts file, and checks for a change > upon reconnect. > > (I initially read the above as session state caching ala SSL) well, yes, you could even record more crypto material, so you can automatically generate a new session key for new connections. again, i guess this is to be discussed while working out the actual protocol regards, marcelo > .pdf > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Apr 9 05:45:54 2014 Return-Path: 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 8CE521A0136 for ; Wed, 9 Apr 2014 05:45:50 -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 dfWJX-qqKX8d for ; Wed, 9 Apr 2014 05:45:46 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id C76991A0285 for ; Wed, 9 Apr 2014 05:45:41 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0AFBD825FC0 for ; Wed, 9 Apr 2014 14:45:41 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (121.171.78.188.dynamic.jazztel.es [188.78.171.121]) (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 3A5C28B6F37 for ; Wed, 9 Apr 2014 14:45:37 +0200 (CEST) Message-ID: <534540E8.1060007@it.uc3m.es> Date: Wed, 09 Apr 2014 14:45:28 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> In-Reply-To: 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-20620.007 X-TM-AS-Result: No--23.311-7.0-31-1 X-imss-scan-details: No--23.311-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/r6DqZxK7Blk0VpNBBNf293vJvhs 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:45:50 -0000 mmm, it was not envisioned to include this in this effort. El 09/04/14 11:42, Sandeep Kumar escribió: > Maybe off topic but will there be a similar effort for UDP? > > regards > Sandeep > > > On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun > > wrote: > > Hi, > > It seems a good time to start talking about the charter. > Please find an initial draft on a possible charter. > Comments would be appreciated. > > TCP anonymous encryption (TAE) > > Anonymous encryption is an anonymous key exchange resulting in > encryption > without authentication. This is better than plain-text because it > thwarts > passive eavesdropping, but is weaker than using authenticated > keys, because it > is vulnerable to man-in-the-middle attacks. This work is part of > the IETF > effort to harness the Internet architecture given the latest > events of pervasive > monitoring (see draft-farrell-perpass-attack). > > The TAE WG will define mechanisms for anonymous encryption of TCP > connections. > The WG will define the TCP extensions needed to provide privacy > and integrity > protection of TCP connections. The working group is > looking to produce experimental documents specifying the required > TCP extensions > for anonymous encryption and any additional informational > documents needed. > > The high-level requirements for the TCP anonymous encryption > protocol are: > > - Deployable and usable without significant changes to existing > Internet > infrastructure; > > - Usable by unmodified applications. This effort is complementary to > other security protocols developed in the IETF (such as TLS) as > it protects > those applications and protocols that are difficult to change or > may even not > be changed in a backward compatible way. It also provides some > protection in > scenarios where people are unwilling to do any change just for > the sake of > security (e.g., like configure encryption in an application). > > - When encryption is enabled, it must at least provide protection > against > passive eavesdropping by default, > > - Must gracefully fall-back to TCP if the remote peer does not > support the > proposed extensions > > - When encryption is enabled, it must always provide forward secrecy. > > - When encryption is enabled, it must always provide integrity > protection of the > payload data (it is open for discussion for the WG if the TCP > header should or > not be protected) > > - When encryption is enabled, it must always provide payload > encryption. > > - Should attempt to use the least amount of TCP option space. > > - Must not require any authentication or configuration from > applications or users. However, hooks for higher-level > authentication must be > made available. The WG will not work on new authentication > mechanisms. > > - The protocol must have acceptable performance. For example, > session caching > should be used to avoid expensive public key operations on > connection set up. > > Security features at the TCP-level can benefit other TCP > extensions. For > example, both Multipath TCP and TCP Fast Open require proof that > some connections are > related. Session resumption and Message Authentication Codes > (MACs) can provide > this evidence. The working group should identify synergies and > design the > security protocol in such a way that other TCP efforts can benefit > from it. Of > course, TCP extensions that break must be identified too, and kept > to a minimum. > > The working group will produce the following documents: > > - A framework for anonimous encryption for TCP connections. This > document will > describe basic design considerations, including the motivation and > the applicability > of the proposed mechanism, the interaction with other security > mechanisms in different > layers of the stack, the interaction with higher layer > authentication mechanisms, the > expected protection and residual threats. > > - Extensions to current TCP to support anonimous encryption. This > covers all the > protocol changes to support anonimous encryption. This will be a > experimental document. > > - An extended API describing how applications can obtain further > benefits of the > proposed extensions. In particular, the hooks for supporting > higher layer authentication > will be defined in this document. This will be an informational > document. > > > Regards, marcelo > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Wed Apr 9 06:24:12 2014 Return-Path: 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 0DE111A02D6 for ; Wed, 9 Apr 2014 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_44=0.6] autolearn=no 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 bMR1hQ3J-e8n for ; Wed, 9 Apr 2014 06:24:11 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 183A21A02DA for ; Wed, 9 Apr 2014 06:24:07 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2AC61F986; Wed, 9 Apr 2014 09:24:04 -0400 (EDT) Message-ID: <534549E6.8050109@fifthhorseman.net> Date: Wed, 09 Apr 2014 09:23:50 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Paul Lambert , marcelo bagnulo braun , "tcpcrypt@ietf.org" References: <533C33D2.4060004@it.uc3m.es> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wS3M0gorrgnOQweLDbikeF8TuamkIGjhe" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/pEbFCydY4segEV4orpGjwXa0RTM Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:24:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wS3M0gorrgnOQweLDbikeF8TuamkIGjhe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/08/2014 05:52 PM, Paul Lambert wrote: > Is the key discovered used at all in a =C2=B3sticky=C2=B2 manner? afaict, the proposed charter doesn't mention any sort of persistent keying at all, and its scope could be met by an entirely ephemeral approach. The "hooks for higher-level authentication" can be met by exporting a derived value that would be a shared secret both parties to the transaction should know. That said, i can imagine some schemes that use persistent keys as well, and the charter doesn't seem to rule out one scheme or the other. > That is, does the =C2=B3anonymous" connection maintain the discovered k= ey and > associated state to ensure that subsequent connections to the same site= > use the same key? by "site" i think you mean host+port. is that correct? What are you proposing the TCP stack should do if it sees that the discovered key for the peer's host+port has changed? Should it refuse to complete the connection? should it fallback to plain (cleartext) TCP? Should it send an alert to somewhere higher in the stack and allow the connection to proceed otherwise? Should it have the same behaviors when acting as both client (connect()) and server (accept())? So, assuming the proposed scheme will offer persistent keying, and if you're advocating connection refusal, then you need to provide a plausible story about what to do in the event of legitimate re-keying for any long-term key material. The recent fun and games with heartbleed make it clear that there are legitimate scenarios for the rotation of persistent keys. Any scheme that would cause connection failures in the face of such a legitimate key rotation smells dangerous to me, and it seems likely that naturally conservative system administrators would not want to deploy such a scheme for fear of locking out their users when they do ultimately need to rotate keys. > Hopefully yes =C5=A0 if not, this activity is a hazard. Do you still consider this a hazard if the architecture we end up at does not require any persistent keying at all? Regards, --dkg --wS3M0gorrgnOQweLDbikeF8TuamkIGjhe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTRUnmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+VAQANjPj46mgrU5yRiW1IQASHGr B6F8RJp+JQCexBKnI6BHexD2dDhV8a+vtIIWHHew53g52V8gs9YkiPNfvO6bsh1O MzN1k9bl4DsDBsby2ONcYM/1ONRASw3LRX7/ADIAHyc1nIP+0G7pnsJXQpG9VUFH W6flYRgQEoJOku1g5esCmInSvWH/gIYFrCNXp7BuKjZ8sQNcw2TnzX6oUd1CoIdJ xl7ISyN9F/ekLydB86KY8fl2Gd8bu6YOw79AK4kmgvSvfPwi79pWdMFsLPOh9vGd fxZqf4IRqTgq8tT+n6oBmOMkoixuQsiqL7zJ8eNxxRCIlMGaliiM7DuZ+y2A/WOD sT5LcwOgo6KC2tlJS/Muu3bPgfCXv17MIPtDB075iPGAjg/RIhJ+vC+MOQOGSzEe FjDEMfMODjhzMLOmj4oPhkwYw5Sp7QwhwU6czbaR/YEGbtpQfHczOOGDKgD9gH16 6nX5O/SOR9SiLQ8ipYFtlZCNXockYxSauI6s0l3+0Ygqw8n0T5gH/rYcvLlpAzWl kwTw4Ubc4znhLjvIPLC4kA+fHBLRTEm7oxm9rBpcrpsm6B87sqD/nsObOjOKxrq3 /ldHE4ZlZe26PwHPZYrCCGSlSiOQRMd8Jpa6/ojLcr4p4jsUqHalje7NKTSicMwY Z9VeC0exnfBGeN5ax77D =3EWi -----END PGP SIGNATURE----- --wS3M0gorrgnOQweLDbikeF8TuamkIGjhe-- From nobody Wed Apr 9 06:31:46 2014 Return-Path: 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 A8BBA1A02FB for ; Wed, 9 Apr 2014 06:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 fkAwkji0tF9D for ; Wed, 9 Apr 2014 06:31:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 770E91A02E3 for ; Wed, 9 Apr 2014 06:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C4FEBE9F; Wed, 9 Apr 2014 14:31:33 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TcH6xsxY9Jw; Wed, 9 Apr 2014 14:31:33 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15DB1BEA1; Wed, 9 Apr 2014 14:31:33 +0100 (IST) Message-ID: <53454BB4.7030209@cs.tcd.ie> Date: Wed, 09 Apr 2014 14:31:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534540E8.1060007@it.uc3m.es> In-Reply-To: <534540E8.1060007@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/V1FrTpyC524bXZ0vEcB8FPluA18 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:31:45 -0000 On 04/09/2014 01:45 PM, marcelo bagnulo braun wrote: > mmm, it was not envisioned to include this in this effort. > > > El 09/04/14 11:42, Sandeep Kumar escribió: >> Maybe off topic but will there be a similar effort for UDP? The only worked-out thing I've see was QUIC which was presented at IETF-88 [1] but which is just a company internal thing as far as I know. There are probably other similar proposals about as well of course. I guess one could argue that a lot of the same issues might arise for potential solutions over TCP and UDP but I'm not sure if it'd be wise to extend the scope so much, at least at the start. OTOH, now is I guess the right time for considering that kind of thing, so good question! S. [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >> >> regards >> Sandeep >> >> >> On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun >> > wrote: >> >> Hi, >> >> It seems a good time to start talking about the charter. >> Please find an initial draft on a possible charter. >> Comments would be appreciated. >> >> TCP anonymous encryption (TAE) >> >> Anonymous encryption is an anonymous key exchange resulting in >> encryption >> without authentication. This is better than plain-text because it >> thwarts >> passive eavesdropping, but is weaker than using authenticated >> keys, because it >> is vulnerable to man-in-the-middle attacks. This work is part of >> the IETF >> effort to harness the Internet architecture given the latest >> events of pervasive >> monitoring (see draft-farrell-perpass-attack). >> >> The TAE WG will define mechanisms for anonymous encryption of TCP >> connections. >> The WG will define the TCP extensions needed to provide privacy >> and integrity >> protection of TCP connections. The working group is >> looking to produce experimental documents specifying the required >> TCP extensions >> for anonymous encryption and any additional informational >> documents needed. >> >> The high-level requirements for the TCP anonymous encryption >> protocol are: >> >> - Deployable and usable without significant changes to existing >> Internet >> infrastructure; >> >> - Usable by unmodified applications. This effort is complementary to >> other security protocols developed in the IETF (such as TLS) as >> it protects >> those applications and protocols that are difficult to change or >> may even not >> be changed in a backward compatible way. It also provides some >> protection in >> scenarios where people are unwilling to do any change just for >> the sake of >> security (e.g., like configure encryption in an application). >> >> - When encryption is enabled, it must at least provide protection >> against >> passive eavesdropping by default, >> >> - Must gracefully fall-back to TCP if the remote peer does not >> support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it must always provide integrity >> protection of the >> payload data (it is open for discussion for the WG if the TCP >> header should or >> not be protected) >> >> - When encryption is enabled, it must always provide payload >> encryption. >> >> - Should attempt to use the least amount of TCP option space. >> >> - Must not require any authentication or configuration from >> applications or users. However, hooks for higher-level >> authentication must be >> made available. The WG will not work on new authentication >> mechanisms. >> >> - The protocol must have acceptable performance. For example, >> session caching >> should be used to avoid expensive public key operations on >> connection set up. >> >> Security features at the TCP-level can benefit other TCP >> extensions. For >> example, both Multipath TCP and TCP Fast Open require proof that >> some connections are >> related. Session resumption and Message Authentication Codes >> (MACs) can provide >> this evidence. The working group should identify synergies and >> design the >> security protocol in such a way that other TCP efforts can benefit >> from it. Of >> course, TCP extensions that break must be identified too, and kept >> to a minimum. >> >> The working group will produce the following documents: >> >> - A framework for anonimous encryption for TCP connections. This >> document will >> describe basic design considerations, including the motivation and >> the applicability >> of the proposed mechanism, the interaction with other security >> mechanisms in different >> layers of the stack, the interaction with higher layer >> authentication mechanisms, the >> expected protection and residual threats. >> >> - Extensions to current TCP to support anonimous encryption. This >> covers all the >> protocol changes to support anonimous encryption. This will be a >> experimental document. >> >> - An extended API describing how applications can obtain further >> benefits of the >> proposed extensions. In particular, the hooks for supporting >> higher layer authentication >> will be defined in this document. This will be an informational >> document. >> >> >> Regards, marcelo >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> >> >> >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > From nobody Wed Apr 9 06:57:44 2014 Return-Path: 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 186AD1A0312 for ; Wed, 9 Apr 2014 06:57:23 -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 bGKdJLB8SUmT for ; Wed, 9 Apr 2014 06:57:16 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B1EC21A027E for ; Wed, 9 Apr 2014 06:57:15 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5D20FCD6068 for ; Wed, 9 Apr 2014 15:57:14 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (121.171.78.188.dynamic.jazztel.es [188.78.171.121]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 48037CD6026 for ; Wed, 9 Apr 2014 15:57:12 +0200 (CEST) Message-ID: <534551B7.3030005@it.uc3m.es> Date: Wed, 09 Apr 2014 15:57:11 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534540E8.1060007@it.uc3m.es> <53454BB4.7030209@cs.tcd.ie> In-Reply-To: <53454BB4.7030209@cs.tcd.ie> 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-20620.007 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/PMxFEd2BkEkOQtfJYZCty-lObDU 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:57:23 -0000 El 09/04/14 15:31, Stephen Farrell escribió: > > On 04/09/2014 01:45 PM, marcelo bagnulo braun wrote: >> mmm, it was not envisioned to include this in this effort. >> >> >> El 09/04/14 11:42, Sandeep Kumar escribió: >>> Maybe off topic but will there be a similar effort for UDP? > The only worked-out thing I've see was QUIC which was > presented at IETF-88 [1] but which is just a company > internal thing as far as I know. There are probably > other similar proposals about as well of course. > > I guess one could argue that a lot of the same issues > might arise for potential solutions over TCP and UDP > but I'm not sure if it'd be wise to extend the scope > so much, at least at the start. I agree > OTOH, now is I guess > the right time for considering that kind of thing, > so good question! > > S. > > [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf > >>> regards >>> Sandeep >>> >>> >>> On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun >>> > wrote: >>> >>> Hi, >>> >>> It seems a good time to start talking about the charter. >>> Please find an initial draft on a possible charter. >>> Comments would be appreciated. >>> >>> TCP anonymous encryption (TAE) >>> >>> Anonymous encryption is an anonymous key exchange resulting in >>> encryption >>> without authentication. This is better than plain-text because it >>> thwarts >>> passive eavesdropping, but is weaker than using authenticated >>> keys, because it >>> is vulnerable to man-in-the-middle attacks. This work is part of >>> the IETF >>> effort to harness the Internet architecture given the latest >>> events of pervasive >>> monitoring (see draft-farrell-perpass-attack). >>> >>> The TAE WG will define mechanisms for anonymous encryption of TCP >>> connections. >>> The WG will define the TCP extensions needed to provide privacy >>> and integrity >>> protection of TCP connections. The working group is >>> looking to produce experimental documents specifying the required >>> TCP extensions >>> for anonymous encryption and any additional informational >>> documents needed. >>> >>> The high-level requirements for the TCP anonymous encryption >>> protocol are: >>> >>> - Deployable and usable without significant changes to existing >>> Internet >>> infrastructure; >>> >>> - Usable by unmodified applications. This effort is complementary to >>> other security protocols developed in the IETF (such as TLS) as >>> it protects >>> those applications and protocols that are difficult to change or >>> may even not >>> be changed in a backward compatible way. It also provides some >>> protection in >>> scenarios where people are unwilling to do any change just for >>> the sake of >>> security (e.g., like configure encryption in an application). >>> >>> - When encryption is enabled, it must at least provide protection >>> against >>> passive eavesdropping by default, >>> >>> - Must gracefully fall-back to TCP if the remote peer does not >>> support the >>> proposed extensions >>> >>> - When encryption is enabled, it must always provide forward secrecy. >>> >>> - When encryption is enabled, it must always provide integrity >>> protection of the >>> payload data (it is open for discussion for the WG if the TCP >>> header should or >>> not be protected) >>> >>> - When encryption is enabled, it must always provide payload >>> encryption. >>> >>> - Should attempt to use the least amount of TCP option space. >>> >>> - Must not require any authentication or configuration from >>> applications or users. However, hooks for higher-level >>> authentication must be >>> made available. The WG will not work on new authentication >>> mechanisms. >>> >>> - The protocol must have acceptable performance. For example, >>> session caching >>> should be used to avoid expensive public key operations on >>> connection set up. >>> >>> Security features at the TCP-level can benefit other TCP >>> extensions. For >>> example, both Multipath TCP and TCP Fast Open require proof that >>> some connections are >>> related. Session resumption and Message Authentication Codes >>> (MACs) can provide >>> this evidence. The working group should identify synergies and >>> design the >>> security protocol in such a way that other TCP efforts can benefit >>> from it. Of >>> course, TCP extensions that break must be identified too, and kept >>> to a minimum. >>> >>> The working group will produce the following documents: >>> >>> - A framework for anonimous encryption for TCP connections. This >>> document will >>> describe basic design considerations, including the motivation and >>> the applicability >>> of the proposed mechanism, the interaction with other security >>> mechanisms in different >>> layers of the stack, the interaction with higher layer >>> authentication mechanisms, the >>> expected protection and residual threats. >>> >>> - Extensions to current TCP to support anonimous encryption. This >>> covers all the >>> protocol changes to support anonimous encryption. This will be a >>> experimental document. >>> >>> - An extended API describing how applications can obtain further >>> benefits of the >>> proposed extensions. In particular, the hooks for supporting >>> higher layer authentication >>> will be defined in this document. This will be an informational >>> document. >>> >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> Tcpcrypt mailing list >>> Tcpcrypt@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpcrypt >>> >>> >>> >>> >>> _______________________________________________ >>> Tcpcrypt mailing list >>> Tcpcrypt@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpcrypt >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> >> > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Apr 9 07:47:52 2014 Return-Path: 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 647041A0297 for ; Wed, 9 Apr 2014 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 WEbU5nqjOAKD for ; Wed, 9 Apr 2014 07:47:40 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BA1A005A for ; Wed, 9 Apr 2014 07:47:40 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ib6so2119239vcb.41 for ; Wed, 09 Apr 2014 07:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6oyOptXTZz2m6P3KX40eOydXNsRMkTiS2tg9xcY6VPY=; b=DEPLVXS8sHqn+n0OwrMr/8ain6GNM//O4WVJC7dNp3XPuVpFKZnA42kksZrbbrcS0c wjSiYI7Re+t42ZToBfJ27Lf4nvTDm/z2oipl7vZr8baqLaq57d2qa39NB4793tLJpiwO epGXbY0hfKFocCDk94ywzs0RkywCy25mVn1SINaV1/LXwrl7llq9kJLHJnSWUATPFEO0 G3hWxXy13mNgG9KWB8UWKR+TuAla6KDZai4b+yaJOrQLXsXEyj523mUIrlQbGVj+VGX+ hbbwEsKz0VbgoqZFwbKVgcul6SE+XqKf+ijLW5gDC/Ca0qTkyFtuc+FMvfkFsIAXAfU4 u9Ow== MIME-Version: 1.0 X-Received: by 10.220.163.3 with SMTP id y3mr9264041vcx.7.1397054859722; Wed, 09 Apr 2014 07:47:39 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Wed, 9 Apr 2014 07:47:39 -0700 (PDT) In-Reply-To: <20140404203730.GA94387@banjo.employees.org> References: <533C33D2.4060004@it.uc3m.es> <20140404203730.GA94387@banjo.employees.org> Date: Wed, 9 Apr 2014 10:47:39 -0400 X-Google-Sender-Auth: Gzw1PylSC15DcJjxgbXO4vLcOYo Message-ID: From: Erik Nygren To: Derek Fawcus Content-Type: multipart/alternative; boundary=001a1133da66a56dbd04f69d2edf Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/sOQLoyhgi-Sdu4PYKFZeSxShMkY Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:47:44 -0000 --001a1133da66a56dbd04f69d2edf Content-Type: text/plain; charset=ISO-8859-1 Do we explicitly need to call out that the solution should work across NAT, or is that covered by "Deployable and usable without significant changes to existing Internet infrastructure"? It seems likely that this (and other similar use-cases) will come into conflict with header protections. Erik On Fri, Apr 4, 2014 at 4:37 PM, Derek Fawcus < dfawcus+lists-tcpcrypt@employees.org> wrote: > On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote: > > - When encryption is enabled, it must always provide integrity > protection of the > > payload data (it is open for discussion for the WG if the TCP header > should or > > not be protected) > > I'd suggest that the TCP header should also be protected; > otherwise one can't easily detect the situation where a MitM spoofs > FIN or RST to force a connection closed. > > As I recall (it's been a while since I last read it), the current tcpcrypt > draft does provide such protection. > > So do you mean discuss wrt to if the charter should cover this, or keep > charter > as above and discuss within context of protocol discussions? > > .pdf > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > --001a1133da66a56dbd04f69d2edf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do we explicitly need to call out that the solution s= hould work across NAT, or is that covered by "Deployable and usable wi= thout significant changes to existing Internet infrastructure"?=A0 It = seems likely that this (and other similar use-cases) will come into conflic= t with header protections.

=A0= =A0=A0=A0=A0 Erik


On Fri, Apr 4, 2014 at 4:37 PM, Derek Fawcus <dfawcus+lists-tcpcrypt@employees.org> wrote:
On Wed, Apr 02, 2014 at 05:5= 9:14PM +0200, marcelo bagnulo braun wrote:
> - When encryption is enabled, it must always provide integrity protect= ion of the
> =A0 payload data (it is open for discussion for the WG if the TCP head= er should or
> =A0 not be protected)

I'd suggest that the TCP header should also be protected;
otherwise one can't easily detect the situation where a MitM spoofs
FIN or RST to force a connection closed.

As I recall (it's been a while since I last read it), =A0the current tc= pcrypt
draft does provide such protection.

So do you mean discuss wrt to if the charter should cover this, =A0or keep = charter
as above and discuss within context of protocol discussions?

.pdf

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

--001a1133da66a56dbd04f69d2edf-- From nobody Wed Apr 9 07:55:12 2014 Return-Path: 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 CA41B1A030F for ; Wed, 9 Apr 2014 07:55:09 -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 c1aLSPpJg0GC for ; Wed, 9 Apr 2014 07:55:05 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 37B1D1A0260 for ; Wed, 9 Apr 2014 07:55:04 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 241FD11BE9A1 for ; Wed, 9 Apr 2014 16:55:04 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (121.171.78.188.dynamic.jazztel.es [188.78.171.121]) (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 5C0B7FA95D3 for ; Wed, 9 Apr 2014 16:55:02 +0200 (CEST) Message-ID: <53455F43.1030408@it.uc3m.es> Date: Wed, 09 Apr 2014 16:54:59 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <20140404203730.GA94387@banjo.employees.org> In-Reply-To: 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-20620.007 X-TM-AS-Result: No--18.622-7.0-31-1 X-imss-scan-details: No--18.622-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/kYwh_1lix-PCSYeSZ6prE-30nnE 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:55:10 -0000 I am not sure i understand your point: do you disagree with the requirement that the solution should work across nats or you just think it is redundant with the deployability requirement? El 09/04/14 16:47, Erik Nygren escribió: > Do we explicitly need to call out that the solution should work across > NAT, or is that covered by "Deployable and usable without significant > changes to existing Internet infrastructure"? It seems likely that > this (and other similar use-cases) will come into conflict with header > protections. > > Erik > > > On Fri, Apr 4, 2014 at 4:37 PM, Derek Fawcus > > wrote: > > On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote: > > - When encryption is enabled, it must always provide integrity > protection of the > > payload data (it is open for discussion for the WG if the TCP > header should or > > not be protected) > > I'd suggest that the TCP header should also be protected; > otherwise one can't easily detect the situation where a MitM spoofs > FIN or RST to force a connection closed. > > As I recall (it's been a while since I last read it), the current > tcpcrypt > draft does provide such protection. > > So do you mean discuss wrt to if the charter should cover this, > or keep charter > as above and discuss within context of protocol discussions? > > .pdf > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Wed Apr 9 08:39:36 2014 Return-Path: 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 1EF6D1A03A4 for ; Wed, 9 Apr 2014 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 97uHgM4EWYUn for ; Wed, 9 Apr 2014 08:39:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81F1A0293 for ; Wed, 9 Apr 2014 08:39:24 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0A548F986; Wed, 9 Apr 2014 11:39:21 -0400 (EDT) Message-ID: <534569A0.9020505@fifthhorseman.net> Date: Wed, 09 Apr 2014 11:39:12 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> In-Reply-To: <533C33D2.4060004@it.uc3m.es> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b2cJhut8l3AkQ2V77OSCQXufO05aK5EA6" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/CAz7-KbebvPvZJdhXoiRofRxTN8 Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:39:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b2cJhut8l3AkQ2V77OSCQXufO05aK5EA6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: > TCP anonymous encryption (TAE) While the proposed outline does start as anonymous encryption, the requirement for hooks for higher-level authentication doesn't feel like anonymous encryption to me. I wonder if this choice of name will cause people to think that authentication is supposed to be impossible with this scheme, rather than supported-but-not-baked-in. > - The protocol must have acceptable performance. For example, session > caching should be used to avoid expensive public key operations on > connection set up. I'm not sure that we want the term "session caching" in the charter, mainly because: a) it's not clear what a "session" is without a clearer specification of the protocol, and b) it seems to rule out any architecture that doesn't permit something that could be called "session caching", even if we come up with an session-less architecture that is more performant. > - A framework for anonimous encryption for TCP connections.=20 spelling nitpick: i think you mean "anonymous" here (and three other places in the text) > (it is open for discussion for the WG if the TCP header should or > not be protected)=20 If the TCP header is protected, how will this interoperate with widespread packet-mangling mechanisms like NAT? I would love to see NAT die a quiet death, but it doesn't seem likely to happen any time soon. if we design a spec that breaks when used across NAT, i doubt it will see much useful deployment :( Privacy Considerations ---------------------- This charter makes no mention of any privacy considerations as first-order concerns. Two immediate considerations spring to mind: 0) can a passive eavesdropper link two distinct sessions with each other using whatever extension information is present in the packets? Consider Alice checking her e-mail from a laptop. If the exposed data are not unlinkable, a network observer who watches traffic at the mailserver can tell which network locations Alice connects from, at what times. 1) can the server link two subsequent connections from a given client? in some cases, a client will want to provide some proof of continuity to a server (e.g. maintaining an authenticated session across a series of TCP connections). In other cases, the client will want to be able to mask the fact that it is the same client to the server (e.g. when connecting to widely-used advertising servers, analytics sites, or CDNs, clients that want to avoid leaking their browsing history to the backend might prefer to keep these connections unlinkable). What mechanisms would such a spec provide to be able to accomodate both cases? Do we want the group to consider these privacy considerations (i do)? if so, should they be included in the charter? Regards, --dkg --b2cJhut8l3AkQ2V77OSCQXufO05aK5EA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTRWmgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcQfEP/i/85kQPlO7Ei6xd5lvKeFxV e6scXgni2lpWeTj98TSm3Io7CueEwzjV2vvwmDfZBsP7SB+Wnzv60tVA3xppxQqz TXxbWa8rl5DG6f8XUhRVD0r6s8Pdn+J76rf9CayRugcuEay6wx/qELMfcBIp2jpr EGTSg+rdNoqs9EeGx5xNY4bodv/eKS7sdPKrQc2+IDhRK5AwHqvZflwUq0gneI3z wOcnM3qe4/RWTfc2MmdTuyxwTaqv/9HkhAOYmI3Ipo+944WTC9tWYSQ4ONyQPqea h3qZuea0UlYo4pFWs/k5k1kL1v+nBJ9hsM1B4YhAX1ONfN3d2coETR3BCtaD3i3Q lGRlVTJjcDpqCmtyu9zJdHQJrz2LadwEuYZUfCdx6OsJ4/aiGasP49F4n/6bdwKK xMIHS0Q9E3J5CKAdljNJfw0RVG6MoDCevem1oy1v/nqq2L3sgNSN9FqGrw+7rbJG 4vRmuuetJ4j/9TgSjZx3/owa4nhQsxlwPHRNPd07Vxen8zoGXVh2maDdfUxBXymt 9AKd9JQhnkR1BicZstIJf+gh70xyRMhpXJSaCxhdsvYxcz0IRitsIFKKmI2jde7F mEOhMFBTD+tsORpwUdBE3toDw/XPF/qN1/mHv9X2gS5lawU2xhBzEp+x1/ySPlRr Ikdh9cT225EdEqh7yn+W =w/+V -----END PGP SIGNATURE----- --b2cJhut8l3AkQ2V77OSCQXufO05aK5EA6-- From nobody Wed Apr 9 08:44:59 2014 Return-Path: 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 239561A03AD for ; Wed, 9 Apr 2014 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 iCH9CQJaAQ4u for ; Wed, 9 Apr 2014 08:44:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25EE21A03AC for ; Wed, 9 Apr 2014 08:44:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67A44BEA1; Wed, 9 Apr 2014 16:44:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwLVT7rfWulC; Wed, 9 Apr 2014 16:44:54 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3E4B7BE8A; Wed, 9 Apr 2014 16:44:54 +0100 (IST) Message-ID: <53456AF5.5010408@cs.tcd.ie> Date: Wed, 09 Apr 2014 16:44:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , marcelo bagnulo braun , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> In-Reply-To: <534569A0.9020505@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/7DJkd4XuuZGDe9sfWCrIZmXOS84 Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:44:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2014 04:39 PM, Daniel Kahn Gillmor wrote: > On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >>> TCP anonymous encryption (TAE) > While the proposed outline does start as anonymous encryption, the > requirement for hooks for higher-level authentication doesn't feel > like anonymous encryption to me. I wonder if this choice of name > will cause people to think that authentication is supposed to be > impossible with this scheme, rather than > supported-but-not-baked-in. > There's an ongoing debate on saag that seems to be closing in on defining the term "opportunistic security" for this kind of thing. I'd say debating terminology here is probably not needed (debating the details of what security you do get is needed of course here and/or in a wg) but this charter text and that activity on terminology can sync up when the time's right. Cheers, S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTRWryAAoJEC88hzaAX42iiK4H/jnzZMJdNsGtNx3IR/rig3MH Cht8ys8UhLD6yO7veYZ03KXw0mrQj+W0/+uny0+JI42RQD+USsV6mVnLhmuVXCqs jtp1hI4tKZLcRhcGv6A4nfZqFQ5W+xAIqCqvwAgpY64T5clYw4yqzHizp2MfntAH mEGpnRbUdh46P1SsgPZVpcpUNTjwF9sMoTVpfD7v07FQU4FvXl3se5jFNcZEgnt9 tKCiUVVMrdQfJVNE8BvinQl9tQEeHW8ttX+AapovSJyVslSpT9rrkS14s7SFMtCB 0/TlQWK2DDhZTMQ0iS7ZnRNGigRE2ZHSYE2SXlxNjZhhp3D7IawJwvHTeUyjf34= =4x1v -----END PGP SIGNATURE----- From nobody Wed Apr 9 09:03:12 2014 Return-Path: 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 6E7461A035C for ; Wed, 9 Apr 2014 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 c4rzLMlAj-XI for ; Wed, 9 Apr 2014 09:03:08 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id A03EF1A03B1 for ; Wed, 9 Apr 2014 09:02:55 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s39G2pLt051533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 09:02:52 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s39G2oAx051532; Wed, 9 Apr 2014 09:02:50 -0700 (PDT) (envelope-from jmg) Date: Wed, 9 Apr 2014 09:02:50 -0700 From: John-Mark Gurney To: Daniel Kahn Gillmor Message-ID: <20140409160250.GX34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534569A0.9020505@fifthhorseman.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 09 Apr 2014 09:02:52 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/8pnsDntVwpOAjKJrl95ntE6vufA Cc: marcelo bagnulo braun , David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:03:10 -0000 Daniel Kahn Gillmor wrote this message on Wed, Apr 09, 2014 at 11:39 -0400: > > (it is open for discussion for the WG if the TCP header should or > > not be protected) > > If the TCP header is protected, how will this interoperate with > widespread packet-mangling mechanisms like NAT? The original tcpcrypt paper talks about nat traversal and includes a link to a paper talking about that.... It isn't just nat traversal that we have to worry about.. There are some transparent proxies that will munge sequence numbers too... This is why the tcpcrypt protocol integrated a relative sequence number and not the absolute, so that the sequence numbers could be munged... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Wed Apr 9 09:07:33 2014 Return-Path: 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 A9CAE1A03B1 for ; Wed, 9 Apr 2014 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 f9fsj5-vgsib for ; Wed, 9 Apr 2014 09:07:30 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 09EAC1A03A1 for ; Wed, 9 Apr 2014 09:07:30 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s39G7Q9A051605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 09:07:27 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s39G7Q9C051604; Wed, 9 Apr 2014 09:07:26 -0700 (PDT) (envelope-from jmg) Date: Wed, 9 Apr 2014 09:07:26 -0700 From: John-Mark Gurney To: Daniel Kahn Gillmor Message-ID: <20140409160726.GY34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534549E6.8050109@fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <534549E6.8050109@fifthhorseman.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 09 Apr 2014 09:07:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1qge7y7D8fjn2WyImBQETCjQGZg Cc: Paul Lambert , marcelo bagnulo braun , Andrea Bittau , "tcpcrypt@ietf.org" , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:07:30 -0000 Daniel Kahn Gillmor wrote this message on Wed, Apr 09, 2014 at 09:23 -0400: > > That is, does the ³anonymous" connection maintain the discovered key and > > associated state to ensure that subsequent connections to the same site > > use the same key? > > by "site" i think you mean host+port. is that correct? > > What are you proposing the TCP stack should do if it sees that the > discovered key for the peer's host+port has changed? > > Should it refuse to complete the connection? should it fallback to > plain (cleartext) TCP? Should it send an alert to somewhere higher in > the stack and allow the connection to proceed otherwise? I was thinking about this... It should always use the new key material, any other solution would defeate the point of the protocol.. Now an interesting question is, what happens when the authentication layer fails to authenticate the remote host, and there are other unauthenticated connections to the remote host? Could it be that the auth failed because the credentials just didn't match? Should there be an option to "kill" the other connections to the remote host because you happen to know that there is an active MITM attack? But clearly this will need to be discussed as part of the WG, but from what I read, (besides the minor nit picks others have pointed out), it looks like it will scope the problem well... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Wed Apr 9 09:22:14 2014 Return-Path: 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 B7EA61A03C9 for ; Wed, 9 Apr 2014 09:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lL20hl7A0135 for ; Wed, 9 Apr 2014 09:22:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC311A03B1 for ; Wed, 9 Apr 2014 09:22:02 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1C00AF986; Wed, 9 Apr 2014 12:21:56 -0400 (EDT) Message-ID: <534573A5.1060800@fifthhorseman.net> Date: Wed, 09 Apr 2014 12:21:57 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Stephen Farrell , marcelo bagnulo braun , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <53456AF5.5010408@cs.tcd.ie> In-Reply-To: <53456AF5.5010408@cs.tcd.ie> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pnm7dxltOsD8TnIxB3tkSjXTGivfOHNm8" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/c-rBZ4Q7hnAPHWGM9dhifOXedII Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:22:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pnm7dxltOsD8TnIxB3tkSjXTGivfOHNm8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/09/2014 11:44 AM, Stephen Farrell wrote: > There's an ongoing debate on saag that seems to be closing > in on defining the term "opportunistic security" for this > kind of thing. I'm aware of that saag saga, and look forward to its conclusion. > I'd say debating terminology here is probably > not needed (debating the details of what security you do get > is needed of course here and/or in a wg) but this charter text > and that activity on terminology can sync up when the time's > right. that sounds fine to me. i just wouldn't want us to have to wait on the conclusion of that debate in order to move forward with tcpcrypt. if we can move forward calling it TAE and then just quickly rename it to TOS (or whatever the outcome of the saag mishegas is) when the time comes, that would be ok. I hope people will respond to the substantive questions raised in this exchange (in particular, the Privacy Considerations) and not the terminology wrangling. --dkg --pnm7dxltOsD8TnIxB3tkSjXTGivfOHNm8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTRXOlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcQ9EQAOeg6LCC5aUGvZdqgG8e8stV SF/CDm752zaPFH7toyLYmpY/akKMI14/F7aIuRdtRv1ZypLMYyXLskcVLL0Xh0JI 8o/xd4rUdqbf5hvFKGmGvmRAe0wjK7E9uKqM1k74Dp6Z/dKvm0n9X/65ZOORUsRb B/xjr2jAvfjC+UlXAVoylJxUpo5p11mUr4NFZ5Q+FoDEvJbJLcUn0r2HxhFvJyiI tSYqrZIbMtIxvA5FiaXa+Xiiqv2UkYqJdEpe18ufbZd4r1/21zQdxJicICk7Kc5m jbPPFovJ5Zdug8Iu+6Rnyb5xEDb4euC1xETBeMA8tV4nc0vZKsUbv5QA6MWe+KKT Rqi5n/dHJoBz0HtBqmadm3k6by7ST6o7YnEMzTq594eM6UAV8ZB99+Jy7mjO/uE8 eCELDIkpOi6RMdkqt7nNBDfNNH/2JWwRUJABHQEq0PhsD4RFYareAaJDP8K6nkxE 5Er2wbMLk9lu3CCvO/sK/2moUrT68gSh/93OtVfZVq08GkObhbvLL4Tzxi3xBWFX 8DNVgIqy5B13jQ8jnwNJolCME/MTyuUME+A6sfoKqh0crG0sBz4dZljQdfFwbVzh +ww4cojsMTJgkN3/+nUZsEcFIOn3kUWQl8BWg7U2+NTNftRNZEQFK/PyQt+z4Ysd PDzZ8WZhcMaTgwvbi6IE =vIE6 -----END PGP SIGNATURE----- --pnm7dxltOsD8TnIxB3tkSjXTGivfOHNm8-- From nobody Wed Apr 9 09:25:52 2014 Return-Path: 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 811401A03BD for ; Wed, 9 Apr 2014 09:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 h-uuB-IjTsu8 for ; Wed, 9 Apr 2014 09:25:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 171B51A032E for ; Wed, 9 Apr 2014 09:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58BD0BE9F; Wed, 9 Apr 2014 17:25:47 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlrK1kqpKF7b; Wed, 9 Apr 2014 17:25:47 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE6B0BEB0; Wed, 9 Apr 2014 17:25:45 +0100 (IST) Message-ID: <53457489.4000800@cs.tcd.ie> Date: Wed, 09 Apr 2014 17:25:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , marcelo bagnulo braun , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <53456AF5.5010408@cs.tcd.ie> <534573A5.1060800@fifthhorseman.net> In-Reply-To: <534573A5.1060800@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/v2s4EV7PgOqudrryDCmoESpRIxs Cc: Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:25:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2014 05:21 PM, Daniel Kahn Gillmor wrote: > On 04/09/2014 11:44 AM, Stephen Farrell wrote: >> There's an ongoing debate on saag that seems to be closing in on >> defining the term "opportunistic security" for this kind of >> thing. > > I'm aware of that saag saga, and look forward to its conclusion. > >> I'd say debating terminology here is probably not needed >> (debating the details of what security you do get is needed of >> course here and/or in a wg) but this charter text and that >> activity on terminology can sync up when the time's right. > > that sounds fine to me. i just wouldn't want us to have to wait on > the conclusion of that debate in order to move forward with > tcpcrypt. > > if we can move forward calling it TAE and then just quickly rename > it to TOS (or whatever the outcome of the saag mishegas is) when > the time comes, that would be ok. Yep. We won't block on that. > > I hope people will respond to the substantive questions raised in > this exchange (in particular, the Privacy Considerations) and not > the terminology wrangling. And yep:-) S. > > --dkg > > > > _______________________________________________ Tcpcrypt mailing > list Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTRXSJAAoJEC88hzaAX42igk8IAIVE9AjCwPsvVqT9z5ZPLqtB IrsRL/9+yyKrpjZqgFsXks8chJKzWkvyVLclv8Bh8m86kchxTdxpTCGc29Kf9rHT rgr1EG9OXSO3XOqhnBH2ua1/mUd1c1XZTvt3SKGrZss9wZreNld1Hb0/XFZMo5E8 p9wQfmUCXjQQMCpB6ac3ClaDNzmUEI4POqc9Oy0VSfJ1FzfsXEV8VkORt5dZM6+j 9EHivWlnkFQ+1CNa93MqXiExzE+RFvVJ5+kChGkbFnCNFb9zy/7Yn0lkzVgNMyMC bOHDdGwMHIrLaxlH2SBS4YRb8JRrmS3nK9bajf8duacblBA3P1/IggmN784C3gk= =zop8 -----END PGP SIGNATURE----- From nobody Wed Apr 9 10:23:18 2014 Return-Path: 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 D67F61A02E2 for ; Wed, 9 Apr 2014 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 sfNHXmiublsb for ; Wed, 9 Apr 2014 10:23:11 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 745901A02D4 for ; Wed, 9 Apr 2014 10:23:07 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s39HMjrb024076; Wed, 9 Apr 2014 10:22:45 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1k4dqxwwv0-8 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Apr 2014 10:22:45 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Wed, 9 Apr 2014 10:22:44 -0700 From: Paul Lambert To: Derek Fawcus , "tcpcrypt@ietf.org" Date: Wed, 9 Apr 2014 10:22:48 -0700 Thread-Topic: [Tcpcrypt] Draft charter text Thread-Index: Ac9UGFFn6hSPY93kRSy2JUoGAjz5Bg== Message-ID: References: <533C33D2.4060004@it.uc3m.es> <20140409084423.GA74559@banjo.employees.org> In-Reply-To: <20140409084423.GA74559@banjo.employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-09_03:2014-04-09,2014-04-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404090133 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1B8Jy3px5jp5Sg9dXjnNlmfT7VE 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:23:16 -0000 On 4/9/14, 1:44 AM, "Derek Fawcus" wrote: >On Tue, Apr 08, 2014 at 02:52:05PM -0700, Paul Lambert wrote: >> On 4/2/14, 8:59 AM, "marcelo bagnulo braun" wrote: >> >TCP anonymous encryption (TAE) >> > >> >Anonymous encryption is an anonymous key exchange resulting in >>encryption >> >without authentication. >>=20 >> Is the key discovered used at all in a "sticky" manner? >>=20 >> That is, does the "anonymous" connection maintain the discovered key and >> associated state to ensure that subsequent connections to the same site >> use the same key? >>=20 >> Hopefully yes - if not, this activity is a hazard. > >I take it in the above you're referring to the public key discovered? Yes. =20 > >i.e. similar behaviour to how openssh records an public key for an >unknown location in its known_hosts file, and checks for a change >upon reconnect. Also yes. This is a very important difference from not every checking the public key that is being used. We should NOT mix the =B3sticky=B2 mode and =B3don=B9t care what key=B2 mod= e of operations without clear indication to the user. I would strongly prefer only the =B3sticky mode=B2 where clear indications (akin to SSH) of state changes are given for: - new key for new peer - warning on new key for existing peer/key Paul > >(I initially read the above as session state caching ala SSL) > >.pdf > >_______________________________________________ >Tcpcrypt mailing list >Tcpcrypt@ietf.org >https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Wed Apr 9 23:50:44 2014 Return-Path: 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 4F1D51A027F for ; Wed, 9 Apr 2014 23:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 f0UHlugr4t09 for ; Wed, 9 Apr 2014 23:50:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 320FF1A012F for ; Wed, 9 Apr 2014 23:50:36 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 94D34C34D3B; Thu, 10 Apr 2014 08:50:35 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id A533FCC008B; Thu, 10 Apr 2014 08:50:34 +0200 (CEST) Received: from 93.158.47.214 ([93.158.47.214]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Thu, 10 Apr 2014 08:50:34 +0200 Message-ID: <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> Date: Thu, 10 Apr 2014 08:50:34 +0200 From: MARCELO BAGNULO BRAUN To: Daniel Kahn Gillmor References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> In-Reply-To: <534569A0.9020505@fifthhorseman.net> 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); Thu, 10 Apr 2014 08:50:35 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20622.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/QxQLuIlqilU-ynBZNdw1sIyV4q4 Cc: David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 06:50:42 -0000 Daniel Kahn Gillmor dijo: > On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >> TCP anonymous encryption (TAE) > > While the proposed outline does start as anonymous encryption, the > requirement for hooks for higher-level authentication doesn't feel like > anonymous encryption to me. I wonder if this choice of name will cause > people to think that authentication is supposed to be impossible with > this scheme, rather than supported-but-not-baked-in. what stephen said. We initially called it transport level oportunistic encryption, but we didnt wanted to end un in a terminology discussion here so we called it anonymous encryption, but i agree the name is at odds with the higher layer authentication add on we should wait for saag to finish their discussion or if you have a better name suggestion, please go ahead > >> - The protocol must have acceptable performance. For example, session >> caching should be used to avoid expensive public key operations on >> connection set up. > > I'm not sure that we want the term "session caching" in the charter, > mainly because: > > a) it's not clear what a "session" is without a clearer specification > of the protocol, and > > b) it seems to rule out any architecture that doesn't permit something > that could be called "session caching", even if we come up with an > session-less architecture that is more performant. > agree we should probably call it crypto material re use, or something along those lines, similar to what we are discussing with Paul Lambert in the other thread. Actually i should have brought this up in that context... > >> - A framework for anonimous encryption for TCP connections. > > spelling nitpick: i think you mean "anonymous" here (and three other > places in the text) > right, thanks >> (it is open for discussion for the WG if the TCP header should or >> not be protected) > > If the TCP header is protected, how will this interoperate with > widespread packet-mangling mechanisms like NAT? > > I would love to see NAT die a quiet death, but it doesn't seem likely to > happen any time soon. if we design a spec that breaks when used across > NAT, i doubt it will see much useful deployment :( > right, but it is up for discussion in the WG, so we can figure it out later. besides it is not an all or nothing disucssion, right? We can decide to protect those fields that are less changed by middle boxes. I guess as you say, that doesnt make sense to aim to protect the addresses and port fields, as it would be incompatible with nats. One discussion is whether we aim to protect the seq number and the ack number. This wouldnt break with nats but with other middle boxes. This is also related with where to carry the crypto information (like the hmac for the payload). If we want to protect some of the tcp header fields, then we should carry the hmac in tcp options, as it becomes harder to send the hmac in the payload, as ack many times dont carry data, so you may end up consumin seq number space when sending empty acks... so in a nutshell, this seems like a long discussion that is central to the solution design, that is why we propose to have it once the wg is formed, makes sense? > > Privacy Considerations > ---------------------- > > This charter makes no mention of any privacy considerations as > first-order concerns. Two immediate considerations spring to mind: > > 0) can a passive eavesdropper link two distinct sessions with each > other using whatever extension information is present in the packets? > Consider Alice checking her e-mail from a laptop. If the exposed data > are not unlinkable, a network observer who watches traffic at the > mailserver can tell which network locations Alice connects from, at what > times. > > 1) can the server link two subsequent connections from a given client? > in some cases, a client will want to provide some proof of continuity > to a server (e.g. maintaining an authenticated session across a series > of TCP connections). In other cases, the client will want to be able to > mask the fact that it is the same client to the server (e.g. when > connecting to widely-used advertising servers, analytics sites, or CDNs, > clients that want to avoid leaking their browsing history to the backend > might prefer to keep these connections unlinkable). What mechanisms > would such a spec provide to be able to accomodate both cases? > > Do we want the group to consider these privacy considerations (i do)? > if so, should they be included in the charter? yes and yes do you mind if i ask you to suggest the text you would like to see included in the charter? do you think we need a specific deliverable in security (both security and privacy aspects?) Regards, marcelo > > Regards, > > --dkg > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Fri Apr 11 13:38:10 2014 Return-Path: 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 AD3971A022E for ; Fri, 11 Apr 2014 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] 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 QUBS8Dn9wVrA for ; Fri, 11 Apr 2014 13:38:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8964D1A02F4 for ; Fri, 11 Apr 2014 13:37:56 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3BKbXkf007869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Apr 2014 13:37:33 -0700 (PDT) Message-ID: <5348528D.1030101@isi.edu> Date: Fri, 11 Apr 2014 13:37:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , Daniel Kahn Gillmor References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> In-Reply-To: <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/QVqdvLJC4pyv5Lh9Hd8FhtVAydw Cc: tcpcrypt@ietf.org, Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:38:04 -0000 On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: > Daniel Kahn Gillmor dijo: > >> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >>> TCP anonymous encryption (TAE) >> >> While the proposed outline does start as anonymous encryption, the >> requirement for hooks for higher-level authentication doesn't feel like >> anonymous encryption to me. Or me either; anonymous encryption is useful independent of whether higher-level hooks are provided or not. (IMO that was a mistake made when BTNS was being worked; the original concept of AE was IMO warped into necessarily including channel binding and connection latching, which severely limits the benefit of AE --- CB/CL just move the need for key distribution to a different layer, whereas true AE can avoid it with lesser benefit). > we should wait for saag to finish their discussion or if you have a > better name suggestion, please go ahead SAAG is trying to redefine widely-cited terminology; that seems like a bad idea. Further, there's a difference between anonymous and 'keyless'. Anonymous implies lack of traceability, which is harder to prove. Most of the time I've seen "anonymous" it means "keyless", as in unsigned Diffie-Hellman. On the SAAG list, I offered a few alternatives (all of which were dismissed, of course), depending on what's being described: zero-key zero-ID These play off of "zero-configuration" and "zero-touch" network management, and IMO still might be useful if you're interested in a descriptive term (rather than trying to redefine a long-cited one). ... > I guess as you say, that doesnt make sense to aim to protect the > addresses and port fields, as it would be incompatible with nats. FWIW, that has its merits (NATs are an attack that some security protocols are designed to protect against). TCP-AO isn't compatible with NATs, but there is an extension that is, FWIW. > One discussion is whether we aim to protect the seq number and the ack > number. This wouldnt break with nats but with other middle boxes. There is no way to protect the signalling part of TCP and be compatible with rewriting NATs; IMO such compatibility should be out of scope. > This is also related with where to carry the crypto information (like > the hmac for the payload). If we want to protect some of the tcp header > fields, then we should carry the hmac in tcp options, as it becomes > harder to send the hmac in the payload, as ack many times dont carry > data, so you may end up consumin seq number space when sending empty > acks... so in a nutshell, this seems like a long discussion that is > central to the solution design, that is why we propose to have it once > the wg is formed, makes sense? That's why TCP-AO has its HMAC as a header option. FWIW, I also posted a way to use TCP-AO for encryption. Joe From nobody Sun Apr 13 00:09:25 2014 Return-Path: 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 B79841A027C for ; Sun, 13 Apr 2014 00:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BUgAQrOpZSye for ; Sun, 13 Apr 2014 00:09:20 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id B160C1A0274 for ; Sun, 13 Apr 2014 00:09:05 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EB4E2FA970B for ; Sun, 13 Apr 2014 09:09:02 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id D49649D4532 for ; Sun, 13 Apr 2014 09:09:02 +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; Sun, 13 Apr 2014 09:09:02 +0200 Message-ID: <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> Date: Sun, 13 Apr 2014 09:09:02 +0200 From: MARCELO BAGNULO BRAUN To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> In-Reply-To: <5348528D.1030101@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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Sun, 13 Apr 2014 09:09:02 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20628.005 X-TM-AS-Result: No--15.102-7.0-31-1 X-imss-scan-details: No--15.102-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xj5PV-2B7empic4ZmJkW9jRkviQ 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 07:09:25 -0000 Joe Touch dijo: > > > On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: >> Daniel Kahn Gillmor dijo: >> >>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >>>> TCP anonymous encryption (TAE) >>> >>> While the proposed outline does start as anonymous encryption, the >>> requirement for hooks for higher-level authentication doesn't feel like >>> anonymous encryption to me. > > Or me either; anonymous encryption is useful independent of whether > higher-level hooks are provided or not. > > (IMO that was a mistake made when BTNS was being worked; the original > concept of AE was IMO warped into necessarily including channel > binding and connection latching, which severely limits the benefit of > AE --- CB/CL just move the need for key distribution to a different > layer, whereas true AE can avoid it with lesser benefit). > >> we should wait for saag to finish their discussion or if you have a >> better name suggestion, please go ahead > > SAAG is trying to redefine widely-cited terminology; that seems like > a bad idea. > > Further, there's a difference between anonymous and 'keyless'. > Anonymous implies lack of traceability, which is harder to prove. > > Most of the time I've seen "anonymous" it means "keyless", as in > unsigned Diffie-Hellman. > > On the SAAG list, I offered a few alternatives (all of which were > dismissed, of course), depending on what's being described: > > zero-key > > zero-ID > > These play off of "zero-configuration" and "zero-touch" network > management, and IMO still might be useful if you're interested in a > descriptive term (rather than trying to redefine a long-cited one). > > ... >> I guess as you say, that doesnt make sense to aim to protect the >> addresses and port fields, as it would be incompatible with nats. > > FWIW, that has its merits (NATs are an attack that some security > protocols are designed to protect against). > > TCP-AO isn't compatible with NATs, but there is an extension that is, FWIW. > >> One discussion is whether we aim to protect the seq number and the ack >> number. This wouldnt break with nats but with other middle boxes. > > There is no way to protect the signalling part of TCP and be > compatible with rewriting NATs; IMO such compatibility should be out > of scope. > >> This is also related with where to carry the crypto information (like >> the hmac for the payload). If we want to protect some of the tcp header >> fields, then we should carry the hmac in tcp options, as it becomes >> harder to send the hmac in the payload, as ack many times dont carry >> data, so you may end up consumin seq number space when sending empty >> acks... so in a nutshell, this seems like a long discussion that is >> central to the solution design, that is why we propose to have it once >> the wg is formed, makes sense? > > That's why TCP-AO has its HMAC as a header option. > > FWIW, I also posted a way to use TCP-AO for encryption. > > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Sun Apr 13 08:56:53 2014 Return-Path: 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 D95C11A02C6 for ; Sun, 13 Apr 2014 08:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 hO5y-Thh-Vns for ; Sun, 13 Apr 2014 08:56:50 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCCC1A01DE for ; Sun, 13 Apr 2014 08:56:50 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so3009386wib.11 for ; Sun, 13 Apr 2014 08:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4JSLOn2v7Tqf68M1IusRGxb1BoWTfU2TS47vfrb0Ruw=; b=vkGCMST38iIQu6QexKTPlO1w/VOCcPKUvR/h1k9up8Lr8G5evXKk7teKo5TnVMvfRI eZcIq8CD8dOtdSsKMn/hf+hdxJ25+FDoAtsK/LTX8dV6Rm7sOfjaZ63xT24ylY2oDYTK j8DBco2/ROdFGqC79k/O8/Qy7iaAFsVRMKe1wIpMQ0WVlM62aR6Vc99qjBnv/xsBunve aR3t/QWetTCgKXFdkHIZWOxeCy7dFHwl53QJdp43rmatTc1JTSgyBx4oLj7FZ3O6XBcJ RekJFIQvWToxhfQ65uGaggOHVGZhC57XXr7UmXc9yfsussQhvuytkD9AUJEd7dQj9iOG WAhQ== MIME-Version: 1.0 X-Received: by 10.194.59.226 with SMTP id c2mr29262111wjr.6.1397404607879; Sun, 13 Apr 2014 08:56:47 -0700 (PDT) Sender: bittau@gmail.com Received: by 10.217.61.10 with HTTP; Sun, 13 Apr 2014 08:56:47 -0700 (PDT) In-Reply-To: <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> Date: Sun, 13 Apr 2014 08:56:47 -0700 X-Google-Sender-Auth: ozGsRKRyiKP3rCZt2mG-Uuiumt0 Message-ID: From: Andrea Bittau To: MARCELO BAGNULO BRAUN Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Z77UvjLeC4gRPiHeEjj1hKMtN94 Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 15:56:53 -0000 Here're some comments on points raised (I hope I covered it all): * Header protection. We probably can't encrypt most of the header without breaking NATs but there probably are fields we can MAC without breaking NATs (e.g., relative sequence numbers). There could also be a software enabled mode where MACing certain fields is mandatory - e.g., MACing the RST, enabled maybe on BGP connections. * "sticky" a la SSH keys. This is an application-layer concern (where authentication is performed) - not something to be tackled at the transport layer. Care must be taken with the forward secrecy requirement and the solution must work with load balancers / connecting to different backends. For what it's worth, session caching at the transport layer is a temporary, poor man's implementation of this - if there was no man-in-the-middle on the first connection, the subsequent cached connections are safe. * UDP. The fundamental advantage in TCP is the existing three way handshake where we can signal whether tcpcrypt is available or not. This gives us transparent incremental adoption. In UDP we don't have this. So an application layer solution will probably be as good as a transport layer solution (both face the same bootstrap problem). Unless you do crazy things like send the first UDP packet with an invalid but fixed "UDPCrypt" checksum to signal that you want to start encrypting - but that's a whole different mess in itself that is out of scope for this effort. * NATs & Middleboxes. The solution must work with them. The goal should be that wherever TCP works, tcpcrypt works, too (maybe disabled initially). * Session caching. I agree that it's not fundamental but rather it's a performance optimization. Hey if a scheme that is always fast exists, then that's good enough. The high level requirement is that it should be fast enough that you can turn it on by default. (A session, in practice, is a TCP connection.) I'm not sure how to avoid public key operations for connection establishment and that's why we thought session caching should be a requirement in practice, as we want to avoid having public key operations for each connection. * Privacy considerations. Traffic analysis and side-channels are out of scope. Trying to detect users by IP address, port addresses, time, traffic patterns (packet lengths and inter-packet intervals) is something we should not require to defend against. This is not intended to be a Tor-like solution. If, however, two sessions cannot be linked from the information stated above, they should not be linkable by the way we encrypt layer-7 data. I'd be happy to make that a requirement - namely that any encryption (or metadata added by tcpcrypt) does not add to a packet's "linkability" to a user or previous connection (of course we cannot deal with lower layers or traffic analysis as stated). * Authentication failures & some fail some don't to same host. There's a synergy between multipath TCP and tcpcrypt - it's harder to mount attacks because the attacker has to be on path on each connection, and it's easier to detect (and potentially kill) one path that is misbehaving. In any event, authentication failures are application-specific problems. In a web browser that supports authentication and mandates it, you'll probably get a red screen with a certificate failure. An e-mail client will probably pop-up a dialog saying unable to connect / verify server identity. The default, where there is no authentication and the application is tcpcrypt-unaware, means that the connection will always succeed and that the user will not even be aware that the connection is encrypted (or not). Nothing changes from the app's and user's perspective. There's only the added bonus of encryption if no man-in-the-middle is present. * Exposing hooks for authentication (e.g., Session ID). We do not require authentication, so exposing a hook for it does not provide any harm in my mind as it can simply be ignored by all. If anything, exposing the hook will make the protocol more future proof. For example, it can avoid double encryption - the application has a way of verifying that the layer-4 encryption is safe and does not need to redo its own encryption, but rather it merely includes the Session ID in its (possibly already existing) authentication. Plus, after doing all the hard work of setting up an encrypted channel, it seems reasonable to take the extra step to expose a simple hash which can be used to greatly improve the security guarantees provided. We don't want to limit our security guarantees by design. On Sun, Apr 13, 2014 at 12:09 AM, MARCELO BAGNULO BRAUN wrote: > Joe Touch dijo: > >> >> >> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: >>> >>> Daniel Kahn Gillmor dijo: >>> >>>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >>>>> >>>>> TCP anonymous encryption (TAE) >>>> >>>> >>>> While the proposed outline does start as anonymous encryption, the >>>> requirement for hooks for higher-level authentication doesn't feel like >>>> anonymous encryption to me. >> >> >> Or me either; anonymous encryption is useful independent of whether >> higher-level hooks are provided or not. >> >> (IMO that was a mistake made when BTNS was being worked; the original >> concept of AE was IMO warped into necessarily including channel binding and >> connection latching, which severely limits the benefit of AE --- CB/CL just >> move the need for key distribution to a different layer, whereas true AE can >> avoid it with lesser benefit). >> >>> we should wait for saag to finish their discussion or if you have a >>> better name suggestion, please go ahead >> >> >> SAAG is trying to redefine widely-cited terminology; that seems like a bad >> idea. >> >> Further, there's a difference between anonymous and 'keyless'. Anonymous >> implies lack of traceability, which is harder to prove. >> >> Most of the time I've seen "anonymous" it means "keyless", as in unsigned >> Diffie-Hellman. >> >> On the SAAG list, I offered a few alternatives (all of which were >> dismissed, of course), depending on what's being described: >> >> zero-key >> >> zero-ID >> >> These play off of "zero-configuration" and "zero-touch" network >> management, and IMO still might be useful if you're interested in a >> descriptive term (rather than trying to redefine a long-cited one). >> >> ... >>> >>> I guess as you say, that doesnt make sense to aim to protect the >>> addresses and port fields, as it would be incompatible with nats. >> >> >> FWIW, that has its merits (NATs are an attack that some security protocols >> are designed to protect against). >> >> TCP-AO isn't compatible with NATs, but there is an extension that is, >> FWIW. >> >>> One discussion is whether we aim to protect the seq number and the ack >>> number. This wouldnt break with nats but with other middle boxes. >> >> >> There is no way to protect the signalling part of TCP and be compatible >> with rewriting NATs; IMO such compatibility should be out of scope. >> >>> This is also related with where to carry the crypto information (like >>> the hmac for the payload). If we want to protect some of the tcp header >>> fields, then we should carry the hmac in tcp options, as it becomes >>> harder to send the hmac in the payload, as ack many times dont carry >>> data, so you may end up consumin seq number space when sending empty >>> acks... so in a nutshell, this seems like a long discussion that is >>> central to the solution design, that is why we propose to have it once >>> the wg is formed, makes sense? >> >> >> That's why TCP-AO has its HMAC as a header option. >> >> FWIW, I also posted a way to use TCP-AO for encryption. >> >> Joe >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> > > > > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Sun Apr 13 09:45:50 2014 Return-Path: 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 7AA751A01DA for ; Sun, 13 Apr 2014 09:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 xUitTSvD8JIu for ; Sun, 13 Apr 2014 09:45:45 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A979A1A01ED for ; Sun, 13 Apr 2014 09:45:45 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so6468336veb.37 for ; Sun, 13 Apr 2014 09:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k6Izl2MVpy3vR4Bt4QjB2UigFGTs07KWpAHewkp0TY8=; b=EEziGnf2NH5+2zJo87vERs5dBfKCbw64/tGRTlAlh9awvOeNT90EZss+t+hMjb2YyZ e9KAbd/H2BmfZ6bY+9OmGdgomlDJWJD+qxUT9XFe/3FZO5YhmgmpiumV3et/m1+cz3ww g89VhPNWbPZufbWtTAQa2OebHwk/oKdYXFcrofQriWh6E46Rz7PmGCDhb58aNjXPbNOf sEWskJiS9o+tIeuBg9vOpD2dnHXEOHk9c33/sz426DIkV1QFIWrAFN8oD+N+koRaxwsH Udhrw/PJJSpIiO+xPpDAUUpYI3lCNlB9XfAiAYGv41QdYfONGpth042fIHa6zj0wswyA /J6g== MIME-Version: 1.0 X-Received: by 10.58.207.74 with SMTP id lu10mr31874788vec.15.1397407543355; Sun, 13 Apr 2014 09:45:43 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Sun, 13 Apr 2014 09:45:43 -0700 (PDT) In-Reply-To: References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> Date: Sun, 13 Apr 2014 12:45:43 -0400 X-Google-Sender-Auth: TmSrir-WE-vVmnOBqNxp_n-AORE Message-ID: From: Erik Nygren To: Andrea Bittau Content-Type: multipart/alternative; boundary=047d7b6783ce3a6dff04f6ef4c14 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/tgMbuj7mE9q716VVeWO2njeTJeU Cc: MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 16:45:49 -0000 --047d7b6783ce3a6dff04f6ef4c14 Content-Type: text/plain; charset=ISO-8859-1 Thank you for this summary. Along the lines of application hooks, do we want a way for the application layer to be able to safely disable encryption part way through a connection? For example, tcpcrypt may be a good way of protecting the initial TLS handshake (eg, protecting parts of it from passive surveillance) but once the TLS session is established it may be redundant enough that we may wish to let the applications agree to drop back to plain-text at the TCP layer. Any negotiation here presumably needs to be mutual and properly covered by whatever authentication the tcpcrypt connection has. A side-note on NATs: authenticating RSTs could be problematic when a NAT times out a connection and starts reusing source ports (perhaps for a different client to the same server), especially if the client and server on either end using tcpcrypt are unaware of this. There are a bunch of annoying corner-cases in this area. Would we ever want a middle-box (eg, a NAT or transparent proxy) to be able to opportunistically terminate tcpcrypt on both ends? While this is something that active attackers will also try and do, supporting it may allow for helpful middle boxes to give protections even for clients that don't support it. For example, if a users' home NAT gateway did tcpcrypt out to any servers in the world then they could gain some protection from passive pervasive surveillance even for older client software in their home. Erik On Sun, Apr 13, 2014 at 11:56 AM, Andrea Bittau wrote: > Here're some comments on points raised (I hope I covered it all): > > * Header protection. We probably can't encrypt most of the header without > breaking NATs but there probably are fields we can MAC without breaking > NATs > (e.g., relative sequence numbers). > > There could also be a software enabled mode where MACing certain fields > is > mandatory - e.g., MACing the RST, enabled maybe on BGP connections. > > * "sticky" a la SSH keys. This is an application-layer concern (where > authentication is performed) - not something to be tackled at the > transport > layer. Care must be taken with the forward secrecy requirement and the > solution must work with load balancers / connecting to different > backends. > > For what it's worth, session caching at the transport layer is a > temporary, > poor man's implementation of this - if there was no man-in-the-middle on > the > first connection, the subsequent cached connections are safe. > > * UDP. The fundamental advantage in TCP is the existing three way > handshake > where we can signal whether tcpcrypt is available or not. This gives us > transparent incremental adoption. In UDP we don't have this. So an > application layer solution will probably be as good as a transport layer > solution (both face the same bootstrap problem). Unless you do crazy > things > like send the first UDP packet with an invalid but fixed "UDPCrypt" > checksum > to signal that you want to start encrypting - but that's a whole > different > mess in itself that is out of scope for this effort. > > * NATs & Middleboxes. The solution must work with them. The goal should > be > that wherever TCP works, tcpcrypt works, too (maybe disabled initially). > > * Session caching. I agree that it's not fundamental but rather it's a > performance optimization. Hey if a scheme that is always fast exists, > then > that's good enough. The high level requirement is that it should be fast > enough that you can turn it on by default. (A session, in practice, is > a TCP > connection.) I'm not sure how to avoid public key operations for > connection > establishment and that's why we thought session caching should be a > requirement in practice, as we want to avoid having public key > operations for > each connection. > > * Privacy considerations. Traffic analysis and side-channels are out of > scope. > Trying to detect users by IP address, port addresses, time, traffic > patterns > (packet lengths and inter-packet intervals) is something we should not > require > to defend against. This is not intended to be a Tor-like solution. If, > however, two sessions cannot be linked from the information stated > above, they > should not be linkable by the way we encrypt layer-7 data. I'd be happy > to > make that a requirement - namely that any encryption (or metadata added > by > tcpcrypt) does not add to a packet's "linkability" to a user or previous > connection (of course we cannot deal with lower layers or traffic > analysis as > stated). > > * Authentication failures & some fail some don't to same host. There's a > synergy between multipath TCP and tcpcrypt - it's harder to mount attacks > because the attacker has to be on path on each connection, and it's > easier to > detect (and potentially kill) one path that is misbehaving. In any > event, > authentication failures are application-specific problems. In a web > browser > that supports authentication and mandates it, you'll probably get a red > screen > with a certificate failure. An e-mail client will probably pop-up a > dialog > saying unable to connect / verify server identity. The default, where > there > is no authentication and the application is tcpcrypt-unaware, means that > the > connection will always succeed and that the user will not even be aware > that > the connection is encrypted (or not). Nothing changes from the app's and > user's perspective. There's only the added bonus of encryption if no > man-in-the-middle is present. > > * Exposing hooks for authentication (e.g., Session ID). We do not require > authentication, so exposing a hook for it does not provide any harm in > my mind > as it can simply be ignored by all. If anything, exposing the hook will > make > the protocol more future proof. For example, it can avoid double > encryption - > the application has a way of verifying that the layer-4 encryption is > safe and > does not need to redo its own encryption, but rather it merely includes > the > Session ID in its (possibly already existing) authentication. Plus, > after > doing all the hard work of setting up an encrypted channel, it seems > reasonable to take the extra step to expose a simple hash which can be > used to > greatly improve the security guarantees provided. We don't want to > limit our > security guarantees by design. > > > On Sun, Apr 13, 2014 at 12:09 AM, MARCELO BAGNULO BRAUN > wrote: > > Joe Touch dijo: > > > >> > >> > >> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: > >>> > >>> Daniel Kahn Gillmor dijo: > >>> > >>>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: > >>>>> > >>>>> TCP anonymous encryption (TAE) > >>>> > >>>> > >>>> While the proposed outline does start as anonymous encryption, the > >>>> requirement for hooks for higher-level authentication doesn't feel > like > >>>> anonymous encryption to me. > >> > >> > >> Or me either; anonymous encryption is useful independent of whether > >> higher-level hooks are provided or not. > >> > >> (IMO that was a mistake made when BTNS was being worked; the original > >> concept of AE was IMO warped into necessarily including channel binding > and > >> connection latching, which severely limits the benefit of AE --- CB/CL > just > >> move the need for key distribution to a different layer, whereas true > AE can > >> avoid it with lesser benefit). > >> > >>> we should wait for saag to finish their discussion or if you have a > >>> better name suggestion, please go ahead > >> > >> > >> SAAG is trying to redefine widely-cited terminology; that seems like a > bad > >> idea. > >> > >> Further, there's a difference between anonymous and 'keyless'. Anonymous > >> implies lack of traceability, which is harder to prove. > >> > >> Most of the time I've seen "anonymous" it means "keyless", as in > unsigned > >> Diffie-Hellman. > >> > >> On the SAAG list, I offered a few alternatives (all of which were > >> dismissed, of course), depending on what's being described: > >> > >> zero-key > >> > >> zero-ID > >> > >> These play off of "zero-configuration" and "zero-touch" network > >> management, and IMO still might be useful if you're interested in a > >> descriptive term (rather than trying to redefine a long-cited one). > >> > >> ... > >>> > >>> I guess as you say, that doesnt make sense to aim to protect the > >>> addresses and port fields, as it would be incompatible with nats. > >> > >> > >> FWIW, that has its merits (NATs are an attack that some security > protocols > >> are designed to protect against). > >> > >> TCP-AO isn't compatible with NATs, but there is an extension that is, > >> FWIW. > >> > >>> One discussion is whether we aim to protect the seq number and the ack > >>> number. This wouldnt break with nats but with other middle boxes. > >> > >> > >> There is no way to protect the signalling part of TCP and be compatible > >> with rewriting NATs; IMO such compatibility should be out of scope. > >> > >>> This is also related with where to carry the crypto information (like > >>> the hmac for the payload). If we want to protect some of the tcp header > >>> fields, then we should carry the hmac in tcp options, as it becomes > >>> harder to send the hmac in the payload, as ack many times dont carry > >>> data, so you may end up consumin seq number space when sending empty > >>> acks... so in a nutshell, this seems like a long discussion that is > >>> central to the solution design, that is why we propose to have it once > >>> the wg is formed, makes sense? > >> > >> > >> That's why TCP-AO has its HMAC as a header option. > >> > >> FWIW, I also posted a way to use TCP-AO for encryption. > >> > >> Joe > >> > >> _______________________________________________ > >> Tcpcrypt mailing list > >> Tcpcrypt@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpcrypt > >> > > > > > > > > -- > > ---- > > MARCELO BAGNULO BRAUN > > WebCartero > > Universidad Carlos III de Madrid > > > > _______________________________________________ > > Tcpcrypt mailing list > > Tcpcrypt@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpcrypt > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > --047d7b6783ce3a6dff04f6ef4c14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for this summary.

Along the lines of application hooks, do we want a way for the applicati= on layer to be able to safely disable encryption part way through a connect= ion? For example, tcpcrypt may be a good way of protecting the initial TLS = handshake (eg, protecting parts of it from passive surveillance) but once t= he TLS session is established it may be redundant enough that we may wish t= o let the applications agree to drop back to plain-text at the TCP layer.= =A0 Any negotiation here presumably needs to be mutual and properly covered= by whatever authentication the tcpcrypt connection has.


A side-note on NATs:=A0 authenticating RSTs could be problema= tic when a NAT times out a connection and starts reusing source ports (perh= aps for a different client to the same server), especially if the client an= d server on either end using tcpcrypt are unaware of this.=A0 There are a b= unch of annoying corner-cases in this area.

Would we ever want a middle-box (eg, a NAT or transparent proxy) = to be able to opportunistically terminate tcpcrypt on both ends?=A0 While t= his is something that active attackers will also try and do, supporting it = may allow for helpful middle boxes to give protections even for clients tha= t don't support it.=A0 For example, if a users' home NAT gateway di= d tcpcrypt out to any servers in the world then they could gain some protec= tion from passive pervasive surveillance even for older client software in = their home.

=A0=A0=A0=A0=A0 Erik


=
On Sun, Apr 13, 2014 at 11:56 AM, Andrea Bit= tau <bittau@cs.stanford.edu> wrote:
Here're some comments on points raised (= I hope I covered it all):

* Header protection. =A0We probably can't encrypt most of the header wi= thout
=A0 breaking NATs but there probably are fields we can MAC without breaking= NATs
=A0 (e.g., relative sequence numbers).

=A0 There could also be a software enabled mode where MACing certain fields= is
=A0 mandatory - e.g., MACing the RST, enabled maybe on BGP connections.

* "sticky" a la SSH keys. =A0This is an application-layer concern= (where
=A0 authentication is performed) - not something to be tackled at the trans= port
=A0 layer. =A0Care must be taken with the forward secrecy requirement and t= he
=A0 solution must work with load balancers / connecting to different backen= ds.

=A0 For what it's worth, session caching at the transport layer is a te= mporary,
=A0 poor man's implementation of this - if there was no man-in-the-midd= le on the
=A0 first connection, the subsequent cached connections are safe.

* UDP. =A0The fundamental advantage in TCP is the existing three way handsh= ake
=A0 where we can signal whether tcpcrypt is available or not. =A0This gives= us
=A0 transparent incremental adoption. =A0In UDP we don't have this. =A0= So an
=A0 application layer solution will probably be as good as a transport laye= r
=A0 solution (both face the same bootstrap problem). =A0Unless you do crazy= things
=A0 like send the first UDP packet with an invalid but fixed "UDPCrypt= " checksum
=A0 to signal that you want to start encrypting - but that's a whole di= fferent
=A0 mess in itself that is out of scope for this effort.

* NATs & Middleboxes. =A0The solution must work with them. =A0The goal = should be
=A0 that wherever TCP works, tcpcrypt works, too (maybe disabled initially)= .

* Session caching. =A0I agree that it's not fundamental but rather it&#= 39;s a
=A0 performance optimization. =A0Hey if a scheme that is always fast exists= , then
=A0 that's good enough. =A0The high level requirement is that it should= be fast
=A0 enough that you can turn it on by default. =A0(A session, in practice, = is a TCP
=A0 connection.) =A0I'm not sure how to avoid public key operations for= connection
=A0 establishment and that's why we thought session caching should be a=
=A0 requirement in practice, as we want to avoid having public key operatio= ns for
=A0 each connection.

* Privacy considerations. =A0Traffic analysis and side-channels are out of = scope.
=A0 Trying to detect users by IP address, port addresses, time, traffic pat= terns
=A0 (packet lengths and inter-packet intervals) is something we should not = require
=A0 to defend against. =A0This is not intended to be a Tor-like solution. = =A0If,
=A0 however, two sessions cannot be linked from the information stated abov= e, they
=A0 should not be linkable by the way we encrypt layer-7 data. =A0I'd b= e happy to
=A0 make that a requirement - namely that any encryption (or metadata added= by
=A0 tcpcrypt) does not add to a packet's "linkability" to a u= ser or previous
=A0 connection (of course we cannot deal with lower layers or traffic analy= sis as
=A0 stated).

* Authentication failures & some fail some don't to same host. =A0T= here's a
=A0 synergy between multipath TCP and tcpcrypt - it's harder to mount a= ttacks
=A0 because the attacker has to be on path on each connection, and it's= easier to
=A0 detect (and potentially kill) one path that is misbehaving. =A0In any e= vent,
=A0 authentication failures are application-specific problems. =A0In a web = browser
=A0 that supports authentication and mandates it, you'll probably get a= red screen
=A0 with a certificate failure. =A0An e-mail client will probably pop-up a = dialog
=A0 saying unable to connect / verify server identity. =A0The default, wher= e there
=A0 is no authentication and the application is tcpcrypt-unaware, means tha= t the
=A0 connection will always succeed and that the user will not even be aware= that
=A0 the connection is encrypted (or not). =A0Nothing changes from the app&#= 39;s and
=A0 user's perspective. =A0There's only the added bonus of encrypti= on if no
=A0 man-in-the-middle is present.

* Exposing hooks for authentication (e.g., Session ID). =A0We do not requir= e
=A0 authentication, so exposing a hook for it does not provide any harm in = my mind
=A0 as it can simply be ignored by all. =A0If anything, exposing the hook w= ill make
=A0 the protocol more future proof. =A0For example, it can avoid double enc= ryption -
=A0 the application has a way of verifying that the layer-4 encryption is s= afe and
=A0 does not need to redo its own encryption, but rather it merely includes= the
=A0 Session ID in its (possibly already existing) authentication. =A0Plus, = after
=A0 doing all the hard work of setting up an encrypted channel, it seems =A0 reasonable to take the extra step to expose a simple hash which can be = used to
=A0 greatly improve the security guarantees provided. =A0We don't want = to limit our
=A0 security guarantees by design.


On Sun, Apr 13, 2014 at 12:09 AM, MARCELO BAGNULO BRAUN
<marcelo@it.uc3m.es> wrote:=
> Joe Touch <touch@isi.edu> d= ijo:
>
>>
>>
>> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote:
>>>
>>> Daniel Kahn Gillmor <dkg@fifthhorseman.net> dijo:
>>>
>>>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote:
>>>>>
>>>>> TCP anonymous encryption (TAE)
>>>>
>>>>
>>>> While the proposed outline does start as anonymous encrypt= ion, the
>>>> requirement for hooks for higher-level authentication does= n't feel like
>>>> anonymous encryption to me.
>>
>>
>> Or me either; anonymous encryption is useful independent of whethe= r
>> higher-level hooks are provided or not.
>>
>> (IMO that was a mistake made when BTNS was being worked; the origi= nal
>> concept of AE was IMO warped into necessarily including channel bi= nding and
>> connection latching, which severely limits the benefit of AE --- C= B/CL just
>> move the need for key distribution to a different layer, whereas t= rue AE can
>> avoid it with lesser benefit).
>>
>>> we should wait for saag to finish their discussion or if you h= ave a
>>> better name suggestion, please go ahead
>>
>>
>> SAAG is trying to redefine widely-cited terminology; that seems li= ke a bad
>> idea.
>>
>> Further, there's a difference between anonymous and 'keyle= ss'. Anonymous
>> implies lack of traceability, which is harder to prove.
>>
>> Most of the time I've seen "anonymous" it means &quo= t;keyless", as in unsigned
>> Diffie-Hellman.
>>
>> On the SAAG list, I offered a few alternatives (all of which were<= br> >> dismissed, of course), depending on what's being described: >>
>> =A0 =A0 =A0 =A0 zero-key
>>
>> =A0 =A0 =A0 =A0 zero-ID
>>
>> These play off of "zero-configuration" and "zero-to= uch" network
>> management, and IMO still might be useful if you're interested= in a
>> descriptive term (rather than trying to redefine a long-cited one)= .
>>
>> ...
>>>
>>> I guess as you say, that doesnt make sense to aim to protect t= he
>>> addresses and port fields, as it would be incompatible with na= ts.
>>
>>
>> FWIW, that has its merits (NATs are an attack that some security p= rotocols
>> are designed to protect against).
>>
>> TCP-AO isn't compatible with NATs, but there is an extension t= hat is,
>> FWIW.
>>
>>> One discussion is whether we aim to protect the seq number and= the ack
>>> number. This wouldnt break with nats but with other middle box= es.
>>
>>
>> There is no way to protect the signalling part of TCP and be compa= tible
>> with rewriting NATs; IMO such compatibility should be out of scope= .
>>
>>> This is also related with where to carry the crypto informatio= n (like
>>> the hmac for the payload). If we want to protect some of the t= cp header
>>> fields, then we should carry the hmac in tcp options, as it be= comes
>>> harder to send the hmac in the payload, as ack many times dont= carry
>>> data, so you may end up consumin seq number space when sending= empty
>>> acks... so in a nutshell, this seems like a long discussion th= at is
>>> central to the solution design, that is why we propose to have= it once
>>> the wg is formed, makes sense?
>>
>>
>> That's why TCP-AO has its HMAC as a header option.
>>
>> FWIW, I also posted a way to use TCP-AO for encryption.
>>
>> Joe
>>
>> _______________________________________________
>> Tcpcrypt mailing list
>> Tcpcrypt@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpcrypt
>>
>
>
>
> --
> ----
> MARCELO BAGNULO BRAUN
> WebCartero
> Universidad Carlos III de Madrid
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt

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

--047d7b6783ce3a6dff04f6ef4c14-- From nobody Sun Apr 13 10:42:05 2014 Return-Path: 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 E2DB91A02CE for ; Sun, 13 Apr 2014 10:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] 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 QwCeJAk4-vTP for ; Sun, 13 Apr 2014 10:42:02 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9209B1A01FF for ; Sun, 13 Apr 2014 10:42:02 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3DHfHkd021217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 10:41:25 -0700 (PDT) Message-ID: <534ACC3E.1020308@isi.edu> Date: Sun, 13 Apr 2014 10:41:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrea Bittau , MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/EPkFHcVCD3viEb5c6TZpA7KGdvo Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:42:04 -0000 On 4/13/2014 8:56 AM, Andrea Bittau wrote: > Here're some comments on points raised (I hope I covered it all): > > * Header protection. We probably can't encrypt most of the header without > breaking NATs but there probably are fields we can MAC without breaking NATs > (e.g., relative sequence numbers). You should be able to protect parts of the IP and TCP headers (and, FWIW, both are necessary to protect IP). Skipping the source port and source IP address might not have a big impact on overall effectiveness. > There could also be a software enabled mode where MACing certain fields is > mandatory - e.g., MACing the RST, enabled maybe on BGP connections. You need to MAC the IP dest, dest port, and all signal bits in the IP header (sequence, flags, etc.). This will still make it through a NAT, but will break a 'rewriting proxy' - but that's the kind of attack that TCP crypto ought to protect against, because it's indistinguishable from a MITM attack (it *is* a MITM). > * "sticky" a la SSH keys. This is an application-layer concern (where > authentication is performed) - not something to be tackled at the transport > layer. Care must be taken with the forward secrecy requirement and the > solution must work with load balancers / connecting to different backends. > > For what it's worth, session caching at the transport layer is a temporary, > poor man's implementation of this - if there was no man-in-the-middle on the > first connection, the subsequent cached connections are safe. That won't work if addresses are shared, e.g., behind a NAT. > * NATs & Middleboxes. The solution must work with them. The goal should be > that wherever TCP works, tcpcrypt works, too (maybe disabled initially). Some solutions ought to work with simple NATs, some ought to protect against all rewriting, and nothing is going to be compatible with TCP rewriting. > * Authentication failures & some fail some don't to same host. There's a > synergy between multipath TCP and tcpcrypt FWIW, can we please use a different acronym for the solution of this charter vs. the existing mechanism called tcpcrypt? This sort of comment is difficult to understand otherwise. Maybe call this TCPsec? or tcpcrypto? > * Exposing hooks for authentication (e.g., Session ID). We do not require > authentication, Who's "we"? Are you referring to an existing approach, or this group? IMO, integrity protection is critical - encryption is useless IMO without it. Authentication that ties to a known identity is less so (see BTNS), but it's still important to be able to know that the party involved hasn't changed. TCP-AO demonstrates that the session ID for TCP is already there - it's the TCP connection + ISNs. There's no need for additional session info. Joe From nobody Sun Apr 13 10:44:24 2014 Return-Path: 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 A07471A0208 for ; Sun, 13 Apr 2014 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 x5fhGhJ0zqNU for ; Sun, 13 Apr 2014 10:44:21 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A057A1A01FF for ; Sun, 13 Apr 2014 10:44:21 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3DHi37t022080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 10:44:06 -0700 (PDT) Message-ID: <534ACCE5.2080103@isi.edu> Date: Sun, 13 Apr 2014 10:44:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Erik Nygren , Andrea Bittau References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/DGhDJ5_nIv7Z4VaxyOJ3UlJUk5g Cc: MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:44:22 -0000 On 4/13/2014 9:45 AM, Erik Nygren wrote: > Thank you for this summary. > > Along the lines of application hooks, do we want a way for the > application layer to be able to safely disable encryption part way > through a connection? TCP has no mechanism to do a new handshake mid-connection. Once an option is set during the initial handshake, it should be assumed to be persistent across the connection. A better solution, if the goal is to be lightweight, is to change keying parameters during the connection, at which point the new parameter can be "null". See again TCP-AO for an exampple of how to coordinate keying parameter IDs. > A side-note on NATs: authenticating RSTs could be problematic when a > NAT times out a connection and starts reusing source ports (perhaps for > a different client to the same server), especially if the client and > server on either end using tcpcrypt are unaware of this. There are a > bunch of annoying corner-cases in this area. This issue was discussed in TCP-AO too; IMO, the recommendation there (for authentication) is just as relevant here. Joe From nobody Sun Apr 13 10:48:19 2014 Return-Path: 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 B85301A01FF for ; Sun, 13 Apr 2014 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 86KKMGZBVZT8 for ; Sun, 13 Apr 2014 10:48:17 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 77B411A02CC for ; Sun, 13 Apr 2014 10:48:16 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so6786798vcb.0 for ; Sun, 13 Apr 2014 10:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y9FGiMtP6AbUycSWRspR8coOnp4ZEm6dcGXnHkc2CeQ=; b=QE6ZsitdnXUnUWjCjIfY2mGoYxZZL+YaeGWlREsUA17/TlqnMS58Mtg3L7CfW4EJHU WlQ5z1gPWnGB4sk1zdezCKgP2nnG7LhZoZfl10USbzNyhNEXKZvU4+RY5pC927C0F2nm t0qoeN8opuH6uzkpBRG8UEr9f1woMn8T2CgYRFXTzoozRttVT6MZaP+gSMCh4NmIGC9+ XA1MO1UNxLYRvL+Q4C8evZ66/JKuTGT2KjJ9l3eR3DvYebgS748xmtD3AmoXWw5Zf662 DXP3B9jWdShfMXLKrqKrV9FVwZGnnl34XS5P5fhX5l2u+fK/3Cr8LAgKsjRZu45WNbL3 /04w== X-Received: by 10.220.190.197 with SMTP id dj5mr20666561vcb.19.1397411294193; Sun, 13 Apr 2014 10:48:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Sun, 13 Apr 2014 10:47:53 -0700 (PDT) In-Reply-To: <533C33D2.4060004@it.uc3m.es> References: <533C33D2.4060004@it.uc3m.es> From: Tony Arcieri Date: Sun, 13 Apr 2014 10:47:53 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a11c1c272cbaef504f6f02b85 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Xnx1WokCg1g-n_i9k-d4EL2mqm8 Cc: David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:48:18 -0000 --001a11c1c272cbaef504f6f02b85 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun wrote: > TCP anonymous encryption (TAE) > > Anonymous encryption is an anonymous key exchange resulting in encryption > without authentication Will this idea be compatible with future authentication systems, i.e. could some mechanism verify public keys for you, then hand off the rest of the session to tcpcrypt? -- Tony Arcieri --001a11c1c272cbaef504f6f02b85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
TCP anonymous encryption (TAE)

Anonymous encryption is an anonymous key exchange resulting in encryption without authentication

Will this idea be co= mpatible with future authentication systems, i.e. could some mechanism veri= fy public keys for you, then hand off the rest of the session to tcpcrypt?<= /div>
=A0
--
Tony Arcieri
--001a11c1c272cbaef504f6f02b85-- From nobody Sun Apr 13 10:54:31 2014 Return-Path: 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 662621A02C6 for ; Sun, 13 Apr 2014 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 ZSCiL5oWQram for ; Sun, 13 Apr 2014 10:54:29 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2359A1A0202 for ; Sun, 13 Apr 2014 10:54:29 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so6658470veb.15 for ; Sun, 13 Apr 2014 10:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZcVn8ZBmCbx+L/HByRcnxdOmgjixqm4wz34vJ662Gzo=; b=xopejCEUBsp6JTkigTOKtI25OxEN3CH36TPpv7gHIJjoUvTIggYFqzS0dcUDgUtyUt TOWvcIKukTWYrTT3SRKEB06BmuLar3kL+Q7wtO36RFyOp47CqVThcxcKl0nS6GB20pZC zLL9VjjqHN3mYw6Wq0NPTHeaxP+Jf1NDN5Voy26m46Cx3oZdZszxBaLT5Fp2781atqY1 hhTkCCejTswlDY2JLYoSGaqDwg+wewiOFUjtDYS3LU2zA8PY7bPk8T5VEWxYcKs/UcY6 Z1DIW5C7UAQV9OmuGzr7v/8nSWy2AASfeAj837UgFTGTIi5QR48JBDBVOFOJjWZhf1ys xKxA== MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr32041885vcy.8.1397411666801; Sun, 13 Apr 2014 10:54:26 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Sun, 13 Apr 2014 10:54:26 -0700 (PDT) In-Reply-To: <534ACC3E.1020308@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> Date: Sun, 13 Apr 2014 13:54:26 -0400 X-Google-Sender-Auth: pJstTrHCmcE8mJ-teZ-YpVggjDQ Message-ID: From: Erik Nygren To: Joe Touch Content-Type: multipart/alternative; boundary=089e011618ce013b2704f6f0428a Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aDtxqZDuTnGHP8indLWk4_FF9Yg Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:54:30 -0000 --089e011618ce013b2704f6f0428a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch wrote: > > You need to MAC the IP dest, dest port, and all signal bits in the IP > header (sequence, flags, etc.). This will still make it through a NAT, but > will break a 'rewriting proxy' - but that's the kind of attack that TCP > crypto ought to protect against, because it's indistinguishable from a MITM > attack (it *is* a MITM). > Unfortunately, applying a MAC on the IP dest will break NAT64 which is a valid and increasingly critial use-case. Erik --089e011618ce013b2704f6f0428a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch <touch@isi.edu= > wrote:

You need to MAC the IP dest, dest port, and all signal bits in the IP heade= r (sequence, flags, etc.). This will still make it through a NAT, but will = break a 'rewriting proxy' - but that's the kind of attack that = TCP crypto ought to protect against, because it's indistinguishable fro= m a MITM attack (it *is* a MITM).
=A0
Unfortunately, applying a MAC on the IP dest wil= l break NAT64 which is a valid and increasingly critial use-case.
=

=A0=A0=A0= =A0 Erik

--089e011618ce013b2704f6f0428a-- From nobody Sun Apr 13 11:11:11 2014 Return-Path: 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 B62D81A01FF for ; Sun, 13 Apr 2014 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 hrQiv4-wYOqr for ; Sun, 13 Apr 2014 11:10:57 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7A01A020F for ; Sun, 13 Apr 2014 11:10:57 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3DIALx7029497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 11:10:24 -0700 (PDT) Message-ID: <534AD30D.1040301@isi.edu> Date: Sun, 13 Apr 2014 11:10:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Erik Nygren References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xWAJ67gYwU9z2xJDKop-pflNc1M Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 18:11:08 -0000 On 4/13/2014 10:54 AM, Erik Nygren wrote: > On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch > wrote: > > > You need to MAC the IP dest, dest port, and all signal bits in the > IP header (sequence, flags, etc.). This will still make it through a > NAT, but will break a 'rewriting proxy' - but that's the kind of > attack that TCP crypto ought to protect against, because it's > indistinguishable from a MITM attack (it *is* a MITM). > > Unfortunately, applying a MAC on the IP dest will break NAT64 which is a > valid and increasingly critial use-case. If you avoid MACing any address or port info (except perhaps dest port), then all you have left to identify your connection is the ISN pair, and that seems a bit dangerous. Joe From nobody Sun Apr 13 13:37:29 2014 Return-Path: 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 826BB1A0227 for ; Sun, 13 Apr 2014 13:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 a7E_gOvTVPzS for ; Sun, 13 Apr 2014 13:37:27 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF4271A0210 for ; Sun, 13 Apr 2014 13:37:26 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3DKbI21027656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2014 13:37:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3DKbHqv027655; Sun, 13 Apr 2014 13:37:17 -0700 (PDT) (envelope-from jmg) Date: Sun, 13 Apr 2014 13:37:17 -0700 From: John-Mark Gurney To: Tony Arcieri Message-ID: <20140413203717.GI34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Apr 2014 13:37:18 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/AoS6K9QCwvHz0xWCfnX0gGYLOGI Cc: marcelo bagnulo braun , tcpcrypt@ietf.org, Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:37:28 -0000 Tony Arcieri wrote this message on Sun, Apr 13, 2014 at 10:47 -0700: > On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun wrote: > > > TCP anonymous encryption (TAE) > > > > Anonymous encryption is an anonymous key exchange resulting in encryption > > without authentication > > > Will this idea be compatible with future authentication systems, i.e. could > some mechanism verify public keys for you, then hand off the rest of the > session to tcpcrypt? Yes, as long as the new authentication system can authenticate a token (stream of bytes), then it will be compatible... It will require extensions to the protocol to be compatible... Tcpcrypt had to add to the TLS protocol to provide the ability to authenticate the session tokens that tcpcrypt generated... You did drop part of the message that talks about what you're asking: In particular, the hooks for supporting higher layer authentication will be defined in this document. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Sun Apr 13 13:42:10 2014 Return-Path: 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 E43DE1A022D for ; Sun, 13 Apr 2014 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 8UzTiWHM-P4K for ; Sun, 13 Apr 2014 13:42:08 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 07A041A022B for ; Sun, 13 Apr 2014 13:42:08 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3DKg3gP027737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2014 13:42:03 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3DKg2SX027736; Sun, 13 Apr 2014 13:42:02 -0700 (PDT) (envelope-from jmg) Date: Sun, 13 Apr 2014 13:42:02 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140413204202.GJ34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5348528D.1030101@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Apr 2014 13:42:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/dicbGH14jwLWcy2TwScwq5NFAYQ Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:42:09 -0000 Joe Touch wrote this message on Fri, Apr 11, 2014 at 13:37 -0700: > On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: > >Daniel Kahn Gillmor dijo: > > > >>On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: > >>>TCP anonymous encryption (TAE) > >> > >>While the proposed outline does start as anonymous encryption, the > >>requirement for hooks for higher-level authentication doesn't feel like > >>anonymous encryption to me. > > Or me either; anonymous encryption is useful independent of whether > higher-level hooks are provided or not. I would say w/o the hooks isn't useful... Because either it will need to provide a knob to turn it off (for SSL to prevent double encryption), or we'll suffer double encryption, meaning the layer will be redundant and admins will intentially turn it off to reduce the load on their boxes, defeating the benifits of always on encryption... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Sun Apr 13 13:50:40 2014 Return-Path: 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 EA0821A022F for ; Sun, 13 Apr 2014 13:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 4gKWUPz8uQp6 for ; Sun, 13 Apr 2014 13:50:38 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E81A022D for ; Sun, 13 Apr 2014 13:50:37 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3DKoXMv027853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2014 13:50:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3DKoVgN027846; Sun, 13 Apr 2014 13:50:31 -0700 (PDT) (envelope-from jmg) Date: Sun, 13 Apr 2014 13:50:31 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140413205031.GK34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534AD30D.1040301@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Apr 2014 13:50:34 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/FraULZxNYTXNeLFU7Ec5iTgHCWk Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:50:39 -0000 Joe Touch wrote this message on Sun, Apr 13, 2014 at 11:10 -0700: > On 4/13/2014 10:54 AM, Erik Nygren wrote: > >On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch >> wrote: > > > > > > You need to MAC the IP dest, dest port, and all signal bits in the > > IP header (sequence, flags, etc.). This will still make it through a > > NAT, but will break a 'rewriting proxy' - but that's the kind of > > attack that TCP crypto ought to protect against, because it's > > indistinguishable from a MITM attack (it *is* a MITM). > > > >Unfortunately, applying a MAC on the IP dest will break NAT64 which is a > >valid and increasingly critial use-case. > > If you avoid MACing any address or port info (except perhaps dest port), > then all you have left to identify your connection is the ISN pair, and > that seems a bit dangerous. How/Why is that dangerous? If it is used w/ an authentication layer that authenticates that the session hash is the same on both sides, how is this dangerous? The authentication layer has stated that the session key is known only to the end points, and not to any MITM. MAC'ing the IP/port info will prevent 90% of the internet from using it was most end users are behind NATs... Be it a corrporate nat, or the nat their ISP provided so that they are only allocated one IP... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Sun Apr 13 13:54:45 2014 Return-Path: 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 BEFD01A022F for ; Sun, 13 Apr 2014 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 qi5MBJnNvmuU for ; Sun, 13 Apr 2014 13:54:43 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id D12101A0226 for ; Sun, 13 Apr 2014 13:54:43 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3DKseg6027898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2014 13:54:40 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3DKsZ9B027897; Sun, 13 Apr 2014 13:54:35 -0700 (PDT) (envelope-from jmg) Date: Sun, 13 Apr 2014 13:54:35 -0700 From: John-Mark Gurney To: Erik Nygren Message-ID: <20140413205435.GL34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Apr 2014 13:54:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5PV93bfS67WPaYqdUWy0vdF3H8U Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:54:44 -0000 Erik Nygren wrote this message on Sun, Apr 13, 2014 at 12:45 -0400: > Would we ever want a middle-box (eg, a NAT or transparent proxy) to be able > to opportunistically terminate tcpcrypt on both ends? While this is > something that active attackers will also try and do, supporting it may > allow for helpful middle boxes to give protections even for clients that > don't support it. For example, if a users' home NAT gateway did tcpcrypt > out to any servers in the world then they could gain some protection from > passive pervasive surveillance even for older client software in their home. This is an interesting use case... There are corporations that require all sessions to be logged/decrypted at an edge box they control... Some of these boxes have a private wild card cert that is installed on all client boxes... Now that I think about it, there wouldn't need to be much changed to support the new protocol... It's basicly the same in that they have to intercept the TLS (or other auth layer) do the necessary rewriting, and sign with their private key... I can't think of a reason that it wouldn't work for these boxes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Sun Apr 13 15:17:25 2014 Return-Path: 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 2DA901A024B for ; Sun, 13 Apr 2014 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BBf2LFRB0Yjn for ; Sun, 13 Apr 2014 15:17:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B2A121A0249 for ; Sun, 13 Apr 2014 15:17:21 -0700 (PDT) Received: from [10.156.156.160] (cpe-66-108-141-251.nyc.res.rr.com [66.108.141.251]) by che.mayfirst.org (Postfix) with ESMTPSA id 858D9F986; Sun, 13 Apr 2014 18:17:14 -0400 (EDT) Message-ID: <534B0CEA.3010101@fifthhorseman.net> Date: Sun, 13 Apr 2014 18:17:14 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Andrea Bittau , MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UeExKJdh6K8cOqh5qNBga6fGqAl42oBAp" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/OBfWcdlWHOMWsXBDVufxNHIKjqo Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:17:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UeExKJdh6K8cOqh5qNBga6fGqAl42oBAp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/13/2014 11:56 AM, Andrea Bittau wrote: > * Privacy considerations. Traffic analysis and side-channels are out o= f scope. I'm not sure that all side-channels are out-of-scope. For example, I'd be sad if we came up with a proposal that did not have a clear, strong, plausible, implementable recommendation that the cryptographic operations used in whatever scheme we come up with should be constant-tim= e. Traffic analysis is much harder to defend against in a principled fashion -- i think it might make sense to leave that as out-of-scope for this working group. > Trying to detect users by IP address, port addresses, time, traffic p= atterns > (packet lengths and inter-packet intervals) is something we should no= t require > to defend against. I agree with this. > If, however, two sessions cannot be linked from the information state= d above, they > should not be linkable by the way we encrypt layer-7 data. I'd be ha= ppy to > make that a requirement - namely that any encryption (or metadata add= ed by > tcpcrypt) does not add to a packet's "linkability" to a user or previ= ous > connection (of course we cannot deal with lower layers or traffic ana= lysis as > stated). I like this way of framing the constraints. perhaps something like this could be used in the charter? --dkg --UeExKJdh6K8cOqh5qNBga6fGqAl42oBAp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTSwzqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc0gAP/imR9lTyKbWn7B7XSyXo0jNB GO5VoheBA74kdft6FKbdf2YxPsfl+psnrMXkMOkWxlocDxe+OGRwYdNrVG0I01zc xzhRm5TweK012G0/z2QroY/PSDDKEYWaGkIp6LTZYu2oSnFEVVZmmtRyx+UARXox jfS3Mf5dugg1AaynOnoY9FsJcwuQsXpMgaLu4VD7Yg3Qic8ukhSDESdxpBj3uW5g sGTwchMwMDXSfjz6vgX5Bu6cRjOU6Mwo40hIcM5KuAY5Q1z1T7lnO+Efs0Kcowfk GSl4GS2agMyYrGmGDgTuqIJOlffE8nQhcBR8sDtdH41j7K3MTmbvX+ObYeSlhwMw IQ/880rhXI1kCv7dUmPp/vsvdhYM3xhAXl510ITItdgTYbGksVW/uHGK7IcFJ8rw 1yu4b+y7YEuAKWKFvkh4MwgtVk0u776lZXn8IF57c61mH4/GNDg4S5HkCTotAUNn BKVOsdKHUCJ25JzeIkSQT3epjNij63AkHu2lFf9B3grGuvDGnJobqO7cBLgrS4LE 1UcWU2cLOHuNlYINwBPrQoly6/uRv4m29Y3i8FuBxYW6fXQxHseuDYzL6whIvoTt yXWLAj4YTmvlmeQknfIY+mz7gsUB8/82qBzS8Z1GTE8JMl2ZXaLIXbd6bDeBoKHl hOCz2Hczo2lrQu7we6BY =xIgL -----END PGP SIGNATURE----- --UeExKJdh6K8cOqh5qNBga6fGqAl42oBAp-- From nobody Sun Apr 13 15:26:56 2014 Return-Path: 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 513401A02D5 for ; Sun, 13 Apr 2014 15:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 380daGbtUZBL for ; Sun, 13 Apr 2014 15:26:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 829971A02D4 for ; Sun, 13 Apr 2014 15:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D4191BE56; Sun, 13 Apr 2014 23:26:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYZDTrxI7CzI; Sun, 13 Apr 2014 23:26:45 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.18.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 510B7BE55; Sun, 13 Apr 2014 23:26:45 +0100 (IST) Message-ID: <534B0F16.30604@cs.tcd.ie> Date: Sun, 13 Apr 2014 23:26:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Andrea Bittau , MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534B0CEA.3010101@fifthhorseman.net> In-Reply-To: <534B0CEA.3010101@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/EwmjwYtXWhkkJQ19VbA6dHVP0JY Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:26:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2014 11:17 PM, Daniel Kahn Gillmor wrote: > Traffic analysis is much harder to defend against in a principled > fashion -- i think it might make sense to leave that as > out-of-scope for this working group. I note that the HTTP/2.0 work has included a mechanism for traffic padding. I'm not sure that we (yet) know how to use that well, but its existence might be a good thing as we learn more/better how to counter traffic analysis. I'm not sure if something similar would or would not make sense here but at least considering it probably would make sense as there are presumably many TCP sessions where the packet sizes alone could reveal an awful lot. Of course it could also be that transport folks have looked at this in the past and reached some conclusions already. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTSw8WAAoJEC88hzaAX42i2mUH/3sL14JEJ79fcgOvs0Wi5FRJ vZSQYBbIlMYykitqA4Lo88+htm0212n7y7i9iOpegwZdenTkxRHNvgQlKorYKMk4 sYFCchn+59lRmIZv33tw29grMNcs2bImQWFnWM6ghYzB/ZADxlO3GX+QP2mvjpPY //gGbqrwgb82uwqcPyZI7Cq8MUJptGD0FBbc3esJIvlrc+GesTClmDUpNGMXkLuy iu1Et8Xc6TaQzrLKigvMo0136rFn6BSPWk5RqK+W6xgog5edU4bAz02opNDJ4ykB Ex2FDwjnnkb4crR1VGvbU/CJgpfr124YrQR35BoMUrLOUt1Rgk6Us2KK9DzEo2I= =ht7e -----END PGP SIGNATURE----- From nobody Sun Apr 13 19:43:19 2014 Return-Path: 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 ED7FD1A0309 for ; Sun, 13 Apr 2014 19:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rO19JOaDFPxn for ; Sun, 13 Apr 2014 19:43:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB81A02FE for ; Sun, 13 Apr 2014 19:43:16 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2F05DF986; Sun, 13 Apr 2014 22:43:12 -0400 (EDT) Message-ID: <534B4B40.1000901@fifthhorseman.net> Date: Sun, 13 Apr 2014 22:43:12 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> In-Reply-To: <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NS4LLcsrHqxv45wpDiP0uaQML33xBRTc7" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Z-81IDxyiYfjv-J76wllGFZNwso Cc: tcpcrypt@ietf.org, Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 02:43:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NS4LLcsrHqxv45wpDiP0uaQML33xBRTc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2014 02:50 AM, MARCELO BAGNULO BRAUN wrote: > Daniel Kahn Gillmor dijo: >> Privacy Considerations >> ---------------------- >> >> This charter makes no mention of any privacy considerations as >> first-order concerns. Two immediate considerations spring to mind: >> >> 0) can a passive eavesdropper link two distinct sessions with each >> other using whatever extension information is present in the packets? >> Consider Alice checking her e-mail from a laptop. If the exposed data= >> are not unlinkable, a network observer who watches traffic at the >> mailserver can tell which network locations Alice connects from, at wh= at >> times. >> >> 1) can the server link two subsequent connections from a given client?= >> in some cases, a client will want to provide some proof of continuity >> to a server (e.g. maintaining an authenticated session across a series= >> of TCP connections). In other cases, the client will want to be able = to >> mask the fact that it is the same client to the server (e.g. when >> connecting to widely-used advertising servers, analytics sites, or CDN= s, >> clients that want to avoid leaking their browsing history to the backe= nd >> might prefer to keep these connections unlinkable). What mechanisms >> would such a spec provide to be able to accomodate both cases? >> >> Do we want the group to consider these privacy considerations (i do)? >> if so, should they be included in the charter? >=20 > yes and yes >=20 > do you mind if i ask you to suggest the text you would like to see > included in the charter? sure, i'd probably start with something along the lines that Andrea Bittau recommended. - No extra linkability: when encryption is enabled the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - Client fingerprinting: some clients may want to avoid appearing as the same client when connecting to a remote peer on subsequent occasions. This should either be the default (clients cannot be "fingerprinted" by the server based on shared state) or some mechanism should be available for clients to drop or ignore shared state to avoid being fingerprintable. does this sound reasonable? --dkg --NS4LLcsrHqxv45wpDiP0uaQML33xBRTc7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTS0tAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpceG4P/RftPhgwJXnC0NFf8F9tIoyh bqYK65U2lLHWsaVI1TTHu5n/4PkTjG54pS57VD+mRVzJgLyXfj6Ze5jLxrOuQxhK DzsN8zsrtyG318qzRBsTz1Gvfz8uXcmNtVPxb3fmXIYzScl2lHzIZIFX4xdZ6phH 7XJC8wtK7x32PhfPGKHL7vykcLH5LJE42c5hxXvQ1sj1S1l8QRneeY726J1kyPql tx1zgeBTLuNgtyKf88PbKcXJQkzrx3AanUeHMaXYweo6bud7wdCrHshYEEWYDyuN TBbowSGhUG0RK7UgXXptBXsO6PcGteT5cnPFK8hWp+/xqNSakIQ6zM/666dnYjF+ UkkoHWF1l4e3kCFyj88bVewqz50xfVLKs1ZvZsKeEQUNfW5jlIGUOo0MuU8Ffo0+ fBnYKQkONnEEfyV9F33UkB16FGCIiJzoqyDqJNvsZnhf4TvNSmoVSrqiJi92bMEA vVojEY8b37QsvqxQi6Oumobmk1WJViHIMsRCuenx7dIAISNI/yzBqFlzLPAHAIRN pLc7kX1P/e5ulzPNqGSBDRlv20uQDTgU2zAZQsnYd8zNkqcQ6N9FFgEtxgm/wcDd qYqh6L09270vBCu/wtEmzoX9y5frXoenROdjuNb7jFgrWg/G5cy/zhUk+Nd8YsV6 e6cYUnGXiedsUWxNDGYK =ICdb -----END PGP SIGNATURE----- --NS4LLcsrHqxv45wpDiP0uaQML33xBRTc7-- From nobody Sun Apr 13 22:01:47 2014 Return-Path: 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 AB7E21A0340 for ; Sun, 13 Apr 2014 22:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 djd8E6XVuFgX for ; Sun, 13 Apr 2014 22:01:41 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 718241A0337 for ; Sun, 13 Apr 2014 22:01:41 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3E512hx022921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 22:01:05 -0700 (PDT) Message-ID: <534B6B8F.1050703@isi.edu> Date: Sun, 13 Apr 2014 22:01:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Erik Nygren References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/gYnebh81nMMv_Sv3T-JMikmsZtQ Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:01:46 -0000 On 4/13/2014 10:54 AM, Erik Nygren wrote: > On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch > wrote: > > > You need to MAC the IP dest, dest port, and all signal bits in the > IP header (sequence, flags, etc.). This will still make it through a > NAT, but will break a 'rewriting proxy' - but that's the kind of > attack that TCP crypto ought to protect against, because it's > indistinguishable from a MITM attack (it *is* a MITM). > > Unfortunately, applying a MAC on the IP dest will break NAT64 which is a > valid and increasingly critial use-case. Well, you don't *need* to MAC anything in the header per se, but the less you protect, the more you're not protected. NAT64 is another kind of attack that integrity protection is designed to prevent, but it's always possible to lower the defense level and still end up with "better than nothing". Joe From nobody Sun Apr 13 22:07:03 2014 Return-Path: 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 CF4BB1A0348 for ; Sun, 13 Apr 2014 22:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 76GdRIuyVH4x for ; Sun, 13 Apr 2014 22:06:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2721D1A0346 for ; Sun, 13 Apr 2014 22:06:53 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3E56Lip024296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 22:06:24 -0700 (PDT) Message-ID: <534B6CCE.1030400@isi.edu> Date: Sun, 13 Apr 2014 22:06:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> In-Reply-To: <20140413205031.GK34745@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Zv3OSmV7O7smirIKw6CoEY_WY5A Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:07:01 -0000 On 4/13/2014 1:50 PM, John-Mark Gurney wrote: > Joe Touch wrote this message on Sun, Apr 13, 2014 at 11:10 -0700: >> On 4/13/2014 10:54 AM, Erik Nygren wrote: >>> On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch >> > wrote: >>> >>> >>> You need to MAC the IP dest, dest port, and all signal bits in the >>> IP header (sequence, flags, etc.). This will still make it through a >>> NAT, but will break a 'rewriting proxy' - but that's the kind of >>> attack that TCP crypto ought to protect against, because it's >>> indistinguishable from a MITM attack (it *is* a MITM). >>> >>> Unfortunately, applying a MAC on the IP dest will break NAT64 which is a >>> valid and increasingly critial use-case. >> >> If you avoid MACing any address or port info (except perhaps dest port), >> then all you have left to identify your connection is the ISN pair, and >> that seems a bit dangerous. > > How/Why is that dangerous? It increases the chance of reusing information across connections. It also makes it easier to have an attack that consumes receiver resources. > If it is used w/ an authentication layer that authenticates that the > session hash is the same on both sides, how is this dangerous? The "session hash" would consist of only the session ID info that isn't rewritten; the more you rewrite, the less info is used in that hash - and the weaker it becomes. > The > authentication layer has stated that the session key is known only to > the end points, and not to any MITM. See above. > MAC'ing the IP/port info will prevent 90% of the internet from using > it was most end users are behind NATs... Be it a corrporate nat, or > the nat their ISP provided so that they are only allocated one IP... MAC'ing the dest IP and dest port is weaker than MAC'ing both IP addrs and ports, but stronger than MAC'ing nothing. See TCP-AO NAT traversal mode (RFC 6978); it can be done, but it seems preferable to support just the NAT on one side (source addr/port). Joe From nobody Sun Apr 13 22:09:05 2014 Return-Path: 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 3F61F1A025B for ; Sun, 13 Apr 2014 22:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 oQm9EeFVL6Sc for ; Sun, 13 Apr 2014 22:09:02 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C02791A0346 for ; Sun, 13 Apr 2014 22:09:02 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3E58jfI025041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 22:08:48 -0700 (PDT) Message-ID: <534B6D5E.1000003@isi.edu> Date: Sun, 13 Apr 2014 22:08:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> In-Reply-To: <20140413204202.GJ34745@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/G8vYXOv7sCAk3rqjMx7hihQGfD0 Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:09:04 -0000 On 4/13/2014 1:42 PM, John-Mark Gurney wrote: > Joe Touch wrote this message on Fri, Apr 11, 2014 at 13:37 -0700: >> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: >>> Daniel Kahn Gillmor dijo: >>> >>>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >>>>> TCP anonymous encryption (TAE) >>>> >>>> While the proposed outline does start as anonymous encryption, the >>>> requirement for hooks for higher-level authentication doesn't feel like >>>> anonymous encryption to me. >> >> Or me either; anonymous encryption is useful independent of whether >> higher-level hooks are provided or not. > > I would say w/o the hooks isn't useful... > Because either it will need to provide a knob to turn it off (for SSL > to prevent double encryption), or we'll suffer double encryption, > meaning the layer will be redundant and admins will intentially turn it > off to reduce the load on their boxes, defeating the benifits of always > on encryption... Double encryption happens all over the place - TLS over WPA, e.g. It's not only not bad, it has important utility (protecting E2E connections vs. protecting the link layer). When load is an issue, encryption at every layer is susceptible to being disabled - but we're approaching the point where we eat the cost because we want the benefit. The same happened for VM - we do double-lookups all over the place because it's useful; it's certainly not efficient. Joe From nobody Mon Apr 14 08:10:52 2014 Return-Path: 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 9C3BD1A0515 for ; Mon, 14 Apr 2014 08:10:50 -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 mawRLUr307xa for ; Mon, 14 Apr 2014 08:10:45 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3DB1A0505 for ; Mon, 14 Apr 2014 08:10:44 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 796B1CB1AAB; Mon, 14 Apr 2014 17:10:41 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 1A38AC35C87; Mon, 14 Apr 2014 17:10:40 +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 17:10:40 +0200 Message-ID: <20140414171040.x035ap4lws8kswoo@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 17:10:40 +0200 From: MARCELO BAGNULO BRAUN To: Erik Nygren References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> In-Reply-To: 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 17:10:41 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/jBcYgGqIxoWqHTo5Z5XfGClls5Y Cc: Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:10:50 -0000 below... Erik Nygren dijo: > Thank you for this summary. > > Along the lines of application hooks, do we want a way for the application > layer to be able to safely disable encryption part way through a > connection? For example, tcpcrypt may be a good way of protecting the > initial TLS handshake (eg, protecting parts of it from passive > surveillance) but once the TLS session is established it may be redundant > enough that we may wish to let the applications agree to drop back to > plain-text at the TCP layer. Any negotiation here presumably needs to be > mutual and properly covered by whatever authentication the tcpcrypt > connection has. > i think we should include a requirement that the app layer should be able to request no encrryption i.e. regular TCP. An extended API should allow for this. > > A side-note on NATs: authenticating RSTs could be problematic when a NAT > times out a connection and starts reusing source ports (perhaps for a > different client to the same server), especially if the client and server > on either end using tcpcrypt are unaware of this. There are a bunch of > annoying corner-cases in this area. > Right, i believe there is a tradeoff between how much security you include in the RST and the number of cases the RST actually serves its purpose. I think this tradeoff should be assesed and some design decision need to be taken by the WG > Would we ever want a middle-box (eg, a NAT or transparent proxy) to be able > to opportunistically terminate tcpcrypt on both ends? While this is > something that active attackers will also try and do, supporting it may > allow for helpful middle boxes to give protections even for clients that > don't support it. For example, if a users' home NAT gateway did tcpcrypt > out to any servers in the world then they could gain some protection from > passive pervasive surveillance even for older client software in their home. > I think this is inherent to oportunistic encryption, no? I mean, whithout authentication, the solution is vulnerable to MiTM, hence this would be possible, i believe. Regards, marcelo > Erik > > > > On Sun, Apr 13, 2014 at 11:56 AM, Andrea Bittau > wrote: > >> Here're some comments on points raised (I hope I covered it all): >> >> * Header protection. We probably can't encrypt most of the header without >> breaking NATs but there probably are fields we can MAC without breaking >> NATs >> (e.g., relative sequence numbers). >> >> There could also be a software enabled mode where MACing certain fields >> is >> mandatory - e.g., MACing the RST, enabled maybe on BGP connections. >> >> * "sticky" a la SSH keys. This is an application-layer concern (where >> authentication is performed) - not something to be tackled at the >> transport >> layer. Care must be taken with the forward secrecy requirement and the >> solution must work with load balancers / connecting to different >> backends. >> >> For what it's worth, session caching at the transport layer is a >> temporary, >> poor man's implementation of this - if there was no man-in-the-middle on >> the >> first connection, the subsequent cached connections are safe. >> >> * UDP. The fundamental advantage in TCP is the existing three way >> handshake >> where we can signal whether tcpcrypt is available or not. This gives us >> transparent incremental adoption. In UDP we don't have this. So an >> application layer solution will probably be as good as a transport layer >> solution (both face the same bootstrap problem). Unless you do crazy >> things >> like send the first UDP packet with an invalid but fixed "UDPCrypt" >> checksum >> to signal that you want to start encrypting - but that's a whole >> different >> mess in itself that is out of scope for this effort. >> >> * NATs & Middleboxes. The solution must work with them. The goal should >> be >> that wherever TCP works, tcpcrypt works, too (maybe disabled initially). >> >> * Session caching. I agree that it's not fundamental but rather it's a >> performance optimization. Hey if a scheme that is always fast exists, >> then >> that's good enough. The high level requirement is that it should be fast >> enough that you can turn it on by default. (A session, in practice, is >> a TCP >> connection.) I'm not sure how to avoid public key operations for >> connection >> establishment and that's why we thought session caching should be a >> requirement in practice, as we want to avoid having public key >> operations for >> each connection. >> >> * Privacy considerations. Traffic analysis and side-channels are out of >> scope. >> Trying to detect users by IP address, port addresses, time, traffic >> patterns >> (packet lengths and inter-packet intervals) is something we should not >> require >> to defend against. This is not intended to be a Tor-like solution. If, >> however, two sessions cannot be linked from the information stated >> above, they >> should not be linkable by the way we encrypt layer-7 data. I'd be happy >> to >> make that a requirement - namely that any encryption (or metadata added >> by >> tcpcrypt) does not add to a packet's "linkability" to a user or previous >> connection (of course we cannot deal with lower layers or traffic >> analysis as >> stated). >> >> * Authentication failures & some fail some don't to same host. There's a >> synergy between multipath TCP and tcpcrypt - it's harder to mount attacks >> because the attacker has to be on path on each connection, and it's >> easier to >> detect (and potentially kill) one path that is misbehaving. In any >> event, >> authentication failures are application-specific problems. In a web >> browser >> that supports authentication and mandates it, you'll probably get a red >> screen >> with a certificate failure. An e-mail client will probably pop-up a >> dialog >> saying unable to connect / verify server identity. The default, where >> there >> is no authentication and the application is tcpcrypt-unaware, means that >> the >> connection will always succeed and that the user will not even be aware >> that >> the connection is encrypted (or not). Nothing changes from the app's and >> user's perspective. There's only the added bonus of encryption if no >> man-in-the-middle is present. >> >> * Exposing hooks for authentication (e.g., Session ID). We do not require >> authentication, so exposing a hook for it does not provide any harm in >> my mind >> as it can simply be ignored by all. If anything, exposing the hook will >> make >> the protocol more future proof. For example, it can avoid double >> encryption - >> the application has a way of verifying that the layer-4 encryption is >> safe and >> does not need to redo its own encryption, but rather it merely includes >> the >> Session ID in its (possibly already existing) authentication. Plus, >> after >> doing all the hard work of setting up an encrypted channel, it seems >> reasonable to take the extra step to expose a simple hash which can be >> used to >> greatly improve the security guarantees provided. We don't want to >> limit our >> security guarantees by design. >> >> >> On Sun, Apr 13, 2014 at 12:09 AM, MARCELO BAGNULO BRAUN >> wrote: >> > Joe Touch dijo: >> > >> >> >> >> >> >> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: >> >>> >> >>> Daniel Kahn Gillmor dijo: >> >>> >> >>>> On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >> >>>>> >> >>>>> TCP anonymous encryption (TAE) >> >>>> >> >>>> >> >>>> While the proposed outline does start as anonymous encryption, the >> >>>> requirement for hooks for higher-level authentication doesn't feel >> like >> >>>> anonymous encryption to me. >> >> >> >> >> >> Or me either; anonymous encryption is useful independent of whether >> >> higher-level hooks are provided or not. >> >> >> >> (IMO that was a mistake made when BTNS was being worked; the original >> >> concept of AE was IMO warped into necessarily including channel binding >> and >> >> connection latching, which severely limits the benefit of AE --- CB/CL >> just >> >> move the need for key distribution to a different layer, whereas true >> AE can >> >> avoid it with lesser benefit). >> >> >> >>> we should wait for saag to finish their discussion or if you have a >> >>> better name suggestion, please go ahead >> >> >> >> >> >> SAAG is trying to redefine widely-cited terminology; that seems like a >> bad >> >> idea. >> >> >> >> Further, there's a difference between anonymous and 'keyless'. Anonymous >> >> implies lack of traceability, which is harder to prove. >> >> >> >> Most of the time I've seen "anonymous" it means "keyless", as in >> unsigned >> >> Diffie-Hellman. >> >> >> >> On the SAAG list, I offered a few alternatives (all of which were >> >> dismissed, of course), depending on what's being described: >> >> >> >> zero-key >> >> >> >> zero-ID >> >> >> >> These play off of "zero-configuration" and "zero-touch" network >> >> management, and IMO still might be useful if you're interested in a >> >> descriptive term (rather than trying to redefine a long-cited one). >> >> >> >> ... >> >>> >> >>> I guess as you say, that doesnt make sense to aim to protect the >> >>> addresses and port fields, as it would be incompatible with nats. >> >> >> >> >> >> FWIW, that has its merits (NATs are an attack that some security >> protocols >> >> are designed to protect against). >> >> >> >> TCP-AO isn't compatible with NATs, but there is an extension that is, >> >> FWIW. >> >> >> >>> One discussion is whether we aim to protect the seq number and the ack >> >>> number. This wouldnt break with nats but with other middle boxes. >> >> >> >> >> >> There is no way to protect the signalling part of TCP and be compatible >> >> with rewriting NATs; IMO such compatibility should be out of scope. >> >> >> >>> This is also related with where to carry the crypto information (like >> >>> the hmac for the payload). If we want to protect some of the tcp header >> >>> fields, then we should carry the hmac in tcp options, as it becomes >> >>> harder to send the hmac in the payload, as ack many times dont carry >> >>> data, so you may end up consumin seq number space when sending empty >> >>> acks... so in a nutshell, this seems like a long discussion that is >> >>> central to the solution design, that is why we propose to have it once >> >>> the wg is formed, makes sense? >> >> >> >> >> >> That's why TCP-AO has its HMAC as a header option. >> >> >> >> FWIW, I also posted a way to use TCP-AO for encryption. >> >> >> >> Joe >> >> >> >> _______________________________________________ >> >> Tcpcrypt mailing list >> >> Tcpcrypt@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> >> >> > >> > >> > >> > -- >> > ---- >> > MARCELO BAGNULO BRAUN >> > WebCartero >> > Universidad Carlos III de Madrid >> > >> > _______________________________________________ >> > Tcpcrypt mailing list >> > Tcpcrypt@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpcrypt >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 08:13:18 2014 Return-Path: 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 D020C1A04A3 for ; Mon, 14 Apr 2014 08:13:16 -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 2RPtBuqXnVev for ; Mon, 14 Apr 2014 08:13:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FB1A049C for ; Mon, 14 Apr 2014 08:13:12 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D1C176B36B for ; Mon, 14 Apr 2014 17:13:09 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 71720766B01 for ; Mon, 14 Apr 2014 17:13:09 +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 17:13:09 +0200 Message-ID: <20140414171309.wbovftkckkcggs04@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 17:13:09 +0200 From: MARCELO BAGNULO BRAUN To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> In-Reply-To: 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 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 14 Apr 2014 17:13:09 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 X-TM-AS-Result: No--6.341-7.0-31-1 X-imss-scan-details: No--6.341-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ZGrDW1RTKcpD7gjaCuAsQOdCONk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:13:17 -0000 Tony Arcieri dijo: > On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun > wrote: > >> TCP anonymous encryption (TAE) >> >> Anonymous encryption is an anonymous key exchange resulting in encryption >> without authentication > > > Will this idea be compatible with future authentication systems, i.e. could > some mechanism verify public keys for you, then hand off the rest of the > session to tcpcrypt? > yes, this is expressed in the proposed charter text as hooks for upper layer authentication, makes sense? regards, marcelo > -- > Tony Arcieri > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 08:17:32 2014 Return-Path: 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 50ACA1A02CF for ; Mon, 14 Apr 2014 08:17:31 -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 MDty26UoL-Rq for ; Mon, 14 Apr 2014 08:17:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id A12781A0466 for ; Mon, 14 Apr 2014 08:17:25 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 59F7D766B01 for ; Mon, 14 Apr 2014 17:17:22 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 4C9968721A1 for ; Mon, 14 Apr 2014 17:17:22 +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 17:17:22 +0200 Message-ID: <20140414171722.2sr1vqpw088ksg8s@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 17:17:22 +0200 From: MARCELO BAGNULO BRAUN To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> In-Reply-To: <20140413204202.GJ34745@funkthat.com> 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 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 14 Apr 2014 17:17:22 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 X-TM-AS-Result: No--16.100-7.0-31-1 X-imss-scan-details: No--16.100-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/w2jOJgvRPf71mevPfFnjWUeKguM 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:17:31 -0000 below.. John-Mark Gurney dijo: > Joe Touch wrote this message on Fri, Apr 11, 2014 at 13:37 -0700: >> On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: >> >Daniel Kahn Gillmor dijo: >> > >> >>On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: >> >>>TCP anonymous encryption (TAE) >> >> >> >>While the proposed outline does start as anonymous encryption, the >> >>requirement for hooks for higher-level authentication doesn't feel like >> >>anonymous encryption to me. >> >> Or me either; anonymous encryption is useful independent of whether >> higher-level hooks are provided or not. > > I would say w/o the hooks isn't useful... > Because either it will need to provide a knob to turn it off (for SSL > to prevent double encryption), or we'll suffer double encryption, > meaning the layer will be redundant and admins will intentially turn it > off to reduce the load on their boxes, defeating the benifits of always > on encryption... > I think the solution should work with unmodified apps, so the extended API should be an optimization for apps that support it. There are ways to avoid double encryption even witout the extended API (if TLS is being used, dont encrypt), which should be good enough overall, i think the extended API for both disabling encryption and for the authentication hooks are important, but the solution should be able to work when these are not used. makes sense? regards, marcelo > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 08:19:21 2014 Return-Path: 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 661CF1A04AB for ; Mon, 14 Apr 2014 08:19:20 -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 les7NXCJ18W1 for ; Mon, 14 Apr 2014 08:19:16 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 228481A049E for ; Mon, 14 Apr 2014 08:19:16 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3539CCD691F; Mon, 14 Apr 2014 17:19:13 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id B7FA7C35A87; Mon, 14 Apr 2014 17:19:12 +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 17:19:12 +0200 Message-ID: <20140414171912.q8ru60ujkgcwgc88@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 17:19:12 +0200 From: MARCELO BAGNULO BRAUN To: Daniel Kahn Gillmor References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534B0CEA.3010101@fifthhorseman.net> In-Reply-To: <534B0CEA.3010101@fifthhorseman.net> 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 17:19:13 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Xpr8M_M_E1eX97rCz0HnD5PzO9k Cc: Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:19:20 -0000 Daniel Kahn Gillmor dijo: > On 04/13/2014 11:56 AM, Andrea Bittau wrote: >> * Privacy considerations. Traffic analysis and side-channels are >> out of scope. > > I'm not sure that all side-channels are out-of-scope. For example, I'd > be sad if we came up with a proposal that did not have a clear, strong, > plausible, implementable recommendation that the cryptographic > operations used in whatever scheme we come up with should be constant-time. > > Traffic analysis is much harder to defend against in a principled > fashion -- i think it might make sense to leave that as out-of-scope for > this working group. > >> Trying to detect users by IP address, port addresses, time, >> traffic patterns >> (packet lengths and inter-packet intervals) is something we should >> not require >> to defend against. > > I agree with this. > >> If, however, two sessions cannot be linked from the information >> stated above, they >> should not be linkable by the way we encrypt layer-7 data. I'd be >> happy to >> make that a requirement - namely that any encryption (or metadata added by >> tcpcrypt) does not add to a packet's "linkability" to a user or previous >> connection (of course we cannot deal with lower layers or traffic >> analysis as >> stated). > > I like this way of framing the constraints. perhaps something like this > could be used in the charter? yes, this makes sense Regards, marcelo > > --dkg > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 08:21:02 2014 Return-Path: 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 E862F1A04B7 for ; Mon, 14 Apr 2014 08:20:57 -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 tcqBpPCQU4c0 for ; Mon, 14 Apr 2014 08:20:53 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id EC5D21A04B1 for ; Mon, 14 Apr 2014 08:20:52 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E87989D337C; Mon, 14 Apr 2014 17:20:49 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id A0B7511C1958; Mon, 14 Apr 2014 17:20:48 +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 17:20:48 +0200 Message-ID: <20140414172048.kgedo0agsg80ws0w@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 17:20:48 +0200 From: MARCELO BAGNULO BRAUN To: Daniel Kahn Gillmor References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <534B4B40.1000901@fifthhorseman.net> In-Reply-To: <534B4B40.1000901@fifthhorseman.net> 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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 14 Apr 2014 17:20:49 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 X-TM-AS-Result: No--17.472-7.0-31-1 X-imss-scan-details: No--17.472-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aBuqJXcqhVFJscW4bgjdR5WdSdw Cc: tcpcrypt@ietf.org, Andrea Bittau , David Mazieres expires 2014-04-06 PDT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:20:58 -0000 Thanks, will use these and Andrea's text in the next version of the charter Daniel Kahn Gillmor dijo: > On 04/10/2014 02:50 AM, MARCELO BAGNULO BRAUN wrote: >> Daniel Kahn Gillmor dijo: > >>> Privacy Considerations >>> ---------------------- >>> >>> This charter makes no mention of any privacy considerations as >>> first-order concerns. Two immediate considerations spring to mind: >>> >>> 0) can a passive eavesdropper link two distinct sessions with each >>> other using whatever extension information is present in the packets? >>> Consider Alice checking her e-mail from a laptop. If the exposed data >>> are not unlinkable, a network observer who watches traffic at the >>> mailserver can tell which network locations Alice connects from, at what >>> times. >>> >>> 1) can the server link two subsequent connections from a given client? >>> in some cases, a client will want to provide some proof of continuity >>> to a server (e.g. maintaining an authenticated session across a series >>> of TCP connections). In other cases, the client will want to be able to >>> mask the fact that it is the same client to the server (e.g. when >>> connecting to widely-used advertising servers, analytics sites, or CDNs, >>> clients that want to avoid leaking their browsing history to the backend >>> might prefer to keep these connections unlinkable). What mechanisms >>> would such a spec provide to be able to accomodate both cases? >>> >>> Do we want the group to consider these privacy considerations (i do)? >>> if so, should they be included in the charter? >> >> yes and yes >> >> do you mind if i ask you to suggest the text you would like to see >> included in the charter? > > sure, i'd probably start with something along the lines that Andrea > Bittau recommended. > > > - No extra linkability: when encryption is enabled the TCP traffic > should not give a third party observer any extra way to associate those > packets with the specific peers beyond information that would have been > present in a cleartext session. > > - Client fingerprinting: some clients may want to avoid appearing as > the same client when connecting to a remote peer on subsequent > occasions. This should either be the default (clients cannot be > "fingerprinted" by the server based on shared state) or some mechanism > should be available for clients to drop or ignore shared state to avoid > being fingerprintable. > > does this sound reasonable? > > --dkg > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 08:26:59 2014 Return-Path: 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 57DA21A02CF for ; Mon, 14 Apr 2014 08:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 dDQ4b3tbvb5y for ; Mon, 14 Apr 2014 08:26:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBC1A01A6 for ; Mon, 14 Apr 2014 08:26:54 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EFQVPg025391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 08:26:34 -0700 (PDT) Message-ID: <534BFE28.1080408@isi.edu> Date: Mon, 14 Apr 2014 08:26:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <20140414171309.wbovftkckkcggs04@webcartero01.uc3m.es> In-Reply-To: <20140414171309.wbovftkckkcggs04@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/b4DHGKLnFFWaYijALRI_yXj6GK8 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:26:58 -0000 On 4/14/2014 8:13 AM, MARCELO BAGNULO BRAUN wrote: > Tony Arcieri dijo: > >> On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun >> wrote: >> >>> TCP anonymous encryption (TAE) >>> >>> Anonymous encryption is an anonymous key exchange resulting in >>> encryption >>> without authentication >> >> >> Will this idea be compatible with future authentication systems, i.e. >> could >> some mechanism verify public keys for you, then hand off the rest of the >> session to tcpcrypt? >> > > yes, this is expressed in the proposed charter text as hooks for upper > layer authentication, makes sense? Hooks for out-of-band authentication is useful; hooks that are described as tying layers together are problematic - they could be interpreted as "channel binding", a method that can render the lower-level mechanism useless if absent (and thus disabling a useful mode). Joe From nobody Mon Apr 14 09:25:40 2014 Return-Path: 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 C7D061A0572 for ; Mon, 14 Apr 2014 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 qAL5lFEp5bNJ for ; Mon, 14 Apr 2014 09:25:32 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFED1A04C1 for ; Mon, 14 Apr 2014 09:25:32 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EGPREg043588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 09:25:28 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EGPRZI043587; Mon, 14 Apr 2014 09:25:27 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 09:25:27 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414162526.GV34745@funkthat.com> References: <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> <534B6CCE.1030400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534B6CCE.1030400@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 09:25:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5ABm2S2bZsAJJvbe11Tph8qJF_g Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:25:36 -0000 Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:06 -0700: > On 4/13/2014 1:50 PM, John-Mark Gurney wrote: > >Joe Touch wrote this message on Sun, Apr 13, 2014 at 11:10 -0700: > >>On 4/13/2014 10:54 AM, Erik Nygren wrote: > >>>On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch >>>> wrote: > >>> > >>> > >>> You need to MAC the IP dest, dest port, and all signal bits in the > >>> IP header (sequence, flags, etc.). This will still make it through a > >>> NAT, but will break a 'rewriting proxy' - but that's the kind of > >>> attack that TCP crypto ought to protect against, because it's > >>> indistinguishable from a MITM attack (it *is* a MITM). > >>> > >>>Unfortunately, applying a MAC on the IP dest will break NAT64 which is a > >>>valid and increasingly critial use-case. > >> > >>If you avoid MACing any address or port info (except perhaps dest port), > >>then all you have left to identify your connection is the ISN pair, and > >>that seems a bit dangerous. > > > >How/Why is that dangerous? > > It increases the chance of reusing information across connections. It > also makes it easier to have an attack that consumes receiver resources. > > >If it is used w/ an authentication layer that authenticates that the > >session hash is the same on both sides, how is this dangerous? > > The "session hash" would consist of only the session ID info that isn't > rewritten; the more you rewrite, the less info is used in that hash - > and the weaker it becomes. Except that each connection has an effermerial key associated w/ it that is guaranteed to be unique, and integrated into the sessions hash, so there can't be any mixing of packets between sessions on different ports or IPs... And it consumes no more resources than sending random data to session forcing the receiver to validate the MAC and when invalid, throw the data away... Remeber, we are looking at something more interesting than basic preset shared secrets between hosts which would be suseptible to the attacks you describe... > >The > >authentication layer has stated that the session key is known only to > >the end points, and not to any MITM. > > See above. > > >MAC'ing the IP/port info will prevent 90% of the internet from using > >it was most end users are behind NATs... Be it a corrporate nat, or > >the nat their ISP provided so that they are only allocated one IP... > > MAC'ing the dest IP and dest port is weaker than MAC'ing both IP addrs > and ports, but stronger than MAC'ing nothing. > > See TCP-AO NAT traversal mode (RFC 6978); it can be done, but it seems > preferable to support just the NAT on one side (source addr/port). Just read it... All it does it sets flags to tell it to zero the respective IP/port... i.e. the same as not MAC'ing them... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 09:32:40 2014 Return-Path: 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 D97D91A065B for ; Mon, 14 Apr 2014 09:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 e3FyVtvwtx-0 for ; Mon, 14 Apr 2014 09:32:34 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF57D1A065E for ; Mon, 14 Apr 2014 09:32:27 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EGWMki043682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 09:32:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EGWMxJ043681; Mon, 14 Apr 2014 09:32:22 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 09:32:22 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414163222.GW34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534B6D5E.1000003@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 09:32:23 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ghUixxrtzYB_1NrJSeUp9_siVBo Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:32:36 -0000 Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:08 -0700: > On 4/13/2014 1:42 PM, John-Mark Gurney wrote: > >Joe Touch wrote this message on Fri, Apr 11, 2014 at 13:37 -0700: > >>On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote: > >>>Daniel Kahn Gillmor dijo: > >>> > >>>>On 04/02/2014 11:59 AM, marcelo bagnulo braun wrote: > >>>>>TCP anonymous encryption (TAE) > >>>> > >>>>While the proposed outline does start as anonymous encryption, the > >>>>requirement for hooks for higher-level authentication doesn't feel like > >>>>anonymous encryption to me. > >> > >>Or me either; anonymous encryption is useful independent of whether > >>higher-level hooks are provided or not. > > > >I would say w/o the hooks isn't useful... > >Because either it will need to provide a knob to turn it off (for SSL > >to prevent double encryption), or we'll suffer double encryption, > >meaning the layer will be redundant and admins will intentially turn it > >off to reduce the load on their boxes, defeating the benifits of always > >on encryption... > > Double encryption happens all over the place - TLS over WPA, e.g. > > It's not only not bad, it has important utility (protecting E2E > connections vs. protecting the link layer). I agree that link layer encryption has it's uses.... since this is only dealing w/ TCP, UDP, ICMP and other protocols still need to be protected via things like WPA.... > When load is an issue, encryption at every layer is susceptible to being > disabled - but we're approaching the point where we eat the cost because > we want the benefit. The same happened for VM - we do double-lookups all > over the place because it's useful; it's certainly not efficient. Except that TLS + tcpcrypt is double encryption at the same layer... Most wifi encryption is now done by hardware, so doesn't have a significant impact on CPU usage, though TLS + tcpcrypt will usually be done by the CPU... Even a fast modern CPU not using dedicated instructions can only do ~150MB/sec for AES-GCM... Using double encryption means immedately half that performance... That's a pretty steep price to pay... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 09:45:17 2014 Return-Path: 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 90C491A0522 for ; Mon, 14 Apr 2014 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 4kZuZ5jQKe4f for ; Mon, 14 Apr 2014 09:45:13 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 657F21A02CF for ; Mon, 14 Apr 2014 09:45:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EGiOIo020801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 09:44:30 -0700 (PDT) Message-ID: <534C106A.1010504@isi.edu> Date: Mon, 14 Apr 2014 09:44:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> <534B6CCE.1030400@isi.edu> <20140414162526.GV34745@funkthat.com> In-Reply-To: <20140414162526.GV34745@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ClaI5XPYU4m2ZL64y9Sz6I3jUao Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:45:15 -0000 On 4/14/2014 9:25 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:06 -0700: >> On 4/13/2014 1:50 PM, John-Mark Gurney wrote: >>> Joe Touch wrote this message on Sun, Apr 13, 2014 at 11:10 -0700: >>>> On 4/13/2014 10:54 AM, Erik Nygren wrote: >>>>> On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch >>>> > wrote: >>>>> >>>>> >>>>> You need to MAC the IP dest, dest port, and all signal bits in the >>>>> IP header (sequence, flags, etc.). This will still make it through a >>>>> NAT, but will break a 'rewriting proxy' - but that's the kind of >>>>> attack that TCP crypto ought to protect against, because it's >>>>> indistinguishable from a MITM attack (it *is* a MITM). >>>>> >>>>> Unfortunately, applying a MAC on the IP dest will break NAT64 which is a >>>>> valid and increasingly critial use-case. >>>> >>>> If you avoid MACing any address or port info (except perhaps dest port), >>>> then all you have left to identify your connection is the ISN pair, and >>>> that seems a bit dangerous. >>> >>> How/Why is that dangerous? >> >> It increases the chance of reusing information across connections. It >> also makes it easier to have an attack that consumes receiver resources. >> >>> If it is used w/ an authentication layer that authenticates that the >>> session hash is the same on both sides, how is this dangerous? >> >> The "session hash" would consist of only the session ID info that isn't >> rewritten; the more you rewrite, the less info is used in that hash - >> and the weaker it becomes. > > Except that each connection has an effermerial key associated w/ > it that is guaranteed to be unique, and integrated into the sessions > hash, so there can't be any mixing of packets between sessions on > different ports or IPs... And it consumes no more resources than sending > random data to session forcing the receiver to validate the MAC and > when invalid, throw the data away... You're assuming a unique ephemeral key per connection - how did you get that? Both ends have to use the same info, so you're basing it solely on the ISNs if all the address and port info can change. That's a lot weaker - and susceptible to collision on different connections - that using at least some address and port info. > Remeber, we are looking at something more interesting than basic > preset shared secrets between hosts which would be suseptible to the > attacks you describe... See TCP-AO; I am too. >>> The >>> authentication layer has stated that the session key is known only to >>> the end points, and not to any MITM. >> >> See above. >> >>> MAC'ing the IP/port info will prevent 90% of the internet from using >>> it was most end users are behind NATs... Be it a corrporate nat, or >>> the nat their ISP provided so that they are only allocated one IP... >> >> MAC'ing the dest IP and dest port is weaker than MAC'ing both IP addrs >> and ports, but stronger than MAC'ing nothing. >> >> See TCP-AO NAT traversal mode (RFC 6978); it can be done, but it seems >> preferable to support just the NAT on one side (source addr/port). > > Just read it... All it does it sets flags to tell it to zero the > respective IP/port... i.e. the same as not MAC'ing them... I gave it as an example that does support NAT, but recommends against zeroing the IP/port on both sides. Note too that zeroing values gives a different MAC value than not MACing them (i.e., you have to be specific in how values are excluded to ensure endpoint compatibility). Joe From nobody Mon Apr 14 09:51:41 2014 Return-Path: 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 27D051A065D for ; Mon, 14 Apr 2014 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 3JHSfhltekrx for ; Mon, 14 Apr 2014 09:51:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 200101A0656 for ; Mon, 14 Apr 2014 09:51:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EGowxg022826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 09:50:58 -0700 (PDT) Message-ID: <534C11F2.3030607@isi.edu> Date: Mon, 14 Apr 2014 09:50:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> In-Reply-To: <20140414163222.GW34745@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/g_o-clNBS8DlJ_HObbtFl31JegU Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:51:38 -0000 On 4/14/2014 9:32 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:08 -0700: ... >> Double encryption happens all over the place - TLS over WPA, e.g. >> >> It's not only not bad, it has important utility (protecting E2E >> connections vs. protecting the link layer). > > I agree that link layer encryption has it's uses.... since this is > only dealing w/ TCP, UDP, ICMP and other protocols still need to be > protected via things like WPA.... > >> When load is an issue, encryption at every layer is susceptible to being >> disabled - but we're approaching the point where we eat the cost because >> we want the benefit. The same happened for VM - we do double-lookups all >> over the place because it's useful; it's certainly not efficient. > > Except that TLS + tcpcrypt is double encryption at the same layer... TLS encrypts the payload - it's "application" layer, at least as far as TCP is concerned (just because it's named "transport layer" doesn't make it so). A TCP crypto solution would necessarily need to protect TCP's signalling protocol, i.e., (at a minimum) the sequence numbers and flags. > Most wifi encryption is now done by hardware, so doesn't have a > significant impact on CPU usage, though TLS + tcpcrypt will usually be > done by the CPU... Hardware support for encryption exists at various layers; TLS and SSL hardware accelerators have been common for many years (I have some that are over 10 years old in my lab). > Even a fast modern CPU not using dedicated > instructions can only do ~150MB/sec for AES-GCM... Using double > encryption means immedately half that performance... Sure. Until we figure out that we didn't really need TLS if we protect TCP. > That's a pretty steep price to pay... That's what people said about double-lookup for VM 30 years ago, about 20 bytes for an IP header 20 years ago, and about TCP 10 years ago. It's all relative to what you want. Let's not please engineer a long-term solution based on ephemeral concerns. Joe From nobody Mon Apr 14 09:59:11 2014 Return-Path: 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 AC3951A04D2 for ; Mon, 14 Apr 2014 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 0K67Pki7urRL for ; Mon, 14 Apr 2014 09:59:04 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D9E6E1A03D7 for ; Mon, 14 Apr 2014 09:59:03 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so7613654vcb.5 for ; Mon, 14 Apr 2014 09:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=chsfgvDkVxJzWHvp/lB9zd+Zr95tLNzt7ywCDrZsrwA=; b=E30hNFoVUGgKkeWvkma+rou1ssjGUmYECBBWOouA7GWVR1KIqNT4tQbPfur681l3qj kmrlbfJYvLp4VeqBVhpwHJRND0opZuxEg0wJ6Y3v9wtOor/roM59xLcU+7SVMwK/TyJD heviFTCeSR3UrigEGUyziT+ZgZUWqy6jg+YlfI1asoIscdDDLySWNodmcouXmUn651p2 nUY8SZ1Kii5J9NgxCvFYL6q0hnsi67BpW+hnql87iCQEWKDNY3s1amXIQcaNrCh0uSLY zfiEwlGVMTTwBJfWYUNf7pmvFpdq2saHuEwFEJIp56lTOWRa5Ho49X7TH8YpiH4kxgF1 mGXA== X-Received: by 10.52.142.10 with SMTP id rs10mr31470603vdb.3.1397494741144; Mon, 14 Apr 2014 09:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Mon, 14 Apr 2014 09:58:41 -0700 (PDT) In-Reply-To: <20140414163222.GW34745@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> From: Tony Arcieri Date: Mon, 14 Apr 2014 09:58:41 -0700 Message-ID: To: John-Mark Gurney Content-Type: multipart/alternative; boundary=bcaec51a71909f1e2c04f70399b8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/-VFCp7SsiRNXmY5PLmGtqCb4Pn0 Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor , Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:59:08 -0000 --bcaec51a71909f1e2c04f70399b8 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 14, 2014 at 9:32 AM, John-Mark Gurney wrote: > Even a fast modern CPU not using dedicated > instructions can only do ~150MB/sec for AES-GCM Most modern CPUs have some sort of native acceleration like AES-NI. If I run openssl speed -evp aes-128-gcm I get ~1.33GB/s -- Tony Arcieri --bcaec51a71909f1e2c04f70399b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 14, 2014 at 9:32 AM, John-Mark Gurney <jmg@funkthat.com> wrote:
Even a fast modern CPU not using dedicated
instructions can only do ~150MB/sec for AES-GCM

=
Most modern CPUs have some sort of native acceleration like AES-NI. If= I run openssl speed -evp aes-128-gcm I get ~1.33GB/s

--
Tony Arcieri
--bcaec51a71909f1e2c04f70399b8-- From nobody Mon Apr 14 10:26:53 2014 Return-Path: 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 4F8D21A06AF for ; Mon, 14 Apr 2014 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 NtmbZ4jOWXf0 for ; Mon, 14 Apr 2014 10:26:45 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 00A501A069A for ; Mon, 14 Apr 2014 10:26:44 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EHQfP5044698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 10:26:41 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EHQevG044697; Mon, 14 Apr 2014 10:26:40 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 10:26:40 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414172640.GB43976@funkthat.com> References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> <534B6CCE.1030400@isi.edu> <20140414162526.GV34745@funkthat.com> <534C106A.1010504@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C106A.1010504@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 10:26:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/I64ELypBQ-F4HYAQlBVk_XfFFcw Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:26:51 -0000 Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:44 -0700: > On 4/14/2014 9:25 AM, John-Mark Gurney wrote: > >Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:06 -0700: > >>On 4/13/2014 1:50 PM, John-Mark Gurney wrote: > >>>Joe Touch wrote this message on Sun, Apr 13, 2014 at 11:10 -0700: > >>>>On 4/13/2014 10:54 AM, Erik Nygren wrote: > >>>>>On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch >>>>>> wrote: > >>>>> > >>>>> > >>>>> You need to MAC the IP dest, dest port, and all signal bits in the > >>>>> IP header (sequence, flags, etc.). This will still make it through > >>>>> a > >>>>> NAT, but will break a 'rewriting proxy' - but that's the kind of > >>>>> attack that TCP crypto ought to protect against, because it's > >>>>> indistinguishable from a MITM attack (it *is* a MITM). > >>>>> > >>>>>Unfortunately, applying a MAC on the IP dest will break NAT64 which is > >>>>>a > >>>>>valid and increasingly critial use-case. > >>>> > >>>>If you avoid MACing any address or port info (except perhaps dest port), > >>>>then all you have left to identify your connection is the ISN pair, and > >>>>that seems a bit dangerous. > >>> > >>>How/Why is that dangerous? > >> > >>It increases the chance of reusing information across connections. It > >>also makes it easier to have an attack that consumes receiver resources. > >> > >>>If it is used w/ an authentication layer that authenticates that the > >>>session hash is the same on both sides, how is this dangerous? > >> > >>The "session hash" would consist of only the session ID info that isn't > >>rewritten; the more you rewrite, the less info is used in that hash - > >>and the weaker it becomes. > > > >Except that each connection has an effermerial key associated w/ > >it that is guaranteed to be unique, and integrated into the sessions > >hash, so there can't be any mixing of packets between sessions on > >different ports or IPs... And it consumes no more resources than sending > >random data to session forcing the receiver to validate the MAC and > >when invalid, throw the data away... > > You're assuming a unique ephemeral key per connection - how did you get > that? Both ends have to use the same info, so you're basing it solely on > the ISNs if all the address and port info can change. That's a lot > weaker - and susceptible to collision on different connections - that > using at least some address and port info. Because I'm assuming that the basic architecture of tcpcrypt will be used... If we aren't using tcpcrypt as a basis for this w/ minor modifications, then I will stop participating because all of the work that Bittau, Hamburg, Handley, Mazie`res and Boneh did on tcpcrypt will be wasted, and we'll spend another coupld years reinventing what they already did... > >Remeber, we are looking at something more interesting than basic > >preset shared secrets between hosts which would be suseptible to the > >attacks you describe... > > See TCP-AO; I am too. I'm not, and that is our disconnect... > >>>The > >>>authentication layer has stated that the session key is known only to > >>>the end points, and not to any MITM. > >> > >>See above. > >> > >>>MAC'ing the IP/port info will prevent 90% of the internet from using > >>>it was most end users are behind NATs... Be it a corrporate nat, or > >>>the nat their ISP provided so that they are only allocated one IP... > >> > >>MAC'ing the dest IP and dest port is weaker than MAC'ing both IP addrs > >>and ports, but stronger than MAC'ing nothing. > >> > >>See TCP-AO NAT traversal mode (RFC 6978); it can be done, but it seems > >>preferable to support just the NAT on one side (source addr/port). > > > >Just read it... All it does it sets flags to tell it to zero the > >respective IP/port... i.e. the same as not MAC'ing them... > > I gave it as an example that does support NAT, but recommends against > zeroing the IP/port on both sides. > > Note too that zeroing values gives a different MAC value than not MACing > them (i.e., you have to be specific in how values are excluded to ensure > endpoint compatibility). -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 10:33:34 2014 Return-Path: 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 5C3591A06C5 for ; Mon, 14 Apr 2014 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 bjTqQjQ2Y8QZ for ; Mon, 14 Apr 2014 10:33:31 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 488911A06C1 for ; Mon, 14 Apr 2014 10:33:31 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EHXAPi007140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 10:33:10 -0700 (PDT) Message-ID: <534C1BD6.1030609@isi.edu> Date: Mon, 14 Apr 2014 10:33:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <534AD30D.1040301@isi.edu> <20140413205031.GK34745@funkthat.com> <534B6CCE.1030400@isi.edu> <20140414162526.GV34745@funkthat.com> <534C106A.1010504@isi.edu> <20140414172640.GB43976@funkthat.com> In-Reply-To: <20140414172640.GB43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/jQFdB-i1X-T5cFsomEU0TnjH5_o Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:33:32 -0000 On 4/14/2014 10:26 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:44 -0700: ... >> You're assuming a unique ephemeral key per connection ... > > Because I'm assuming that the basic architecture of tcpcrypt will be > used... That is an error in the naming of this group. I already spoke with Martin about this issue, and he claimed that the name was an artifact, not intended to focus on a particular solution. Martin might want to weigh-in on this. Joe From nobody Mon Apr 14 10:34:16 2014 Return-Path: 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 6CABC1A06CF for ; Mon, 14 Apr 2014 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Pp29Q6IVukvt for ; Mon, 14 Apr 2014 10:34:12 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 023261A06CC for ; Mon, 14 Apr 2014 10:34:11 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EHY7nS044819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 10:34:07 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EHY79c044818; Mon, 14 Apr 2014 10:34:07 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 10:34:07 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414173407.GC43976@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C11F2.3030607@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 10:34:07 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/J0jsrTJZnCZkLUeWrle4YcXgPvI Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:34:13 -0000 Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:50 -0700: > On 4/14/2014 9:32 AM, John-Mark Gurney wrote: > >Joe Touch wrote this message on Sun, Apr 13, 2014 at 22:08 -0700: > ... > >>Double encryption happens all over the place - TLS over WPA, e.g. > >> > >>It's not only not bad, it has important utility (protecting E2E > >>connections vs. protecting the link layer). > > > >I agree that link layer encryption has it's uses.... since this is > >only dealing w/ TCP, UDP, ICMP and other protocols still need to be > >protected via things like WPA.... > > > >>When load is an issue, encryption at every layer is susceptible to being > >>disabled - but we're approaching the point where we eat the cost because > >>we want the benefit. The same happened for VM - we do double-lookups all > >>over the place because it's useful; it's certainly not efficient. > > > >Except that TLS + tcpcrypt is double encryption at the same layer... > > TLS encrypts the payload - it's "application" layer, at least as far as > TCP is concerned (just because it's named "transport layer" doesn't make > it so). I consider TLS a transport layer as it provides pipes, it just happens to be implemented in the application layer... > A TCP crypto solution would necessarily need to protect TCP's signalling > protocol, i.e., (at a minimum) the sequence numbers and flags. > > >Most wifi encryption is now done by hardware, so doesn't have a > >significant impact on CPU usage, though TLS + tcpcrypt will usually be > >done by the CPU... > > Hardware support for encryption exists at various layers; TLS and SSL > hardware accelerators have been common for many years (I have some that > are over 10 years old in my lab). Yes, and most of the inexpensive (sub $100) ones are very slow now, and have always been expensive for the moderate performance they provide... I've priced them out recently, and they are in the $1k range to get what a $80 CPU w/ AES-NI can now get you... > >Even a fast modern CPU not using dedicated > >instructions can only do ~150MB/sec for AES-GCM... Using double > >encryption means immedately half that performance... > > Sure. Until we figure out that we didn't really need TLS if we protect TCP. Except we will still need the authentication layer of TLS... > >That's a pretty steep price to pay... > > That's what people said about double-lookup for VM 30 years ago, about > 20 bytes for an IP header 20 years ago, and about TCP 10 years ago. It's > all relative to what you want. > > Let's not please engineer a long-term solution based on ephemeral concerns. I'm trying to make sure that people will use this feature instead of turning it off because the performance impact is too great... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 10:44:51 2014 Return-Path: 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 CB1DB1A0670 for ; Mon, 14 Apr 2014 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 WESUZtbqer1u for ; Mon, 14 Apr 2014 10:44:48 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 096E81A0564 for ; Mon, 14 Apr 2014 10:44:48 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EHiiuh045014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 10:44:44 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EHihh3045013; Mon, 14 Apr 2014 10:44:43 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 10:44:43 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414174443.GD43976@funkthat.com> References: <534ACC3E.1020308@isi.edu> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C1BD6.1030609@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 10:44:44 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/wIDQWFRbl0F2YSEC2XZHbCXaYmk Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:44:50 -0000 Joe Touch wrote this message on Mon, Apr 14, 2014 at 10:33 -0700: > On 4/14/2014 10:26 AM, John-Mark Gurney wrote: > >Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:44 -0700: > ... > >>You're assuming a unique ephemeral key per connection ... > > > >Because I'm assuming that the basic architecture of tcpcrypt will be > >used... How do you think this point of the charter: - When encryption is enabled, it must always provide forward secrecy. will be achieved w/o a unique key per connection/session? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 10:51:17 2014 Return-Path: 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 5F4411A0564 for ; Mon, 14 Apr 2014 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 6WY5b8K1emxt for ; Mon, 14 Apr 2014 10:51:10 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id C14311A0515 for ; Mon, 14 Apr 2014 10:51:10 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EHp2D6045105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 10:51:03 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EHp2Ox045104; Mon, 14 Apr 2014 10:51:02 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 10:51:02 -0700 From: John-Mark Gurney To: Tony Arcieri Message-ID: <20140414175102.GE43976@funkthat.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 10:51:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/yIsYulkWAzMLo7WhWXMvq-2bBj8 Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor , Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:51:15 -0000 Tony Arcieri wrote this message on Mon, Apr 14, 2014 at 09:58 -0700: > On Mon, Apr 14, 2014 at 9:32 AM, John-Mark Gurney wrote: > > > Even a fast modern CPU not using dedicated > > instructions can only do ~150MB/sec for AES-GCM > > Most modern CPUs have some sort of native acceleration like AES-NI. If I > run openssl speed -evp aes-128-gcm I get ~1.33GB/s I know, I'm working on that right now for FreeBSD... I used non-dedicated instructions because there are may processors out there, like ARM cores, Atom embedded CPUs, MIPS cores, PowerPC etc. that people would like to have a performant solution that don't all have dedicated instructions... i.e. most embedded solutions will be significantly less than 150MB/sec, and double encryption will be an even larger burden on these embedded systems (think smart phones where double encryption also impacts battery life)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 10:52:23 2014 Return-Path: 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 299D41A0208 for ; Mon, 14 Apr 2014 10:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 dQCpJzE-EPOs for ; Mon, 14 Apr 2014 10:52:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3901A065D for ; Mon, 14 Apr 2014 10:52:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EHpYAi013549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 10:51:34 -0700 (PDT) Message-ID: <534C2026.1040509@isi.edu> Date: Mon, 14 Apr 2014 10:51:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414173407.GC43976@funkthat.com> In-Reply-To: <20140414173407.GC43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/P6v-WncfdlUvL08gsJ8wlgPmEqI Cc: MARCELO BAGNULO BRAUN , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:52:21 -0000 On 4/14/2014 10:34 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:50 -0700: ... > I consider TLS a transport layer as it provides pipes, it just happens > to be implemented in the application layer... In the IETF, "transport" means the layer above IP that provides an E2E service, e.g., TCP, UDP, SCTP, etc. TLS does not provide transport security because it fails to protect the transport protocol. ... >> Hardware support for encryption exists at various layers; TLS and SSL >> hardware accelerators have been common for many years (I have some that >> are over 10 years old in my lab). > > Yes, and most of the inexpensive (sub $100) ones are very slow now, and > have always been expensive for the moderate performance they provide... > I've priced them out recently, and they are in the $1k range to get what > a $80 CPU w/ AES-NI can now get you... Apples and oranges. That $80 CPU doesn't run in a vacuum; it often sits in a $1000 box. The point is that hardware acceleration and offload exists - whether inside the CPU, in NIC offload engines, dedicated chips (HiFN), or as stand-alone systems. >>> Even a fast modern CPU not using dedicated >>> instructions can only do ~150MB/sec for AES-GCM... Using double >>> encryption means immedately half that performance... >> >> Sure. Until we figure out that we didn't really need TLS if we protect TCP. > > Except we will still need the authentication layer of TLS... Not necessarily. DH without authentication still prevents off-path attacks and requires on-path attackers participate in the DH exchange (i.e., raising their level of effort). ... >> Let's not please engineer a long-term solution based on ephemeral concerns. > > I'm trying to make sure that people will use this feature instead of > turning it off because the performance impact is too great... People (i.e., the masses) turn off security because it's too hard to configure. Once it's easy to use, its performance improves (e.g., WPA). Joe From nobody Mon Apr 14 10:54:31 2014 Return-Path: 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 0570E1A0677 for ; Mon, 14 Apr 2014 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 tKvWYpQRPSQY for ; Mon, 14 Apr 2014 10:54:26 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BC3B11A0683 for ; Mon, 14 Apr 2014 10:54:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EHrTNB014365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 10:53:30 -0700 (PDT) Message-ID: <534C2099.10407@isi.edu> Date: Mon, 14 Apr 2014 10:53:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <534ACC3E.1020308@isi.edu> <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> <20140414174443.GD43976@funkthat.com> In-Reply-To: <20140414174443.GD43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/qr-9kIZiw13vBLp3liiCmyFyj0A Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:54:30 -0000 On 4/14/2014 10:44 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Mon, Apr 14, 2014 at 10:33 -0700: >> On 4/14/2014 10:26 AM, John-Mark Gurney wrote: >>> Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:44 -0700: >> ... >>>> You're assuming a unique ephemeral key per connection ... >>> >>> Because I'm assuming that the basic architecture of tcpcrypt will be >>> used... > > How do you think this point of the charter: > - When encryption is enabled, it must always provide forward secrecy. > > will be achieved w/o a unique key per connection/session? The keys can be derived from the session information, using master keys. E.g., how it was done in TCP-AO. But if you take away the connection identifier (e.g., if you exclude both addrs and ports because of NAT issues), how to you create that ephemeral key? Joe From nobody Mon Apr 14 12:12:28 2014 Return-Path: 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 0F48A1A063F for ; Mon, 14 Apr 2014 12:12:26 -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 LGAoo965XXKN for ; Mon, 14 Apr 2014 12:12:21 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16D1A04A1 for ; Mon, 14 Apr 2014 12:12:21 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 177E98B78A4; Mon, 14 Apr 2014 21:12:18 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 093DC76691F; Mon, 14 Apr 2014 21:12:18 +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 21:12:18 +0200 Message-ID: <20140414211218.vbr14am6q88kc84s@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 21:12:18 +0200 From: MARCELO BAGNULO BRAUN To: Joe Touch References: <533C33D2.4060004@it.uc3m.es> <20140414171309.wbovftkckkcggs04@webcartero01.uc3m.es> <534BFE28.1080408@isi.edu> In-Reply-To: <534BFE28.1080408@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 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 14 Apr 2014 21:12:18 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001 X-TM-AS-Result: No--5.976-7.0-31-1 X-imss-scan-details: No--5.976-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/eZLnbsX18kOSrEkM-nlxuH703y0 Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:12:26 -0000 Joe Touch dijo: > > > On 4/14/2014 8:13 AM, MARCELO BAGNULO BRAUN wrote: >> Tony Arcieri dijo: >> >>> On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun >>> wrote: >>> >>>> TCP anonymous encryption (TAE) >>>> >>>> Anonymous encryption is an anonymous key exchange resulting in >>>> encryption >>>> without authentication >>> >>> >>> Will this idea be compatible with future authentication systems, i.e. >>> could >>> some mechanism verify public keys for you, then hand off the rest of the >>> session to tcpcrypt? >>> >> >> yes, this is expressed in the proposed charter text as hooks for upper >> layer authentication, makes sense? > > Hooks for out-of-band authentication is useful; hooks that are > described as tying layers together are problematic I see your concern with this terminology otoh, out of band make me think about manually configured keys, which is not what we want to do, maybe hooks for external authentication, maybe? > - they could be interpreted as "channel binding", a method that can > render the lower-level mechanism useless if absent (and thus > disabling a useful mode). > > Joe > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 12:20:10 2014 Return-Path: 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 C8CB41A06A3 for ; Mon, 14 Apr 2014 12:20:07 -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 em2IUTWUFTGD for ; Mon, 14 Apr 2014 12:20:04 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 668361A0209 for ; Mon, 14 Apr 2014 12:20:04 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 19B0A9D347D; Mon, 14 Apr 2014 21:20:01 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 4A5DF11C4603; Mon, 14 Apr 2014 21:20:00 +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 21:20:00 +0200 Message-ID: <20140414212000.v9ghsownjoc84c0o@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 21:20:00 +0200 From: MARCELO BAGNULO BRAUN To: Joe Touch References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> In-Reply-To: <534C1BD6.1030609@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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 14 Apr 2014 21:20:01 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001 X-TM-AS-Result: No--13.718-7.0-31-1 X-imss-scan-details: No--13.718-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Ukxnwq0H9j7av2LME5kBMCz4kws Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:20:08 -0000 Joe Touch dijo: > > > On 4/14/2014 10:26 AM, John-Mark Gurney wrote: >> Joe Touch wrote this message on Mon, Apr 14, 2014 at 09:44 -0700: > ... >>> You're assuming a unique ephemeral key per connection ... >> >> Because I'm assuming that the basic architecture of tcpcrypt will be >> used... > > That is an error in the naming of this group. Right, i was surprised when we got that particular name for the ml Note that in the propose charter and wg name we are using a different name (which seems to have other problems, but i guess all names do) > > I already spoke with Martin about this issue, and he claimed that the > name was an artifact, not intended to focus on a particular solution. > This is obvious, but i guess it is worthwhile clarifying the IETF process for once in a while. So, the goal of this effort is to create a WG to work on anonymous/oportunistic encryption for TCP streams. As any WG in the IETF, the outcome will be defined by the IETF process, i.e. the WG will define how the final solution will look like. this is not to rubberstamp with the IETF brand a previously backed solution. That being said, the work on tcpcrypt in particular is a very valuable input and it is expected to influence the work as other pieces of existing work (such as TCP AO or others proposals that may come up later on). I hope i am not saying anything new to anyone here. Hope this clarifies the process. Regards, marcelo > Martin might want to weigh-in on this. > > Joe > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 12:27:51 2014 Return-Path: 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 B78F91A06F8 for ; Mon, 14 Apr 2014 12:27:48 -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 1Xk8bVhA7uMV for ; Mon, 14 Apr 2014 12:27:47 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id DFD641A06C4 for ; Mon, 14 Apr 2014 12:27:46 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EB83411C4562 for ; Mon, 14 Apr 2014 21:27:43 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id D4B919D337C for ; Mon, 14 Apr 2014 21:27:43 +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 21:27:43 +0200 Message-ID: <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 21:27:43 +0200 From: MARCELO BAGNULO BRAUN To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> In-Reply-To: <534C11F2.3030607@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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 14 Apr 2014 21:27:43 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001 X-TM-AS-Result: No--11.737-7.0-31-1 X-imss-scan-details: No--11.737-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1mJAHcyrHbsXu2UfwtEd13YOhMA 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:27:48 -0000 Joe Touch dijo: > > A TCP crypto solution would necessarily need to protect TCP's > signalling protocol, i.e., (at a minimum) the sequence numbers and > flags. > Not necesarily. It is actually explicitly stated in the charter that what fields (if any) of the TCP header will be protected by the protocol. As it has become clear from the disucssion in this ml, there are many tradeoffs involved when making the decision of what tpc fields to protect. I dont think we need to work these tradeoffs here, as this is part of the work of the working group (i am perfectly fine with discussing the tradeoffs here though). But just to make it perfectly clear that a solution that doesnt protect any of the TCP fields is a acceptable outcome with the proposed charter. I personally think this is a long discussion and i think it is better to leave it for the WG to figure it out. Regards, marcelo From nobody Mon Apr 14 12:32:57 2014 Return-Path: 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 155F01A0700 for ; Mon, 14 Apr 2014 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 bseYxGTIkTbG for ; Mon, 14 Apr 2014 12:32:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CA1B71A0209 for ; Mon, 14 Apr 2014 12:32:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EJWHxL016640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:32:17 -0700 (PDT) Message-ID: <534C37C1.7080608@isi.edu> Date: Mon, 14 Apr 2014 12:32:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <20140414171309.wbovftkckkcggs04@webcartero01.uc3m.es> <534BFE28.1080408@isi.edu> <20140414211218.vbr14am6q88kc84s@webcartero01.uc3m.es> In-Reply-To: <20140414211218.vbr14am6q88kc84s@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/G1Ki0cHnTIEw_EUKtjhoqPs8JkE Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:32:55 -0000 On 4/14/2014 12:12 PM, MARCELO BAGNULO BRAUN wrote: > Joe Touch dijo: > >> >> >> On 4/14/2014 8:13 AM, MARCELO BAGNULO BRAUN wrote: >>> Tony Arcieri dijo: >>> >>>> On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun >>>> wrote: >>>> >>>>> TCP anonymous encryption (TAE) >>>>> >>>>> Anonymous encryption is an anonymous key exchange resulting in >>>>> encryption >>>>> without authentication >>>> >>>> >>>> Will this idea be compatible with future authentication systems, i.e. >>>> could >>>> some mechanism verify public keys for you, then hand off the rest of >>>> the >>>> session to tcpcrypt? >>>> >>> >>> yes, this is expressed in the proposed charter text as hooks for upper >>> layer authentication, makes sense? >> >> Hooks for out-of-band authentication is useful; hooks that are >> described as tying layers together are problematic > > I see your concern with this terminology > otoh, out of band make me think about manually configured keys, which is > not what we want to do, maybe hooks for external authentication, maybe? Sure - that's probably a better term. Joe From nobody Mon Apr 14 12:43:20 2014 Return-Path: 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 B021B1A0718 for ; Mon, 14 Apr 2014 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 6mCc1W3HsI6t for ; Mon, 14 Apr 2014 12:43:17 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 77E6B1A0213 for ; Mon, 14 Apr 2014 12:43:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EJgXW9019482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:42:33 -0700 (PDT) Message-ID: <534C3A29.2020606@isi.edu> Date: Mon, 14 Apr 2014 12:42:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> In-Reply-To: <20140414212000.v9ghsownjoc84c0o@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bC07u3ZXsg6-d4qdU5g844mTg1Q Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:43:18 -0000 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? Joe From nobody Mon Apr 14 12:44:15 2014 Return-Path: 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 C10ED1A02AC for ; Mon, 14 Apr 2014 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 50xONvtHasqN for ; Mon, 14 Apr 2014 12:44:11 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0901A0213 for ; Mon, 14 Apr 2014 12:44:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EJhmJo020068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:43:48 -0700 (PDT) Message-ID: <534C3A74.9050109@isi.edu> Date: Mon, 14 Apr 2014 12:43:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> In-Reply-To: <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Py5J8349Hwq2lycCIs0AvkY2noY 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:44:12 -0000 On 4/14/2014 12:27 PM, MARCELO BAGNULO BRAUN wrote: > Joe Touch dijo: > > >> >> A TCP crypto solution would necessarily need to protect TCP's >> signalling protocol, i.e., (at a minimum) the sequence numbers and flags. >> > > Not necesarily. It is actually explicitly stated in the charter that > what fields (if any) of the TCP header will be protected by the protocol. > > As it has become clear from the disucssion in this ml, there are many > tradeoffs involved when making the decision of what tpc fields to > protect. I dont think we need to work these tradeoffs here, as this is > part of the work of the working group (i am perfectly fine with > discussing the tradeoffs here though). > > But just to make it perfectly clear that a solution that doesnt protect > any of the TCP fields is a acceptable outcome with the proposed charter. I would argue that this is then not TCP security. If you can't protect the TCP protocol itself, there's nearly nothing added vs. TLS. Joe From nobody Mon Apr 14 13:01:44 2014 Return-Path: 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 6DEBA1A0687 for ; Mon, 14 Apr 2014 13:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 UJzNjE9kdRfP for ; Mon, 14 Apr 2014 13:01:39 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id E401F1A0683 for ; Mon, 14 Apr 2014 13:01:37 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3EK1YXw031683 for ; Mon, 14 Apr 2014 16:01:34 -0400 Received: (qmail 28984 invoked by uid 0); 14 Apr 2014 20:01:34 -0000 X-TCPREMOTEIP: 76.188.220.98 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.11?) (wes@mti-systems.com@76.188.220.98) by 0 with ESMTPA; 14 Apr 2014 20:01:34 -0000 Message-ID: <534C3E9A.9080707@mti-systems.com> Date: Mon, 14 Apr 2014 16:01:30 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> In-Reply-To: <534C3A74.9050109@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/mS_0boXC87Z5iHgKPm4f7mFw5jw 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:01:41 -0000 On 4/14/2014 3:43 PM, Joe Touch wrote: >> >> But just to make it perfectly clear that a solution that doesnt protect >> any of the TCP fields is a acceptable outcome with the proposed charter. > > I would argue that this is then not TCP security. If you can't protect > the TCP protocol itself, there's nearly nothing added vs. TLS. > I agree. Of course, TCP-AO can already protect the connection, just not the data. The goal should be to offer improvement for an application that would currently have to use TCP-AO + TLS in ensemble. -- Wes Eddy MTI Systems From nobody Mon Apr 14 13:05:52 2014 Return-Path: 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 A49A01A064F for ; Mon, 14 Apr 2014 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 mPT140XCRjW5 for ; Mon, 14 Apr 2014 13:05:49 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 945DC1A06A3 for ; Mon, 14 Apr 2014 13:05:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EK5Jmj027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:05:19 -0700 (PDT) Message-ID: <534C3F7F.20708@isi.edu> Date: Mon, 14 Apr 2014 13:05:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Wesley Eddy , MARCELO BAGNULO BRAUN , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> In-Reply-To: <534C3E9A.9080707@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/vDyF1uVTX9soIQiBb1lDiQ1fbkk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:05:50 -0000 On 4/14/2014 1:01 PM, Wesley Eddy wrote: > On 4/14/2014 3:43 PM, Joe Touch wrote: >>> >>> But just to make it perfectly clear that a solution that doesnt protect >>> any of the TCP fields is a acceptable outcome with the proposed charter. >> >> I would argue that this is then not TCP security. If you can't protect >> the TCP protocol itself, there's nearly nothing added vs. TLS. >> > > > I agree. Of course, TCP-AO can already protect the connection, just not > the data. TCP-AO protects the integrity of the connection and the data. http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00 augments TCP-AO with a mode in which the payload is encrypted. > The goal should be to offer improvement for an application > that would currently have to use TCP-AO + TLS in ensemble. Agreed; see ao-encrypt. Joe From nobody Mon Apr 14 13:15:27 2014 Return-Path: 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 1CDF11A0319 for ; Mon, 14 Apr 2014 13:15:26 -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 L4j4ufbI-jG9 for ; Mon, 14 Apr 2014 13:15:24 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id C44511A0213 for ; Mon, 14 Apr 2014 13:15:23 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6CBD5CD56CA; Mon, 14 Apr 2014 22:15:20 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id AB930CD719C; Mon, 14 Apr 2014 22:15:19 +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:15:19 +0200 Message-ID: <20140414221519.vg3o2epgg00w8scs@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 22:15:19 +0200 From: MARCELO BAGNULO BRAUN To: Joe Touch References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> In-Reply-To: <534C3A29.2020606@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:15:20 +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/i7EGdsoaJChGCiRh7BSpWEO-1lE Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:15:26 -0000 Joe Touch 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. 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? Regards, marcelo > > Joe > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 13:22:16 2014 Return-Path: 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 19B7E1A06F0 for ; Mon, 14 Apr 2014 13:22:15 -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 N3n1y1HPXClB for ; Mon, 14 Apr 2014 13:22:10 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 025291A039D for ; Mon, 14 Apr 2014 13:22:09 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 17EBC9D344B; Mon, 14 Apr 2014 22:22:07 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 009CC9D337C; Mon, 14 Apr 2014 22:22:06 +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:22:06 +0200 Message-ID: <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 22:22:06 +0200 From: MARCELO BAGNULO BRAUN To: Wesley Eddy References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> In-Reply-To: <534C3E9A.9080707@mti-systems.com> 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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 14 Apr 2014 22:22:07 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001 X-TM-AS-Result: No--22.488-7.0-31-1 X-imss-scan-details: No--22.488-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/CWBEyCKlTyTiW-9l8CwK_TApFZI Cc: tcpcrypt@ietf.org, Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:22:15 -0000 Hi Wes, below... Wesley Eddy dijo: > On 4/14/2014 3:43 PM, Joe Touch wrote: >>> >>> But just to make it perfectly clear that a solution that doesnt protect >>> any of the TCP fields is a acceptable outcome with the proposed charter. >> >> I would argue that this is then not TCP security. If you can't protect >> the TCP protocol itself, there's nearly nothing added vs. TLS. >> > > > I agree. Of course, TCP-AO can already protect the connection, just not > the data. The goal should be to offer improvement for an application > that would currently have to use TCP-AO + TLS in ensemble. > I think there is added value to such a solution. First and probably most important, if we had a solution that encrypts tcp stremas without requiring authentication that could be used by unmodified apps (i.e. apps opening a regular tcp socket, similar to the mptcp approach) this would allow us to deply pervasive crypto with much less pain that requiring all apps to adopt TLS. Of course TLS is a better solution, but for those apps that people dont want to run over TLS, this would go a long way imho. that is the argument why this is complementary with TLS. Now, the other part of the argument, why not to protect the TCP header. Well, i didnt say we shouldnt protect it. Actually i would like to protect it, if the price to pay is not that we end up with an undeplyable protocol that is imcompatible with middleboxes, current operational practices and other elements of the Internet. That is why i believe the charter shoudlbe open to discuss what is that we can protect of the TCP header and still have some chances to get wider deployment. I think there are complex tradeoffs in that disucssion that should be better understood in the WG discussion that in the chartering discussion. That is why i believe we should charter a WG on TCP crypto and leave the disucssion on what to protect of the TCP header for the WG. Makes sense? Regards, marcelo > -- > Wes Eddy > MTI Systems > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 13:25:52 2014 Return-Path: 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 EDA8A1A06FA for ; Mon, 14 Apr 2014 13:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 w0Sk-wYPZF_G for ; Mon, 14 Apr 2014 13:25:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id ADA911A06F8 for ; Mon, 14 Apr 2014 13:25:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EKPHRV003290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:25:17 -0700 (PDT) Message-ID: <534C442D.2020000@isi.edu> Date: Mon, 14 Apr 2014 13:25:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> In-Reply-To: <20140414221519.vg3o2epgg00w8scs@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/O4SWj862VBjGrDesSRLCG9t_2xY Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:25:52 -0000 On 4/14/2014 1:15 PM, MARCELO BAGNULO BRAUN wrote: > Joe Touch 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. > 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. Joe From nobody Mon Apr 14 13:30:04 2014 Return-Path: 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 DC9171A06F4 for ; Mon, 14 Apr 2014 13:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 Fhm4HQNj5b2o for ; Mon, 14 Apr 2014 13:30:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA81A021F for ; Mon, 14 Apr 2014 13:30:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EKT37h004468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:29:03 -0700 (PDT) Message-ID: <534C450F.5010808@isi.edu> Date: Mon, 14 Apr 2014 13:29:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , Wesley Eddy References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> In-Reply-To: <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/_CqePy1DXr1g2IcSp_3nnyT07No Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:30:03 -0000 On 4/14/2014 1:22 PM, MARCELO BAGNULO BRAUN wrote: > Now, the other part of the argument, why not to protect the TCP header. > Well, i didnt say we shouldnt protect it. Actually i would like to > protect it, if the price to pay is not that we end up with an > undeplyable protocol that is imcompatible with middleboxes, current > operational practices and other elements of the Internet. FWIW, ao-encrypt is compatible with conventional NATs, so it's possible to both protect most of the TCP header (e.g., except source port and source addr) while providing per-connection ephemeral keys based on sufficient session-specific information. There are a few other issues, BTW, that are addressed in TCP-AO-based solutions that might be important to consider: - avoiding replay attacks, even with TCP sequence number wrap - allow key rollover during a connection esp. while avoiding increased receiver load, e.g., in checking multiple keys - coordinate key rollover between endpoints so the source knows when it can use an available new key Joe From nobody Mon Apr 14 13:32:13 2014 Return-Path: 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 ; 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 ; 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 ; 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 To: Joe Touch References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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 , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:32:12 -0000 Hi, Joe Touch dijo: > > > On 4/14/2014 1:15 PM, MARCELO BAGNULO BRAUN wrote: >> Joe Touch 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 From nobody Mon Apr 14 13:40:02 2014 Return-Path: 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 7BE741A0717 for ; Mon, 14 Apr 2014 13:40:00 -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 b7gqrxgpb4rN for ; Mon, 14 Apr 2014 13:39:54 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 313D31A070A for ; Mon, 14 Apr 2014 13:39:54 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1CDF8CD72EB; Mon, 14 Apr 2014 22:39:51 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 0EA2CC3577D; Mon, 14 Apr 2014 22:39:51 +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:39:51 +0200 Message-ID: <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 22:39:51 +0200 From: MARCELO BAGNULO BRAUN To: Joe Touch References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> In-Reply-To: <534C450F.5010808@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:39:51 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.002 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/3kWaCCwxcMs9SkmDpv9EEAiYnFo Cc: Wesley Eddy , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:40:00 -0000 Joe Touch dijo: > > > On 4/14/2014 1:22 PM, MARCELO BAGNULO BRAUN wrote: >> Now, the other part of the argument, why not to protect the TCP header. >> Well, i didnt say we shouldnt protect it. Actually i would like to >> protect it, if the price to pay is not that we end up with an >> undeplyable protocol that is imcompatible with middleboxes, current >> operational practices and other elements of the Internet. > > FWIW, ao-encrypt is compatible with conventional NATs, so it's > possible to both protect most of the TCP header (e.g., except source > port and source addr) while providing per-connection ephemeral keys > based on sufficient session-specific information. > > There are a few other issues, BTW, that are addressed in TCP-AO-based > solutions that might be important to consider: > > - avoiding replay attacks, even with TCP sequence number wrap > > - allow key rollover during a connection > esp. while avoiding increased receiver load, > e.g., in checking multiple keys > > - coordinate key rollover between endpoints > so the source knows when it can use > an available new key agree let me restate, i am not against protecting the tcp header, i wish we could manage to do that it is just that i think we need to understnad the tradeoff better. my main concern is with tcp option space maybe i got this wrong, but my understanding is as follows: if we protect the tcp header we need to use tcp options to carry the mac (if we include the mac in the payload, then when we send pure acks, they carry data (the mac) and they eat seq numbers so we need to ack acks and it all becomes a mess)) if we send the mac in the tcp options, well, we use a lot of option space and we are conflicting with other uses of the optcion space, especially sack and that would deter the deployment of the solution (we dont want that people needs to choose between crypt or sack, because they will choose sack) hence, if we come to the conclusion that it is better to send the mac in the payload, then we may need to give up protecting the header again, there are many dubious statements in the argument above that i woudl like to understand better (including for instance how much we gain by protecting the tcp header and how much of the option space we need to use for the mac and a few others) that being said, i think this is for the wg to discuss and figure out regards, marcelo > > Joe > > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 13:42:50 2014 Return-Path: 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 B923E1A068B for ; Mon, 14 Apr 2014 13:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 IADVTZXpt2V5 for ; Mon, 14 Apr 2014 13:42:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 632B41A0208 for ; Mon, 14 Apr 2014 13:42:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 083F8BE55; Mon, 14 Apr 2014 21:42:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dluzxRq1o0-4; Mon, 14 Apr 2014 21:42:36 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.30.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC12FBE50; Mon, 14 Apr 2014 21:42:35 +0100 (IST) Message-ID: <534C483B.6030000@cs.tcd.ie> Date: Mon, 14 Apr 2014 21:42:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/EScPgm4RgoAAWhxxkI_m_sUTASk Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:42:46 -0000 On 04/14/2014 09:25 PM, Joe Touch wrote: > > 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. FWIW, my opinion is that this work ought use whatever turns out to be the consensus terminology that saag ends up with assuming it does reach rough consensus, which is looking more likely now after much discussion similar to the above. I also see no good reason why that discussion needs to be done over here. S. From nobody Mon Apr 14 13:53:37 2014 Return-Path: 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 5B5DE1A0643 for ; Mon, 14 Apr 2014 13:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 IwxAZccRhzs3 for ; Mon, 14 Apr 2014 13:53:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 963A91A0574 for ; Mon, 14 Apr 2014 13:53:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EKqx6q011223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:53:00 -0700 (PDT) Message-ID: <534C4AAB.9080400@isi.edu> Date: Mon, 14 Apr 2014 13:52:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <20140414223204.aeu1xthy6qsss0ww@webcartero01.uc3m.es> In-Reply-To: <20140414223204.aeu1xthy6qsss0ww@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bXwifflDWnWzGIUCUf-Ym3ZH7fI Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:53:34 -0000 On 4/14/2014 1:32 PM, MARCELO BAGNULO BRAUN wrote: > Hi, > > Joe Touch dijo: ... >> 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. Yeah, but BTNS was integrity protected, and unauthenticated sometimes isn't too. > 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 preventing the hooks for external authentication, but i guess > it is something we can live with, as long we properly explain it in the > charter. I think you can be clear about what you are providing, and allow/require hooks that are *optional* easily. Joe From nobody Mon Apr 14 13:55:30 2014 Return-Path: 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 EE8EA1A0643 for ; Mon, 14 Apr 2014 13:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 7nb111B1KM8F for ; Mon, 14 Apr 2014 13:55:27 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A7FEA1A0297 for ; Mon, 14 Apr 2014 13:55:27 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EKskWF011955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:54:46 -0700 (PDT) Message-ID: <534C4B16.8070503@isi.edu> Date: Mon, 14 Apr 2014 13:54:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> In-Reply-To: <534C483B.6030000@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/E9Zpa61LSGiHbtSCxGU8UWHtmzw Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:55:29 -0000 On 4/14/2014 1:42 PM, Stephen Farrell wrote: > > > On 04/14/2014 09:25 PM, Joe Touch wrote: >> >> 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. > > FWIW, my opinion is that this work ought use whatever turns out > to be the consensus terminology that saag ends up with assuming > it does reach rough consensus, which is looking more likely now > after much discussion similar to the above. I don't agree; much of the discussion there were a lot of arm-chair quarterbacks second-guessing the public-relations value of the term they were using (i.e., whether the public would adopt it). AFAICT, they lost their way when they decided to try to redefine opportunistic, which is already a well-known and well-cited term (by their own admission). > I also see no good > reason why that discussion needs to be done over here. IMO because they're screwing it up ;-) Joe From nobody Mon Apr 14 14:00:58 2014 Return-Path: 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 C3B641A0545 for ; Mon, 14 Apr 2014 14:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 03k6R-scFyZh for ; Mon, 14 Apr 2014 14:00:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6311A0208 for ; Mon, 14 Apr 2014 14:00:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EKxK1d013322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:59:21 -0700 (PDT) Message-ID: <534C4C28.2030501@isi.edu> Date: Mon, 14 Apr 2014 13:59:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> In-Reply-To: <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5hK77O_rnPSB4-hlw-Mc8_zpuao Cc: Wesley Eddy , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:00:56 -0000 On 4/14/2014 1:39 PM, MARCELO BAGNULO BRAUN wrote: > Joe Touch dijo: > >> >> >> On 4/14/2014 1:22 PM, MARCELO BAGNULO BRAUN wrote: >>> Now, the other part of the argument, why not to protect the TCP header. >>> Well, i didnt say we shouldnt protect it. Actually i would like to >>> protect it, if the price to pay is not that we end up with an >>> undeplyable protocol that is imcompatible with middleboxes, current >>> operational practices and other elements of the Internet. >> >> FWIW, ao-encrypt is compatible with conventional NATs, so it's >> possible to both protect most of the TCP header (e.g., except source >> port and source addr) while providing per-connection ephemeral keys >> based on sufficient session-specific information. >> >> There are a few other issues, BTW, that are addressed in TCP-AO-based >> solutions that might be important to consider: >> >> - avoiding replay attacks, even with TCP sequence number wrap >> >> - allow key rollover during a connection >> esp. while avoiding increased receiver load, >> e.g., in checking multiple keys >> >> - coordinate key rollover between endpoints >> so the source knows when it can use >> an available new key > > agree > > let me restate, i am not against protecting the tcp header, i wish we > could manage to do that > > it is just that i think we need to understnad the tradeoff better. > > my main concern is with tcp option space > > maybe i got this wrong, but my understanding is as follows: > if we protect the tcp header we need to use tcp options to carry the mac Yes. That's what TCP-AO does, FWIW. > (if we include the mac in the payload, then when we send pure acks, they > carry data (the mac) and they eat seq numbers so we need to ack acks and > it all becomes a mess))' Anything in the payload except the payload is a mess; we went through this discussion with tcp-multipath, FWIW. > if we send the mac in the tcp options, well, we use a lot of option > space and we are conflicting with other uses of the optcion space, > especially sack and that would deter the deployment of the solution (we > dont want that people needs to choose between crypt or sack, because > they will choose sack) See Section 7.6 of RFC 5925. There's enough space. > hence, if we come to the conclusion that it is better to send the mac in > the payload, then we may need to give up protecting the header I think that throws the baby out with the bathwater. I.e., I'd rather see a shorter option MAC (if necessary) than a payload MAC at all. > again, there are many dubious statements in the argument above that i > woudl like to understand better (including for instance how much we gain > by protecting the tcp header and how much of the option space we need to > use for the mac and a few others) The issue with protecting the TCP header is in the TCP-AO RFC as well. If you don't, DOS attacks are trivial -- but, more to the point, you might as well use TLS (and create a mode where it is OK to ignore authentication in both directions - is is done one-way with most websites now anyway). Joe From nobody Mon Apr 14 14:01:45 2014 Return-Path: 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 79BB31A0224 for ; Mon, 14 Apr 2014 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 Nb48mLm-f11n for ; Mon, 14 Apr 2014 14:01:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C78741A06A0 for ; Mon, 14 Apr 2014 14:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8FDEABE50; Mon, 14 Apr 2014 22:01:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPAp71tTOfFq; Mon, 14 Apr 2014 22:01:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.30.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A161BE3E; Mon, 14 Apr 2014 22:01:24 +0100 (IST) Message-ID: <534C4CA4.7080905@cs.tcd.ie> Date: Mon, 14 Apr 2014 22:01:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <534C4B16.8070503@isi.edu> In-Reply-To: <534C4B16.8070503@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ysvDuGR4xAXjI952jr7yLXjpg2k Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:01:41 -0000 On 04/14/2014 09:54 PM, Joe Touch wrote: > > > On 4/14/2014 1:42 PM, Stephen Farrell wrote: >> >> >> On 04/14/2014 09:25 PM, Joe Touch wrote: >>> >>> 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. >> >> FWIW, my opinion is that this work ought use whatever turns out >> to be the consensus terminology that saag ends up with assuming >> it does reach rough consensus, which is looking more likely now >> after much discussion similar to the above. > > I don't agree; much of the discussion there were a lot of arm-chair > quarterbacks second-guessing the public-relations value of the term they > were using (i.e., whether the public would adopt it). > > AFAICT, they lost their way when they decided to try to redefine > opportunistic, which is already a well-known and well-cited term (by > their own admission). I disagree with the above assertions. The term has been far more commonly used to mean something else in the last year, which is why we need to go to the trouble of getting agreement on the terminology. In the HTTP WG that terminology confusion alone was part of an argument some people made against encrypting without https URIs, so the confusion has a real, and not a mythical, downside in addition to the wasted effort of re-doing discussions over and over. >> I also see no good >> reason why that discussion needs to be done over here. > > IMO because they're screwing it up ;-) Right. You disagree and are fully entitled to be in the rough:-) But if you do disagree please get involved in the discussion on saag, it'll really be better if we can avoid having to re-do this discussion a number of times over, no matter which of us end up in the rough. S. > > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > From nobody Mon Apr 14 14:11:37 2014 Return-Path: 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 379521A06D6 for ; Mon, 14 Apr 2014 14:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 jTpJf57_TxoC for ; Mon, 14 Apr 2014 14:11:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CFDBF1A06C8 for ; Mon, 14 Apr 2014 14:11:33 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ELAnro016892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 14:10:49 -0700 (PDT) Message-ID: <534C4ED9.9060808@isi.edu> Date: Mon, 14 Apr 2014 14:10:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <534C4B16.8070503@isi.edu> <534C4CA4.7080905@cs.tcd.ie> In-Reply-To: <534C4CA4.7080905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ejRBlZ-MUuhiU6obKv2odQAjRGo Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:11:35 -0000 On 4/14/2014 2:01 PM, Stephen Farrell wrote: ... >> I don't agree; much of the discussion there were a lot of arm-chair >> quarterbacks second-guessing the public-relations value of the term they >> were using (i.e., whether the public would adopt it). >> >> AFAICT, they lost their way when they decided to try to redefine >> opportunistic, which is already a well-known and well-cited term (by >> their own admission). > > I disagree with the above assertions. The term has been far > more commonly used to mean something else in the last year, That's just more evidence that it's a poor term to use. > which is why we need to go to the trouble of getting agreement > on the terminology. Agreement is definitely needed. > In the HTTP WG that terminology confusion > alone was part of an argument some people made against > encrypting without https URIs, so the confusion has a real, and > not a mythical, downside in addition to the wasted effort of > re-doing discussions over and over. > >>> I also see no good >>> reason why that discussion needs to be done over here. >> >> IMO because they're screwing it up ;-) > > Right. You disagree and are fully entitled to be in the rough:-) > > But if you do disagree please get involved in the discussion > on saag, I did, and it was immediately evident that it was pointless to do so. > it'll really be better if we can avoid having to re-do > this discussion a number of times over, no matter which of us > end up in the rough. Although I appreciate the sentiment, not all WGs are worth participating in, and not all will necessarily concur on any terminology. They went off the rails trying to redefine a term that clearly has gotten out of their control; I don't think there's much you can do to correct that except avoid the term, and they don't want to do that. IMO, we can do better here. Joe From nobody Mon Apr 14 14:22:31 2014 Return-Path: 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 A008A1A0724 for ; Mon, 14 Apr 2014 14:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 dLFKe22aszTw for ; Mon, 14 Apr 2014 14:22:25 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 917B01A06E6 for ; Mon, 14 Apr 2014 14:22:25 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so8139204veb.16 for ; Mon, 14 Apr 2014 14:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/HvaSYpoIMAVnBqGVaf47E1SGkxoodFW9sYRE5+RZmE=; b=Lic+eg9jBOWPogu/IDy1dAqXsh3MnWN7McaQgxKCWkJslUnEeNV1EKGu0g7YAQ+z3B 3YdYmjgdN3f9W7/k/CcH2Tqd1uLL/fl0BP3XNNeOfmmQAGbagfgJXjjO6aJBtArigRr9 RcppCEHmi7QSWtV6DtMYQVKJXxKa7xmCtU8ENxj4Jh+JXzN8aIfD6zXjFgcEWd4brUOY TwOLfbR7wa3lame9WK3vbzONjk05IrU6qsVopqqHgb03W1u4+UXhNK1nmAyegEMnGAEj DaVVWexpyn1TY7sHLjQPeKabsxd2R8JsFy1qgwqD0F1viECgfisjI9TvFt5fN3zlMGk7 CRcw== X-Received: by 10.52.108.164 with SMTP id hl4mr4274427vdb.25.1397510542871; Mon, 14 Apr 2014 14:22:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Mon, 14 Apr 2014 14:22:02 -0700 (PDT) From: Tony Arcieri Date: Mon, 14 Apr 2014 14:22:02 -0700 Message-ID: To: tcpcrypt@ietf.org Content-Type: multipart/alternative; boundary=bcaec547c9d57a59cf04f707478e Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/VqCLkgMxHadPTv43lWJTI9V_hFE Subject: [Tcpcrypt] Nuke TLS from orbit X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:22:29 -0000 --bcaec547c9d57a59cf04f707478e Content-Type: text/plain; charset=UTF-8 Mentions Tcpcrypt: http://clearcryptocode.org/tls/ -- Tony Arcieri --bcaec547c9d57a59cf04f707478e Content-Type: text/html; charset=UTF-8
Mentions Tcpcrypt:

--bcaec547c9d57a59cf04f707478e-- From nobody Mon Apr 14 14:29:45 2014 Return-Path: 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 DC3D71A073B for ; Mon, 14 Apr 2014 14:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_54=0.6] autolearn=no 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 XwsMM9znh2NU for ; Mon, 14 Apr 2014 14:29:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1127B1A073F for ; Mon, 14 Apr 2014 14:29:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 892FB67C06E for ; Mon, 14 Apr 2014 14:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=GGPhiOU4O6TQNihfxCI9 RUhN9LA=; b=AtpeDevIypd83ScYlEMWVfdUMnLlAZk4cmRRwN7W5sDQwiP6bKe4 7T0vTNyZK+eLIZLyHQV2xnuDR3vg/dxTLdcez4vHTPvNS+Qf9o6/p6yEEIuvNJy7 +vWPXK7mPAPG5eUS/QDSlt4kLlvm+gOiVCxPBBXEdhqUVY9MaCtn1Wk= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 39E3267C069 for ; Mon, 14 Apr 2014 14:29:37 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so8783930wes.1 for ; Mon, 14 Apr 2014 14:29:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr11224682wic.5.1397510975847; Mon, 14 Apr 2014 14:29:35 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 14:29:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 16:29:35 -0500 Message-ID: From: Nico Williams To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/M8JhzC5s59yvG25gHbKKbWlL4Kw Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Nuke TLS from orbit X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:29:44 -0000 If we're to nuke TLS and... replace it with what? My preferred answer would be IPsec+DANE, which would work as follows on the client side: 1) apps get target's TLSA RRset (using the target's _host_ name FQDN, of course) 2) apps pass in this data to the socket as a socket option (or an enhanced sockaddr) 3) apps connect() (even for UDP, of course) 4) the system guarantees that for the life of the connected socket its packet flow will be protected by SAs whose peer's public credentials match the given TLSA RRset. The guarantee in (4) is very similar to the guarantee provided for in RFC5660. Nico -- From nobody Mon Apr 14 14:35:50 2014 Return-Path: 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 C41E51A0235 for ; Mon, 14 Apr 2014 14:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 aI2P5TPtACJf for ; Mon, 14 Apr 2014 14:35:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 90C1C1A0671 for ; Mon, 14 Apr 2014 14:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87092BE55; Mon, 14 Apr 2014 22:35:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB+th7RQfnkG; Mon, 14 Apr 2014 22:35:41 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.30.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 483ACBE4C; Mon, 14 Apr 2014 22:35:41 +0100 (IST) Message-ID: <534C54AD.8000805@cs.tcd.ie> Date: Mon, 14 Apr 2014 22:35:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <534C4B16.8070503@isi.edu> <534C4CA4.7080905@cs.tcd.ie> <534C4ED9.9060808@isi.edu> In-Reply-To: <534C4ED9.9060808@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/IKOPGMkZd4CWaHGRvQUWM5pXlwE Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:35:48 -0000 On 04/14/2014 10:10 PM, Joe Touch wrote: > Agreement is definitely needed. > ... > > IMO, we can do better here. Depending what you mean, your two statements above could be in conflict. But anyway - sometimes one just has to accept being in the rough on stuff. If this group use terms that are being defined elsewhere in a confusing manner then that I think is highly likely to lead to wasted effort to continually explain that and deal with e.g. IETF LC's that may go wildly astray. If this group want to call what they're doing frobble and say that that's called grobble elsewhere but means the same, then that's maybe liveable but will I bet end up wasting time and effort anyway. I'd much rather not see that wasted effort myself. S. From nobody Mon Apr 14 14:41:59 2014 Return-Path: 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 514141A0769 for ; Mon, 14 Apr 2014 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 ARk_5ATrOUe0 for ; Mon, 14 Apr 2014 14:41:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id EB7811A0766 for ; Mon, 14 Apr 2014 14:41:55 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ELfDTw025888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 14:41:13 -0700 (PDT) Message-ID: <534C55FA.7070900@isi.edu> Date: Mon, 14 Apr 2014 14:41:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <534C4B16.8070503@isi.edu> <534C4CA4.7080905@cs.tcd.ie> <534C4ED9.9060808@isi.edu> <534C54AD.8000805@cs.tcd.ie> In-Reply-To: <534C54AD.8000805@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/M_DKGt4GkQTffDlS_2nqk-JuUhA Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:41:57 -0000 On 4/14/2014 2:35 PM, Stephen Farrell wrote: > > > On 04/14/2014 10:10 PM, Joe Touch wrote: > >> Agreement is definitely needed. >> > ... >> >> IMO, we can do better here. > > Depending what you mean, your two statements above could > be in conflict. Sure - let me be more precise: Agreement is preferable, but not at the expense of compromising meaning at the expense of perceived PR. > But anyway - sometimes one just has to accept being in the > rough on stuff. > > If this group use terms that are being defined elsewhere in > a confusing manner then that I think is highly likely to > lead to wasted effort to continually explain that and deal > with e.g. IETF LC's that may go wildly astray. That's happened in SAAG before (it might be a defining characteristic). I suspect their LC will be dismissive of anyone who points out the contrary, as has happened in the past. I don't know how they would handle our use of zero-ID; they might just assume that we're not using the 'best' term for PR purposes. > If this group want to call what they're doing frobble > and say that that's called grobble elsewhere but means > the same, then that's maybe liveable but will I bet end > up wasting time and effort anyway. FWIW, they're quite dismissive of the value of zero-ID security without upper layer authentication. So if they call that frobble, it might not interfere with us anyway. > I'd much rather not see that wasted effort myself. While I agree, I think trying to sync areas on terminology has proven to be the very definition of wasted effort in the IETF ;-) Joe From nobody Mon Apr 14 14:43:42 2014 Return-Path: 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 329131A076A for ; Mon, 14 Apr 2014 14:43:41 -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 g2mSOcrIUcoF for ; Mon, 14 Apr 2014 14:43:38 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 069EE1A0771 for ; Mon, 14 Apr 2014 14:43:38 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 011038B7650; Mon, 14 Apr 2014 23:43:35 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 6BE3E768054; Mon, 14 Apr 2014 23:43:34 +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 23:43:34 +0200 Message-ID: <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 23:43:34 +0200 From: MARCELO BAGNULO BRAUN To: Stephen Farrell References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> In-Reply-To: <534C483B.6030000@cs.tcd.ie> 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 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 14 Apr 2014 23:43:34 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.002 X-TM-AS-Result: No--12.784-7.0-31-1 X-imss-scan-details: No--12.784-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/wFVDmrewBZkuFSdjtq8uSrBXPf4 Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau , Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:43:41 -0000 Stephen Farrell dijo: > > > On 04/14/2014 09:25 PM, Joe Touch wrote: >> >> 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. > > FWIW, my opinion is that this work ought use whatever turns out > to be the consensus terminology that saag ends up with assuming > it does reach rough consensus, which is looking more likely now > after much discussion similar to the above. I also see no good > reason why that discussion needs to be done over here. I dont have a problem with using whatever terminology saag comes up with, but i wouldnt want to wait for them to finish their discussion before we can start, so i would like to use some terminology here that is not confusing and allow us to make progress. It doesnt have to be a cool terminology, just useful. For instance unauthenticated encryption if integrity protection of tecp streams, would that work? Regards, marcelo > > S. > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 14:48:57 2014 Return-Path: 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 807021A04E8 for ; Mon, 14 Apr 2014 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 u5B6oV5_DWvE for ; Mon, 14 Apr 2014 14:48:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 276821A0661 for ; Mon, 14 Apr 2014 14:48:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56944BE55; Mon, 14 Apr 2014 22:48:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq1wZ6Exwyic; Mon, 14 Apr 2014 22:48:44 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.30.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C93F2BE35; Mon, 14 Apr 2014 22:48:44 +0100 (IST) Message-ID: <534C57BC.8060402@cs.tcd.ie> Date: Mon, 14 Apr 2014 22:48:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> In-Reply-To: <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/sGIPbvZiFHZq7YrCzZ7nmQkp2tI Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau , Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:48:55 -0000 On 04/14/2014 10:43 PM, MARCELO BAGNULO BRAUN wrote: > I dont have a problem with using whatever terminology saag comes up > with, but i wouldnt want to wait for them to finish their discussion > before we can start, so i would like to use some terminology here that > is not confusing and allow us to make progress. Fully agree. > It doesnt have to be a cool terminology, just useful. For instance > unauthenticated encryption if integrity protection of tecp streams, > would that work? I'd say for now just get charter text that folks here like and then we can s/frobble/grobble/ later if that has rough consensus. For now, all I'm asking is to not re-do the terminology discussion here. S. From nobody Mon Apr 14 14:51:56 2014 Return-Path: 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 932801A0661 for ; Mon, 14 Apr 2014 14:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 XjScPXR1GiWr for ; Mon, 14 Apr 2014 14:51:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 498B81A04E8 for ; Mon, 14 Apr 2014 14:51:53 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ELouVV028895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 14:50:56 -0700 (PDT) Message-ID: <534C5841.7010609@isi.edu> Date: Mon, 14 Apr 2014 14:50:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , Stephen Farrell References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> In-Reply-To: <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/cvMZ89LzLKb74G436p-NoRCs9zE Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:51:54 -0000 On 4/14/2014 2:43 PM, MARCELO BAGNULO BRAUN wrote: ... > It doesnt have to be a cool terminology, just useful. For instance > unauthenticated encryption if integrity protection of tecp streams, > would that work? I can't parse that. Did you mean: "unauthenticated encryption and integrity protection of tcp streams" If so, +1 Joe From nobody Mon Apr 14 14:57:00 2014 Return-Path: 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 3E3E61A04AB for ; Mon, 14 Apr 2014 14:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 s9ZbFWuWWUSc for ; Mon, 14 Apr 2014 14:56:57 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B522A1A0230 for ; Mon, 14 Apr 2014 14:56:57 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ELuGNi000460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 14:56:16 -0700 (PDT) Message-ID: <534C5980.7060908@isi.edu> Date: Mon, 14 Apr 2014 14:56:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> <534C57BC.8060402@cs.tcd.ie> In-Reply-To: <534C57BC.8060402@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/OWI_o6IpyA_TqA4KtOVyE2FXzeM Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:56:59 -0000 On 4/14/2014 2:48 PM, Stephen Farrell wrote: ... > For now, all I'm asking is to not re-do the terminology discussion > here. Sounds good to me, but would necessarily require avoiding existing ambiguous terminology. So "opportunistic FOO" shouldn't be used. If we say "unauthenticated", we need to be clear that we're talking about avoiding a tie to an external identity. Some still call the association of the segments in a single connection to be authenticated as being from the same stream, though - and that's more than "unauthenticated" might imply. So AFAICT, we want: - MUST NOT require external identity MUST allow external identity if available and desired - MUST provide integrity protection, including tamper and replay prevention - MUST authenticate segments as being associated with a given TCP connection - MUST provide payload confidentiality Maybe it's sufficient to just list these individual requirements, and not give it a name. Joe From nobody Mon Apr 14 14:58:28 2014 Return-Path: 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 676461A0218 for ; Mon, 14 Apr 2014 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 HwKIAdUE0H8U for ; Mon, 14 Apr 2014 14:58:26 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A0D051A03F3 for ; Mon, 14 Apr 2014 14:58:23 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ELvuuU000942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 14:57:57 -0700 (PDT) Message-ID: <534C59E5.1010504@isi.edu> Date: Mon, 14 Apr 2014 14:57:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN , Daniel Kahn Gillmor References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <534B4B40.1000901@fifthhorseman.net> <20140414172048.kgedo0agsg80ws0w@webcartero01.uc3m.es> In-Reply-To: <20140414172048.kgedo0agsg80ws0w@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/OSIaltCTdjjV7-qLNxJofZYne7E Cc: David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:58:27 -0000 On 4/14/2014 8:20 AM, MARCELO BAGNULO BRAUN wrote: > Thanks, will use these and Andrea's text in the next version of the charter PS - can you post an update so we can get back on the same page? (even if it's rough) Thanks, Joe From nobody Mon Apr 14 15:02:35 2014 Return-Path: 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 010231A0230 for ; Mon, 14 Apr 2014 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 zmx3zPBQasDV for ; Mon, 14 Apr 2014 15:02:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 508361A0218 for ; Mon, 14 Apr 2014 15:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02EFABE55; Mon, 14 Apr 2014 23:02:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZJ6NxBYWgD3; Mon, 14 Apr 2014 23:02:26 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.30.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07F80BE39; Mon, 14 Apr 2014 23:02:26 +0100 (IST) Message-ID: <534C5AF1.6080205@cs.tcd.ie> Date: Mon, 14 Apr 2014 23:02:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> <534C57BC.8060402@cs.tcd.ie> <534C5980.7060908@isi.edu> In-Reply-To: <534C5980.7060908@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ImKUD_l5mZ28XV41RzDZ1tMOyPc Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:02:33 -0000 On 04/14/2014 10:56 PM, Joe Touch wrote: > > > On 4/14/2014 2:48 PM, Stephen Farrell wrote: > ... >> For now, all I'm asking is to not re-do the terminology discussion >> here. > > Sounds good to me, but would necessarily require avoiding existing > ambiguous terminology. > > So "opportunistic FOO" shouldn't be used. > > If we say "unauthenticated", we need to be clear that we're talking > about avoiding a tie to an external identity. Some still call the > association of the segments in a single connection to be authenticated > as being from the same stream, though - and that's more than > "unauthenticated" might imply. > > So AFAICT, we want: > > - MUST NOT require external identity > MUST allow external identity if available and desired > > - MUST provide integrity protection, including tamper and > replay prevention > > - MUST authenticate segments as being associated with > a given TCP connection > > - MUST provide payload confidentiality > > Maybe it's sufficient to just list these individual requirements, and > not give it a name. That approach looks reasonable to me and has the benefit of better precision. I assume there's also a bunch of MUST NOTs that might be added as we go, e.g. MUST NOT allow reflection attacks. But the above look like the main ones that'd need to be clear at the start. S. > > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > From nobody Mon Apr 14 15:13:40 2014 Return-Path: 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 773D61A023A for ; Mon, 14 Apr 2014 15:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 MWgDbEpBmxY8 for ; Mon, 14 Apr 2014 15:13:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A51A0687 for ; Mon, 14 Apr 2014 15:13:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EMCm7L005862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 15:12:48 -0700 (PDT) Message-ID: <534C5D60.1030803@isi.edu> Date: Mon, 14 Apr 2014 15:12:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , MARCELO BAGNULO BRAUN References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> <534C57BC.8060402@cs.tcd.ie> <534C5980.7060908@isi.edu> <534C5AF1.6080205@cs.tcd.ie> In-Reply-To: <534C5AF1.6080205@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/lq1DX3lZYmosI2zZuc97nAGsaXQ Cc: Erik Nygren , John-Mark Gurney , tcpcrypt@ietf.org, Andrea Bittau 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:13:36 -0000 On 4/14/2014 3:02 PM, Stephen Farrell wrote: > > > On 04/14/2014 10:56 PM, Joe Touch wrote: >> >> >> On 4/14/2014 2:48 PM, Stephen Farrell wrote: >> ... >>> For now, all I'm asking is to not re-do the terminology discussion >>> here. >> >> Sounds good to me, but would necessarily require avoiding existing >> ambiguous terminology. >> >> So "opportunistic FOO" shouldn't be used. >> >> If we say "unauthenticated", we need to be clear that we're talking >> about avoiding a tie to an external identity. Some still call the >> association of the segments in a single connection to be authenticated >> as being from the same stream, though - and that's more than >> "unauthenticated" might imply. >> >> So AFAICT, we want: >> >> - MUST NOT require external identity >> MUST allow external identity if available and desired >> >> - MUST provide integrity protection, including tamper and >> replay prevention >> >> - MUST authenticate segments as being associated with >> a given TCP connection >> >> - MUST provide payload confidentiality >> >> Maybe it's sufficient to just list these individual requirements, and >> not give it a name. > > That approach looks reasonable to me and has the benefit of > better precision. > > I assume there's also a bunch of MUST NOTs that might be > added as we go, e.g. MUST NOT allow reflection attacks. Sure - I'd add that as a positive, and state it in a section on key management: Ephemeral session key coordination... MUST prevent reflection attacks MUST use unique ephemeral keys for each distinct TCP connection MUST support key rollover without disrupting an ongoing connection As I've already noted, though, that coordination might be "out of band" (Marcelo prefers the term "external"). Joe From nobody Mon Apr 14 15:18:29 2014 Return-Path: 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 6FF321A0687 for ; Mon, 14 Apr 2014 15:18:27 -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 2i82Bdn89HPs for ; Mon, 14 Apr 2014 15:18:25 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0487A1A023B for ; Mon, 14 Apr 2014 15:18:24 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BC592FA4990; Tue, 15 Apr 2014 00:18:21 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 0D6F9C73E34; Tue, 15 Apr 2014 00:18:20 +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; Tue, 15 Apr 2014 00:18:20 +0200 Message-ID: <20140415001820.qrnix1aybogoc40s@webcartero01.uc3m.es> Date: Tue, 15 Apr 2014 00:18:20 +0200 From: MARCELO BAGNULO BRAUN To: Joe Touch References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <534B4B40.1000901@fifthhorseman.net> <20140414172048.kgedo0agsg80ws0w@webcartero01.uc3m.es> <534C59E5.1010504@isi.edu> In-Reply-To: <534C59E5.1010504@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 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Tue, 15 Apr 2014 00:18:21 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.002 X-TM-AS-Result: No--10.444-7.0-31-1 X-imss-scan-details: No--10.444-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/PgHri7lM5Zs_kTbPid45LL8y3Gg Cc: David Mazieres expires 2014-04-06 PDT , Andrea Bittau , tcpcrypt@ietf.org, Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:18:27 -0000 Joe Touch dijo: > > > On 4/14/2014 8:20 AM, MARCELO BAGNULO BRAUN wrote: >> Thanks, will use these and Andrea's text in the next version of the charter > > PS - can you post an update so we can get back on the same page? > > (even if it's rough) > i will do so next week (believe it or not, i am actually in holidays this week!) > Thanks, > > Joe > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 15:18:41 2014 Return-Path: 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 81E111A0757 for ; Mon, 14 Apr 2014 15:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 x0YItoWKN_8F for ; Mon, 14 Apr 2014 15:18:34 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id DB99F1A0762 for ; Mon, 14 Apr 2014 15:18:34 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 4194C60CE for ; Mon, 14 Apr 2014 15:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=Ly8V3WQHs9X09Pa1o5Ty2Zvd2so=; b=QM Fki1655RlailjabaCL0ETYkxsZY1eWBC3EWNK1QUCVu22FyA0gcILkYUkICK8gPF dahJeTOqJ4pHeeq3h5oIETBVSaf/QJOtlGxHDN5q2wvQsz6TwGamtS/Wjl4lUUPd 6+72RTi6V4Hz3SgjHOgbPM/wgWRCyFqEaFjvB1UtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=IKHkvaS5LB/QLfEw4UNcQcvygQUm lQaAlFyszA8++XjcOZbQEv4d29qtkIwhYFubt9iyAqQMj7NWwvDCjl3FM1Rt8cEC rPcrU3AUGa4G92fTBhxRYNl+QvIRP7YNtyH9j7PexHptrq1YPSZEM87fJuqddkrl HeGqh2QcDd6r3uw= Received: by banjo.employees.org (Postfix, from userid 1736) id 2E0F860C9; Mon, 14 Apr 2014 15:18:32 -0700 (PDT) Date: Mon, 14 Apr 2014 15:18:32 -0700 From: Derek Fawcus To: tcpcrypt@ietf.org Message-ID: <20140414221832.GA61630@banjo.employees.org> References: <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/tIeBDIIx0iCOwcFyLwwq1o1CzDI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:18:39 -0000 On Mon, Apr 14, 2014 at 10:39:51pm +0200, MARCELO BAGNULO BRAUN wrote: > my main concern is with tcp option space [snip] > if we send the mac in the tcp options, well, we use a lot of option > space and we are conflicting with other uses of the optcion space, So then, should we also take on the work of defining how to negotiate an increased option space? I seem to recall that was previously mentioned (on tcpm?), but don't know if it got anywhere. .pdf From nobody Mon Apr 14 15:35:17 2014 Return-Path: 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 2C2661A077C for ; Mon, 14 Apr 2014 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 3MgmPiqBmJ_b for ; Mon, 14 Apr 2014 15:35:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 21A231A0776 for ; Mon, 14 Apr 2014 15:35:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3EMYrhH012225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 15:34:53 -0700 (PDT) Message-ID: <534C628D.7080706@isi.edu> Date: Mon, 14 Apr 2014 15:34:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Derek Fawcus , tcpcrypt@ietf.org References: <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> <20140414221832.GA61630@banjo.employees.org> In-Reply-To: <20140414221832.GA61630@banjo.employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/DP_DVsve4xKSJ6cpWXi1oank7pU 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:35:16 -0000 On 4/14/2014 3:18 PM, Derek Fawcus wrote: > On Mon, Apr 14, 2014 at 10:39:51pm +0200, MARCELO BAGNULO BRAUN wrote: >> my main concern is with tcp option space > [snip] >> if we send the mac in the tcp options, well, we use a lot of option >> space and we are conflicting with other uses of the optcion space, > > So then, should we also take on the work of defining how to negotiate > an increased option space? That's been discussed in TCPM many times before... > I seem to recall that was previously mentioned (on tcpm?), > but don't know if it got anywhere. There's provably no way to do that in a backward-compatible way for the SYN (where it's really needed). It's trivial for later segments (just make a new option and handshake during the SYN), but it could break middleboxes. Not sure if that's needed, though - see the analysis in the TCP-AO doc about option space. You shouldn't need fields other than are basically need for TCP-AO. Joe From nobody Mon Apr 14 15:41:26 2014 Return-Path: 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 5FF4A1A0465 for ; Mon, 14 Apr 2014 15:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 KpCIn8yVGEq5 for ; Mon, 14 Apr 2014 15:41:23 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC9EF1A0470 for ; Mon, 14 Apr 2014 15:41:22 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3EMfAhH049515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 15:41:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3EMf9BI049514; Mon, 14 Apr 2014 15:41:09 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Apr 2014 15:41:09 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140414224109.GK43976@funkthat.com> References: <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> <534C483B.6030000@cs.tcd.ie> <20140414234334.1tp2af300s4os04o@webcartero01.uc3m.es> <534C57BC.8060402@cs.tcd.ie> <534C5980.7060908@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C5980.7060908@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Apr 2014 15:41:10 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/H0sx-ttFmjRf8aSUHS8X5rDqx28 Cc: MARCELO BAGNULO BRAUN , Erik Nygren , Andrea Bittau , tcpcrypt@ietf.org, Stephen Farrell 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:41:24 -0000 Joe Touch wrote this message on Mon, Apr 14, 2014 at 14:56 -0700: > On 4/14/2014 2:48 PM, Stephen Farrell wrote: > ... > >For now, all I'm asking is to not re-do the terminology discussion > >here. > > Sounds good to me, but would necessarily require avoiding existing > ambiguous terminology. > > So "opportunistic FOO" shouldn't be used. > > If we say "unauthenticated", we need to be clear that we're talking > about avoiding a tie to an external identity. Some still call the > association of the segments in a single connection to be authenticated > as being from the same stream, though - and that's more than > "unauthenticated" might imply. > > So AFAICT, we want: > > - MUST NOT require external identity > MUST allow external identity if available and desired > > - MUST provide integrity protection, including tamper and > replay prevention > > - MUST authenticate segments as being associated with > a given TCP connection > > - MUST provide payload confidentiality > > Maybe it's sufficient to just list these individual requirements, and > not give it a name. These look good... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Apr 14 20:47:54 2014 Return-Path: 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 251261A0743 for ; Mon, 14 Apr 2014 20:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 sHsyJeKY64Cz for ; Mon, 14 Apr 2014 20:47:48 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id D588E1A0198 for ; Mon, 14 Apr 2014 20:47:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3F3lhNs030770 for ; Mon, 14 Apr 2014 23:47:43 -0400 Received: (qmail 30205 invoked by uid 0); 15 Apr 2014 03:47:42 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 15 Apr 2014 03:47:42 -0000 Message-ID: <534CABDB.2040506@mti-systems.com> Date: Mon, 14 Apr 2014 23:47:39 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Derek Fawcus , tcpcrypt@ietf.org References: <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> <20140414221832.GA61630@banjo.employees.org> In-Reply-To: <20140414221832.GA61630@banjo.employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xtlgyJl0-MkzS-AAgGZUwrWwjh8 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 03:47:50 -0000 On 4/14/2014 6:18 PM, Derek Fawcus wrote: > On Mon, Apr 14, 2014 at 10:39:51pm +0200, MARCELO BAGNULO BRAUN wrote: >> my main concern is with tcp option space > [snip] >> if we send the mac in the tcp options, well, we use a lot of option >> space and we are conflicting with other uses of the optcion space, > > So then, should we also take on the work of defining how to negotiate > an increased option space? > > I seem to recall that was previously mentioned (on tcpm?), > but don't know if it got anywhere. > Joe summarized the situation well. One I-D discussing it is: http://tools.ietf.org/html/draft-eddy-tcp-loo-04 -- Wes Eddy MTI Systems From nobody Tue Apr 15 00:28:23 2014 Return-Path: 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 5AF681A0392 for ; Tue, 15 Apr 2014 00:28:20 -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 ft6zvaUyLYNs for ; Tue, 15 Apr 2014 00:28:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6E1A026D for ; Tue, 15 Apr 2014 00:28:16 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 37067CD6136 for ; Tue, 15 Apr 2014 09:28:13 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 2A9F4CD6134 for ; Tue, 15 Apr 2014 09:28:12 +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; Tue, 15 Apr 2014 09:28:12 +0200 Message-ID: <20140415092812.od0qeg188wg8oc0w@webcartero01.uc3m.es> Date: Tue, 15 Apr 2014 09:28:12 +0200 From: MARCELO BAGNULO BRAUN To: tcpcrypt@ietf.org References: <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> <20140414221832.GA61630@banjo.employees.org> <534C628D.7080706@isi.edu> In-Reply-To: <534C628D.7080706@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); Tue, 15 Apr 2014 09:28:13 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/8dJqQQ8T_XM8HVZHPvF493wu0NU 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 07:28:20 -0000 Joe Touch dijo: > > > On 4/14/2014 3:18 PM, Derek Fawcus wrote: >> On Mon, Apr 14, 2014 at 10:39:51pm +0200, MARCELO BAGNULO BRAUN wrote: >>> my main concern is with tcp option space >> [snip] >>> if we send the mac in the tcp options, well, we use a lot of option >>> space and we are conflicting with other uses of the optcion space, >> >> So then, should we also take on the work of defining how to negotiate >> an increased option space? > > That's been discussed in TCPM many times before... > >> I seem to recall that was previously mentioned (on tcpm?), >> but don't know if it got anywhere. > > There's provably no way to do that in a backward-compatible way for > the SYN (where it's really needed). mmm, interestingly enough, for this, i believe it is also an issue in the rest of packets, as all packets need to carry the mac and it eats up option space for all packets. Moreover, if you add sack and mptcp then it is a potential problem not only for syns. So, i would say that it would be valuable to have extended tcp options if only for non syn packets. OTOH, i dont think this would be in scope for this wg, it belongs to tcpm. But this and mptcp could be good motivations for pushing it in tcpm. > > It's trivial for later segments (just make a new option and > handshake during the SYN), but it could break middleboxes. Not sure right, is there any experimental study if that is the case? > if that's needed, though - see the analysis in the TCP-AO doc about > option space. You shouldn't need fields other than are basically need > for TCP-AO. > well, as i said earlier, when you add to the mix mptcp, then things become pretty tight, i believe Regards, marcelo > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Tue Apr 15 00:57:37 2014 Return-Path: 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 E92461A031E for ; Tue, 15 Apr 2014 00:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ddo0e0FMfVUe for ; Tue, 15 Apr 2014 00:57:30 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38A1A0393 for ; Tue, 15 Apr 2014 00:57:29 -0700 (PDT) Received: from pc114.netlab.hut.fi (130.233.154.114) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 53469565005D8E1A; Tue, 15 Apr 2014 10:57:16 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Pasi Sarolahti In-Reply-To: <16087_1397533678_534CABEE_16087_119_1_534CABDB.2040506@mti-systems.com> Date: Tue, 15 Apr 2014 10:57:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC63F43-9F04-42B9-8B5D-5F99447D52E8@iki.fi> References: <20140413204202.GJ34745@funkthat.com> <534B6D5E.1000003@isi.edu> <20140414163222.GW34745@funkthat.com> <534C11F2.3030607@isi.edu> <20140414212743.0pb8ilb4gocskos0@webcartero01.uc3m.es> <534C3A74.9050109@isi.edu> <534C3E9A.9080707@mti-systems.com> <20140414222206.tpy3rfnef44g4wgg@webcartero01.uc3m.es> <534C450F.5010808@isi.edu> <20140414223951.dxh8n99o1wkksgks@webcartero01.uc3m.es> <20140414221832.GA61630@banjo.employees.org> <16087_1397533678_534CABEE_16087_119_1_534CABDB.2040506@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/K-FwsTDVC9hgbEa0fLpR1EVcfaU Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 07:57:35 -0000 On 15 Apr 2014, at 06:47, Wesley Eddy wrote: >> So then, should we also take on the work of defining how to = negotiate >> an increased option space? >>=20 >> I seem to recall that was previously mentioned (on tcpm?), >> but don't know if it got anywhere. >=20 > Joe summarized the situation well. One I-D discussing it is: > http://tools.ietf.org/html/draft-eddy-tcp-loo-04 This idea comes up every once in a while. Perhaps it would be useful to = describe the issues in a small informational RFC? - Pasi From nobody Wed Apr 16 06:19:03 2014 Return-Path: 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 E6A6C1A0188 for ; Wed, 16 Apr 2014 06:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5-VKgLnOdVHF for ; Wed, 16 Apr 2014 06:18:59 -0700 (PDT) Received: from mail-la0-x244.google.com (mail-la0-x244.google.com [IPv6:2a00:1450:4010:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1F1A0187 for ; Wed, 16 Apr 2014 06:18:59 -0700 (PDT) Received: by mail-la0-f68.google.com with SMTP id pv20so2573355lab.11 for ; Wed, 16 Apr 2014 06:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IUPFKKRB6c+mBPfkqu0f++gqngLCJqZ5pVqIjCEgyJI=; b=n8vh4NYhkK5Yif59PAGD/Pt6yFO4ELrUHLATxXCBCKq1XnrhwVOYCiRr0nLqWJKNdp cANzM3mg93Ms761eK+xiQWd1i35CL+0hIS115L4U+oggzufqMNJSCbM5lH2yDDPZSaie b7wNj761RtTo0tkqpG2HrXS37fTZBnJsrLgSMrxkydrTeKZU35tj/26j4ZmKL+tDTCSZ 55iop0rMOZW0PzzqygmeVO1E9adVXTWR1yhRSx9or9mDH4xqffav/AdiFb/7HUFiJqqK NEXwrxrb+UvvjtE5X/iuD76ZpAFNmWeQmvI9wf3M8KK0OL2Ztg1817GLL7BqTICJHknM 1I2w== MIME-Version: 1.0 X-Received: by 10.152.43.107 with SMTP id v11mr1365320lal.49.1397654335251; Wed, 16 Apr 2014 06:18:55 -0700 (PDT) Received: by 10.112.46.196 with HTTP; Wed, 16 Apr 2014 06:18:55 -0700 (PDT) Date: Wed, 16 Apr 2014 20:18:55 +0700 Message-ID: From: Barasu Barasu To: tcpcrypt@ietf.org Content-Type: multipart/alternative; boundary=001a11c350802bea2004f728c226 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/sBPxALrC2qnHvF2axyT_c-67O1A Subject: [Tcpcrypt] Installing Tcpcrypt X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:19:01 -0000 --001a11c350802bea2004f728c226 Content-Type: text/plain; charset=UTF-8 Hi I really need to install Tcpcrypt. However, I find it very difficult to install and build the binary. Would you please create a video tutorial for me? I have followed instructions on installation but as I am not a computer expert I find t difficult to install. Please help me. Please advice. Regards Barasu --001a11c350802bea2004f728c226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

I rea= lly need to install Tcpcrypt. However, I find it very difficult to install = and build the binary. Would you please create a video tutorial for me?
I have followed = instructions on installation but as I am not a computer expert I find t dif= ficult to install. Please help me. Please advice.

Regard= s
Barasu
--001a11c350802bea2004f728c226-- From nobody Wed Apr 16 06:36:37 2014 Return-Path: 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 ECBFB1A019C for ; Wed, 16 Apr 2014 06:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 THIJZA5J4TDf for ; Wed, 16 Apr 2014 06:36:34 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25C1A019D for ; Wed, 16 Apr 2014 06:36:29 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b57so8765759eek.26 for ; Wed, 16 Apr 2014 06:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RlosiJHb37Upfy1rpyH/ahjcWr2dBArJgNGv7zpRhb0=; b=toSofqVSXT1Ur3NBS2BrGZiiuCrEBESQkXtNVVMIRHReKahGXI3ABw3uf9jXX6CAVZ LcbFAt1QOCX0RW8p9r0yWTHEoOU/MrTQvBlDPRMkNvmIgz/DpbruR0KIgTf6FvnVKWUZ r7rrLiznYafJ0lNQgdrKYx5jHFh0RCf3LU5SfTi1+rXYKakxbV3F5oRjNzhI4SGs07SS xr6gxnrIX4f8nXEP8MOWYUBAg7HVfN9OkXfc3CMgCi/Hg/I78y/RNwWDZjBAFYzqmMcr 279Is1MHpL5T4Yu+9MxQ3+G7tcmC1jgmyC77luGf98/5RvewV8QYcEotCQItBzaafDN5 J5ww== X-Received: by 10.14.214.198 with SMTP id c46mr5305090eep.29.1397655385803; Wed, 16 Apr 2014 06:36:25 -0700 (PDT) Received: from ?IPv6:2001:1a80:2803:7c00:3193:7387:b649:1601? ([2001:1a80:2803:7c00:3193:7387:b649:1601]) by mx.google.com with ESMTPSA id g3sm58096731eet.35.2014.04.16.06.36.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 06:36:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Martin Stiemerling In-Reply-To: Date: Wed, 16 Apr 2014 15:36:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <117B62DF-F32D-48AC-882A-E4B10901A5C5@gmail.com> References: To: Barasu Barasu X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/TjCcFLCWcnn_feQ6t4Rki-IQ6XQ Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Installing Tcpcrypt X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:36:37 -0000 Hi,=20 This list is not support questions about the tcpcrypt implementation. = Please do not post this type of questions here.=20 This list for discussing on how to add encryption directly to TCP.=20 Thanks,=20 Martin Stiemerling IETF Transport Area Director Am 16.04.2014 um 15:18 schrieb Barasu Barasu : > Hi=20 >=20 > I really need to install Tcpcrypt. However, I find it very difficult = to install and build the binary. Would you please create a video = tutorial for me? > I have followed instructions on installation but as I am not a = computer expert I find t difficult to install. Please help me. Please = advice. >=20 > Regards > Barasu > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Tue Apr 22 23:14:55 2014 Return-Path: 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 2A6651A0328 for ; Tue, 22 Apr 2014 23:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 zyrIwd6Vp3pZ for ; Tue, 22 Apr 2014 23:14:50 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2B1A00B4 for ; Tue, 22 Apr 2014 23:14:49 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A13728ABAE9 for ; Wed, 23 Apr 2014 08:14:43 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (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 950AD89DD93 for ; Wed, 23 Apr 2014 08:14:43 +0200 (CEST) Message-ID: <53575A81.300@it.uc3m.es> Date: Wed, 23 Apr 2014 08:15:29 +0200 From: marcelo bagnulo braun 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 CC: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> In-Reply-To: <534ACCE5.2080103@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-20650.005 X-TM-AS-Result: No--18.848-7.0-31-1 X-imss-scan-details: No--18.848-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/vLbPEY8IGNyYOVGK8_FufrGXHU8 Subject: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:14:53 -0000 I am working on the new version of the charter and i was thinking about this. below... El 13/04/14 19:44, Joe Touch escribió: > > > On 4/13/2014 9:45 AM, Erik Nygren wrote: >> Thank you for this summary. >> >> Along the lines of application hooks, do we want a way for the >> application layer to be able to safely disable encryption part way >> through a connection? > I think this may be a useful thing to do, but i am unconvinced we shoudl explicitly mention it in the charter. My suggestion would be to leave it for discussion and not mention it in the charter. I do think we should include a requirement on avoiding double encryption when is possible (notable with TLS) Regards, marcelo > TCP has no mechanism to do a new handshake mid-connection. Once an > option is set during the initial handshake, it should be assumed to be > persistent across the connection. > > A better solution, if the goal is to be lightweight, is to change > keying parameters during the connection, at which point the new > parameter can be "null". > > See again TCP-AO for an exampple of how to coordinate keying parameter > IDs. > >> A side-note on NATs: authenticating RSTs could be problematic when a >> NAT times out a connection and starts reusing source ports (perhaps for >> a different client to the same server), especially if the client and >> server on either end using tcpcrypt are unaware of this. There are a >> bunch of annoying corner-cases in this area. > > This issue was discussed in TCP-AO too; IMO, the recommendation there > (for authentication) is just as relevant here. > > Joe > > > From nobody Tue Apr 22 23:16:13 2014 Return-Path: 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 A5C921A00B4 for ; Tue, 22 Apr 2014 23:16: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 yphX2S1PmROJ for ; Tue, 22 Apr 2014 23:16:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 173FC1A0096 for ; Tue, 22 Apr 2014 23:16:08 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6FC7BCD5FB5 for ; Wed, 23 Apr 2014 08:16:01 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 6443FCD5498 for ; Wed, 23 Apr 2014 08:16:01 +0200 (CEST) Message-ID: <53575ACF.2010701@it.uc3m.es> Date: Wed, 23 Apr 2014 08:16:47 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACC3E.1020308@isi.edu> In-Reply-To: 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-20650.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/jAc7JlZYfVHbA20Q9tFKCr1tXsY 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:16:12 -0000 El 13/04/14 19:54, Erik Nygren escribió: > On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch > wrote: > > > You need to MAC the IP dest, dest port, and all signal bits in the > IP header (sequence, flags, etc.). This will still make it through > a NAT, but will break a 'rewriting proxy' - but that's the kind of > attack that TCP crypto ought to protect against, because it's > indistinguishable from a MITM attack (it *is* a MITM). > > Unfortunately, applying a MAC on the IP dest will break NAT64 which is > a valid and increasingly critial use-case. > I dont understand why NAT64 is different than regular NAT44, is it? > Erik > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Tue Apr 22 23:44:55 2014 Return-Path: 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 A442C1A0329 for ; Tue, 22 Apr 2014 23:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 rip_tj7myeO4 for ; Tue, 22 Apr 2014 23:44:49 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id D6BFC1A0089 for ; Tue, 22 Apr 2014 23:44:48 -0700 (PDT) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C9E5019813A; Wed, 23 Apr 2014 08:44:31 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be C9E5019813A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1398235471; bh=yaVp0pNb8b3mP12ykmfPjhKl0jzopMXVo9cMrdsr3vo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H9BE8EnIwwDrdQTEajvJ1BpLeN29F2L6cJSdIK+K5sGtpimcw3D7ASDq/QlL9eCzX E9aLNhLzieHJQ6k5RznYuPiCMUOLyNLbE9CKRx1WlhBHcH4mBKTdiqQZMCHtCiFqq2 2G+MQLqHHy0rSk1VO+iHjWT0FbEm0ROFPKPJGMkc= Message-ID: <5357614F.3060109@uclouvain.be> Date: Wed, 23 Apr 2014 08:44:31 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> In-Reply-To: <53575A81.300@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: C9E5019813A.A3AE3 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/OnpdfNxKvj792bBdBt830tEuqIA Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: Draft charter text X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:44:53 -0000 Marcelo, > > El 13/04/14 19:44, Joe Touch escribió: >> >> >> On 4/13/2014 9:45 AM, Erik Nygren wrote: >>> Thank you for this summary. >>> >>> Along the lines of application hooks, do we want a way for the >>> application layer to be able to safely disable encryption part way >>> through a connection? >> > > I think this may be a useful thing to do, but i am unconvinced we shoudl > explicitly mention it in the charter. My suggestion would be to leave it > for discussion and not mention it in the charter. > > I do think we should include a requirement on avoiding double encryption > when is possible (notable with TLS) One solution could be to allow a renegotiation of the crypto algorithm used (in addition to the keys) and support null encryption. This would allow to effectively disable encryption during the connection but would bring more advanced capabilities Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Apr 23 00:02:02 2014 Return-Path: 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 D47701A0341 for ; Wed, 23 Apr 2014 00:01:44 -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 QHUWCaFn2Nx5 for ; Wed, 23 Apr 2014 00:01:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF31A0339 for ; Wed, 23 Apr 2014 00:01:30 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CB21C1184D02 for ; Wed, 23 Apr 2014 09:01:24 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (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 A624B1184D00 for ; Wed, 23 Apr 2014 09:01:24 +0200 (CEST) Message-ID: <53576572.5030805@it.uc3m.es> Date: Wed, 23 Apr 2014 09:02:10 +0200 From: marcelo bagnulo braun 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20650.005 X-TM-AS-Result: No--17.218-7.0-31-1 X-imss-scan-details: No--17.218-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/6TjtmuMWLdV9RKGZ-v28bP4RZek Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 07:01:45 -0000 Hi, Thanks for the lively discussion on the charter text. I attach a new version of the charter trying to include the received comments. I have tried to be carefull using the should and the must, so please look into those. I tried to reflect the different levels of requirements for the resulting protocol. As usual comments are welcome. TCP Increased Security (TCP Inc.) The TCP Inc. WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define the TCP extensions to perform an unauthenticated key exchange resulting in encryption without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man-in-the-middle attacks. This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring (see draft-farrell-perpass-attack). The working group is looking to produce experimental documents specifying the required TCP extensions and any additional informational documents needed. The high-level requirements for the protocol for providing TCP unauthenticated encryption and integrity protection are: - Deployable and usable without significant changes to existing Internet infrastructure, in particular it must be compatible with NATs (at the very minimum with the NATs that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508); - The protocol must be usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be changed in a backward compatible way. It also provides some protection in scenarios where people are unwilling to do any change just for the sake of security (e.g., like configure encryption in an application). - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Must gracefully fall-back to TCP if the remote peer does not support the proposed extensions - When encryption is enabled, it must always provide forward secrecy. - When encryption is enabled, it must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or not be protected) - When encryption is enabled, it must always provide payload encryption. - Should attempt to use the least amount of TCP option space. - Must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance. For example, the protocol may try to re-use existing cryptographic material for future communication between the same endpoints to avoid expensive public key operations on connection set up. - Hooks for allowing upper layers to disable encryption must be made available. The protocol may try to avoid redundant encryption when it is possible e.g. by detecting encryption performed by upper layers (notably, when TLS is used). - No extra linkability: when encryption is enabled the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - Client fingerprinting: some clients may want to avoid appearing as the same client when connecting to a remote peer on subsequent occasions. This should either be the default (clients cannot be "fingerprinted" by the server based on shared state) or some mechanism should be available for clients to drop or ignore shared state to avoid being fingerprintable. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for unauthenticated encryption and integrity protection of TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with external authentication mechanisms, the expected protection, privacy considerations and residual threats. - Extensions to current TCP to support unauthenticated key exchange and encryption and integrity protection. This covers all the protocol changes required. This will be a experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting external authentication will be defined in this document and the hooks for disabling encryption. This will be an informational document. From nobody Wed Apr 23 00:04:11 2014 Return-Path: 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 B76CE1A0329 for ; Wed, 23 Apr 2014 00:04:09 -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 wfcpibC4gTG5 for ; Wed, 23 Apr 2014 00:04:07 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA01A032E for ; Wed, 23 Apr 2014 00:04:07 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 76971C36079; Wed, 23 Apr 2014 09:04:00 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 687F9CB7BC8; Wed, 23 Apr 2014 09:04:00 +0200 (CEST) Message-ID: <5357660E.3040707@it.uc3m.es> Date: Wed, 23 Apr 2014 09:04:46 +0200 From: marcelo bagnulo braun 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: Olivier.Bonaventure@uclouvain.be References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> In-Reply-To: <5357614F.3060109@uclouvain.be> 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-20650.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/3eBrlfcmA-y4a8jENfKEss8TENc Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 07:04:09 -0000 El 23/04/14 08:44, Olivier Bonaventure escribió: > Marcelo, >> >> El 13/04/14 19:44, Joe Touch escribió: >>> >>> >>> On 4/13/2014 9:45 AM, Erik Nygren wrote: >>>> Thank you for this summary. >>>> >>>> Along the lines of application hooks, do we want a way for the >>>> application layer to be able to safely disable encryption part way >>>> through a connection? >>> >> >> I think this may be a useful thing to do, but i am unconvinced we shoudl >> explicitly mention it in the charter. My suggestion would be to leave it >> for discussion and not mention it in the charter. >> >> I do think we should include a requirement on avoiding double encryption >> when is possible (notable with TLS) > > One solution could be to allow a renegotiation of the crypto algorithm > used (in addition to the keys) and support null encryption. This would > allow to effectively disable encryption during the connection but > would bring more advanced capabilities > yes, Joe suggested this earlier on, that is why i think it should not be very hard to support. My question was more in the charter context, whether we should include this explicitly there or leave it open for the WG to consider and i was slightly inclined to leave it for the WG to decide. Regards, marcelo > > Olivier > > From nobody Wed Apr 23 04:55:23 2014 Return-Path: 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 B62641A0339 for ; Wed, 23 Apr 2014 04:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 6gmr_AKZHQL9 for ; Wed, 23 Apr 2014 04:55:21 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 633BE1A0341 for ; Wed, 23 Apr 2014 04:55:21 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s3NBtDf9014403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 06:55:14 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s3NBtC7N010052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 13:55:12 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 23 Apr 2014 13:55:12 +0200 From: "Scharf, Michael (Michael)" To: marcelo bagnulo braun , "tcpcrypt@ietf.org" Thread-Topic: [Tcpcrypt] New version of the charter text Thread-Index: AQHPXsIKv8txL5azDkSSJGABrZdzP5sfFw0w Date: Wed, 23 Apr 2014 11:55:11 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2C0D53@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <53576572.5030805@it.uc3m.es> In-Reply-To: <53576572.5030805@it.uc3m.es> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bZRWEDz_5lKPZM6P7qmRGx1yb-A 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 11:55:22 -0000 > Thanks for the lively discussion on the charter text. > I attach a new version of the charter trying to include the received > comments. > I have tried to be carefull using the should and the must, so please > look into those. Would draft-paddon-tcposp-01 be within the proposed charter? Michael From nobody Wed Apr 23 09:13:41 2014 Return-Path: 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 371BA1A0375 for ; Wed, 23 Apr 2014 09:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1PLbAKXiiR5g for ; Wed, 23 Apr 2014 09:13:37 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0F1A0272 for ; Wed, 23 Apr 2014 09:13:36 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s3NGDVYp021118; Wed, 23 Apr 2014 09:13:31 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1ke6tj9fkg-8 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 09:13:31 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 23 Apr 2014 09:13:23 -0700 From: Paul Lambert To: marcelo bagnulo braun , "Olivier.Bonaventure@uclouvain.be" , "tcpcrypt@ietf.org" Date: Wed, 23 Apr 2014 09:14:08 -0700 Thread-Topic: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: Draft charter text Thread-Index: Ac9fDvLGYD2Vzvt1SeKzTdSV9AgCTw== Message-ID: References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> In-Reply-To: <5357660E.3040707@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-23_04:2014-04-23,2014-04-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404230246 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/C_WUYYR5OWyPdvCCoHuirXOMduU Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:13:39 -0000 On 4/23/14, 12:04 AM, "marcelo bagnulo braun" wrote: >El 23/04/14 08:44, Olivier Bonaventure escribi=F3: >> Marcelo, >>> >>> El 13/04/14 19:44, Joe Touch escribi=F3: >>>> >>>> >>>> On 4/13/2014 9:45 AM, Erik Nygren wrote: >>>>> Thank you for this summary. >>>>> >>>>> Along the lines of application hooks, do we want a way for the >>>>> application layer to be able to safely disable encryption part way >>>>> through a connection? I do not see why this would ever be necessary. A =B3connection=B2 should be established with a particular expectation of services (like encryption) that should not change. Paul >>>> >>> >>> I think this may be a useful thing to do, but i am unconvinced we >>>shoudl >>> explicitly mention it in the charter. My suggestion would be to leave >>>it >>> for discussion and not mention it in the charter. >>> >>> I do think we should include a requirement on avoiding double >>>encryption >>> when is possible (notable with TLS) >> >> One solution could be to allow a renegotiation of the crypto algorithm >> used (in addition to the keys) and support null encryption. This would >> allow to effectively disable encryption during the connection but >> would bring more advanced capabilities >> > >yes, Joe suggested this earlier on, that is why i think it should not be >very hard to support. >My question was more in the charter context, whether we should include >this explicitly there or leave it open for the WG to consider and i was >slightly inclined to leave it for the WG to decide. >Regards, marcelo > > >> >> Olivier >> >> > >_______________________________________________ >Tcpcrypt mailing list >Tcpcrypt@ietf.org >https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Wed Apr 23 09:16:42 2014 Return-Path: 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 7E4D91A0272 for ; Wed, 23 Apr 2014 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 K9mFMDOuI9VD for ; Wed, 23 Apr 2014 09:16:37 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 648D31A0291 for ; Wed, 23 Apr 2014 09:16:37 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so1411255veb.17 for ; Wed, 23 Apr 2014 09:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DUJb83+Jn5uFTfPcmjZkgnaF/Ik4veMsvUnw/lb/Fh4=; b=ueqzTctrghn7GfFfnbkBQfkNN7eRBZ4URVexTXIQQM0uVcRmPmNh3C9s1Jq8ILYLU7 pGJh1iIYPNYGBEfs0BtgHYmlAurCn4Rg/VXTWV0EbiLLvqHP+txA3Mq9UF0BQ0v0+Pku icjWC4Ln0Kab1TXoP11uCboCUCZisyGG+S+WuYZ1Fnpv5vQNBHh+HmiCxS8taz5QiiVh AZOdYIH4FaSYJv2xX+Ol9/kywzkbR7vWYoDsuFp8VfXgotAUb44OkD1l3ZH36yKfIkVK 6cQlesyq6Nry+9YAWw6Kch/O3agA0NzsfQFclvclf7WxHuoKCbkRV/+LC7cRZDGozSWf 8aTg== X-Received: by 10.52.139.6 with SMTP id qu6mr512677vdb.67.1398269791514; Wed, 23 Apr 2014 09:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 09:16:11 -0700 (PDT) In-Reply-To: References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> From: Tony Arcieri Date: Wed, 23 Apr 2014 09:16:11 -0700 Message-ID: To: Paul Lambert Content-Type: multipart/alternative; boundary=bcaec52d583339398704f7b80e7c Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xe1SmJrHDYVCAsV15j75Q3rnugc Cc: marcelo bagnulo braun , "tcpcrypt@ietf.org" , "Olivier.Bonaventure@uclouvain.be" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:16:39 -0000 --bcaec52d583339398704f7b80e7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2014 at 9:14 AM, Paul Lambert wrote: > I do not see why this would ever be necessary. > A =C2=B3connection=C2=B2 should be established with a particular expectat= ion of > services > (like encryption) that should not change. If we've learned anything from TLS, the more features you add, the more likely you're going to implement one of them incorrectly. What if you make a mistake and an attacker or MitM can shut off encryption? The negligible performance impact of double encryption pales in comparison to the chance that an attacker will be able to maliciously disable encryption, IMO. --=20 Tony Arcieri --bcaec52d583339398704f7b80e7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 9:14 AM, Paul Lambert <paul@marvell.com> wrote:
I do not see why this would = ever be necessary.
A =C2=B3connection=C2=B2 should be established with a particular expectatio= n of
services
(like encryption) that should not change.

I= f we've learned anything from TLS, the more features you add, the more = likely you're going to implement one of them incorrectly. What if you m= ake a mistake and an attacker or MitM can shut off encryption?

The negligible performance impact of double encry= ption pales in comparison to the chance that an attacker will be able to ma= liciously disable encryption, IMO.=C2=A0

--
Tony Ar= cieri
--bcaec52d583339398704f7b80e7c-- From nobody Wed Apr 23 09:55:26 2014 Return-Path: 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 9C4381A037F for ; Wed, 23 Apr 2014 09:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 AJI4XDieRp3n for ; Wed, 23 Apr 2014 09:55:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B21031A026A for ; Wed, 23 Apr 2014 09:55:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NGsqpv024335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 09:54:55 -0700 (PDT) Message-ID: <5357F05C.3060507@isi.edu> Date: Wed, 23 Apr 2014 09:54:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> In-Reply-To: <53576572.5030805@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/yEXaOBLbxZ16KisGn3v7AeJtbqY 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:55:25 -0000 Hi, all, Comments below... Joe On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote: ... > TCP Increased Security (TCP Inc.) I like the title, FWIW. > The TCP Inc. WG will develop the TCP extensions to provide unauthenticated > encryption and integrity protection of TCP streams. OK so far... > The WG will define the > TCP extensions to perform an unauthenticated key exchange resulting in > encryption > without authentication. This implies in-band. I don't think in-band key exchange is viable; there's no way to protect the SYNs, and it might sufficiently increase SYN processing and server state to make a much larger attack surface. I would optimally prefer out-of-band exchange, perhaps that could be bootstrapped with an initial in-band exchange. Less optimal would be to leave this issue open for the WG to discuss, but I definitely don't agree with mandating only in-band key exchange. I would thus prefer: The WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. > This is better than plain-text because it thwarts > passive eavesdropping, but is weaker than using authenticated keys, > because it > is vulnerable to man-in-the-middle attacks. This work is part of the IETF > effort to harness the Internet architecture given the latest events of > pervasive > monitoring (see draft-farrell-perpass-attack). It also leverages the original principle of BTNS, FWIW. > The working group is looking to produce experimental documents > specifying the > required TCP extensions and any additional informational documents needed. > > The high-level requirements for the protocol for providing TCP > unauthenticated > encryption and integrity protection are: > > - Deployable and usable without significant changes to existing Internet > infrastructure, in particular it must be compatible with NATs (at the > very minimum with the NATs that comply with BEHAVE requirements as > documented > in RFC4787, RFC5382 and RFC5508); > > - The protocol must be usable by unmodified applications. This effort > is complementary > to other security protocols developed in the IETF (such as TLS) as it > protects > those applications and protocols that are difficult to change or may > even not > be changed in a backward compatible way. It also provides some > protection in > scenarios where people are unwilling to do any change just for the > sake of > security (e.g., like configure encryption in an application). > > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > - When encryption is enabled, it must always provide forward secrecy. > > - When encryption is enabled, it must always provide integrity > protection of the > payload data (it is open for discussion for the WG if the TCP header > should or > not be protected) > > - When encryption is enabled, it must always provide payload encryption. > > - Should attempt to use the least amount of TCP option space. ...especially in SYN segments. > - Must not require any authentication or configuration from > applications or users. However, hooks for external authentication > must be > made available. The WG will not work on new authentication mechanisms. > > - The protocol must have acceptable performance. For example, the > protocol may > try to re-use existing cryptographic material for future > communication between the > same endpoints to avoid expensive public key operations on connection > set up. > > - Hooks for allowing upper layers to disable encryption must be made > available. > The protocol may try to avoid redundant encryption when it is > possible e.g. > by detecting encryption performed by upper layers (notably, when TLS > is used). When TLS is used, this defeats TCP-INC's ability to protect the TCP header. It's OK to allow hooks to turn this off, but a better use case should be provided as motivation. > - No extra linkability: when encryption is enabled the TCP traffic > should not > give a third party observer any extra way to associate those packets > with the > specific peers beyond information that would have been present in a > cleartext session. > > - Client fingerprinting: some clients may want to avoid appearing as the > same > client when connecting to a remote peer on subsequent occasions. This > should either > be the default (clients cannot be "fingerprinted" by the server based > on shared state) > or some mechanism should be available for clients to drop or ignore > shared state to avoid > being fingerprintable. This should also include "any more than would be present for a cleartext session". > Security features at the TCP-level can benefit other TCP extensions. For > example, both Multipath TCP and TCP Fast Open require proof that some > connections are > related. Session resumption and Message Authentication Codes (MACs) can > provide > this evidence. The working group should identify synergies and design the > security protocol in such a way that other TCP efforts can benefit from > it. Of > course, TCP extensions that break must be identified too, and kept to a > minimum. > > The working group will produce the following documents: > > - A framework for unauthenticated encryption and integrity protection of > TCP connections. > This document will describe basic design considerations, including the > motivation and the > applicability of the proposed mechanism, the interaction with other > security mechanisms in > different layers of the stack, the interaction with external > authentication mechanisms, the > expected protection, privacy considerations and residual threats. > > - Extensions to current TCP to support unauthenticated key exchange and > encryption and > integrity protection. This covers all the protocol changes required. > This will be a > experimental document. > > - An extended API describing how applications can obtain further > benefits of the > proposed extensions. In particular, the hooks for supporting external > authentication > will be defined in this document and the hooks for disabling encryption. > This will be an informational document. > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Wed Apr 23 10:00:27 2014 Return-Path: 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 B02BF1A01DE for ; Wed, 23 Apr 2014 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 ZUmAcjTkwTBo for ; Wed, 23 Apr 2014 10:00:24 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC11A03D3 for ; Wed, 23 Apr 2014 10:00:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NGxwvf026012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 09:59:59 -0700 (PDT) Message-ID: <5357F18E.4090400@isi.edu> Date: Wed, 23 Apr 2014 09:59:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> In-Reply-To: <53575A81.300@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/pzQBk4D6xWfdi0i4ZHPp11G5Fqs Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:00:25 -0000 On 4/22/2014 11:15 PM, marcelo bagnulo braun wrote: > I am working on the new version of the charter and i was thinking about > this. > > below... > > El 13/04/14 19:44, Joe Touch escribió: >> >> >> On 4/13/2014 9:45 AM, Erik Nygren wrote: >>> Thank you for this summary. >>> >>> Along the lines of application hooks, do we want a way for the >>> application layer to be able to safely disable encryption part way >>> through a connection? >> > > I think this may be a useful thing to do, but i am unconvinced we shoudl > explicitly mention it in the charter. My suggestion would be to leave it > for discussion and not mention it in the charter. > > I do think we should include a requirement on avoiding double encryption > when is possible (notable with TLS) I already responded about this issue in the updated charter. Redundant security processing, e.g., TCP-INC with TCP-AO, is clearly useful to avoid. However, encryption at different layers provides different protection. TLS - TCP-INC interaction is a really good example of why NOT to turn of TCP-INC -- it would leave TLS vulnerable to RST and other attacks at the TCP layer. There are similar important differences in protection between WPA, IPsec, and TCP-INC. Encouraging people to disable protection at lower layers because it is provided at higher layers is both a bad idea in specific and bad general security advice in general. Joe From nobody Wed Apr 23 10:02:40 2014 Return-Path: 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 AC3181A0221 for ; Wed, 23 Apr 2014 10:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 Q0pydyATpafU for ; Wed, 23 Apr 2014 10:02:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3F1A03D3 for ; Wed, 23 Apr 2014 10:02:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NH2CBv026762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 10:02:12 -0700 (PDT) Message-ID: <5357F214.7080207@isi.edu> Date: Wed, 23 Apr 2014 10:02:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , Olivier.Bonaventure@uclouvain.be References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> In-Reply-To: <5357660E.3040707@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/eaQK67FaYIPBcbHXvVZXihmn_gA Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:02:39 -0000 On 4/23/2014 12:04 AM, marcelo bagnulo braun wrote: > El 23/04/14 08:44, Olivier Bonaventure escribió: >> Marcelo, >>> >>> El 13/04/14 19:44, Joe Touch escribió: >>>> >>>> >>>> On 4/13/2014 9:45 AM, Erik Nygren wrote: >>>>> Thank you for this summary. >>>>> >>>>> Along the lines of application hooks, do we want a way for the >>>>> application layer to be able to safely disable encryption part way >>>>> through a connection? >>>> >>> >>> I think this may be a useful thing to do, but i am unconvinced we shoudl >>> explicitly mention it in the charter. My suggestion would be to leave it >>> for discussion and not mention it in the charter. >>> >>> I do think we should include a requirement on avoiding double encryption >>> when is possible (notable with TLS) >> >> One solution could be to allow a renegotiation of the crypto algorithm >> used (in addition to the keys) and support null encryption. This would >> allow to effectively disable encryption during the connection but >> would bring more advanced capabilities > > yes, Joe suggested this earlier on, that is why i think it should not be > very hard to support. You don't need to renegotiate during the connection or in-band. You just need to coordinate when to rollover in-band (e.g., as TCP-AO does). Key rollover without impact is important for a lot of other reasons, though, so IMO it should be part of the list. Joe From nobody Wed Apr 23 10:04:10 2014 Return-Path: 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 A14781A03D3 for ; Wed, 23 Apr 2014 10:04:08 -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 aNBiJ2MAgR9S for ; Wed, 23 Apr 2014 10:04:05 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D66C11A03B6 for ; Wed, 23 Apr 2014 10:04:04 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C4B40CD41C1 for ; Wed, 23 Apr 2014 19:03:58 +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@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 88936CD7826 for ; Wed, 23 Apr 2014 19:03:58 +0200 (CEST) Message-ID: <5357F2AD.9070307@it.uc3m.es> Date: Wed, 23 Apr 2014 19:04:45 +0200 From: marcelo bagnulo braun 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> In-Reply-To: <5357F05C.3060507@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.000 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/x98CzUx3SuY-IZ-w4J3vNrFMajY 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:04:08 -0000 El 23/04/14 18:54, Joe Touch escribió: > Hi, all, > > Comments below... > > Joe > > > On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote: > ... >> TCP Increased Security (TCP Inc.) > > I like the title, FWIW. > >> The TCP Inc. WG will develop the TCP extensions to provide >> unauthenticated >> encryption and integrity protection of TCP streams. > > OK so far... > > > 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. I think this is a fundamental feature. I am ok with allowing the use of other keys if they are available, but i strongly believe key exchange is a core part of this. Regards, marcelo > I don't think in-band key exchange is viable; there's no way to > protect the SYNs, and it might sufficiently increase SYN processing > and server state to make a much larger attack surface. > > I would optimally prefer out-of-band exchange, perhaps that could be > bootstrapped with an initial in-band exchange. Less optimal would be > to leave this issue open for the WG to discuss, but I definitely don't > agree with mandating only in-band key exchange. > > I would thus prefer: > > The WG will define the > TCP extensions to utilize unauthenticated keys, resulting > in encryption and integrity protection without authentication. > > > This is better than plain-text because it thwarts >> passive eavesdropping, but is weaker than using authenticated keys, >> because it >> is vulnerable to man-in-the-middle attacks. This work is part of the >> IETF >> effort to harness the Internet architecture given the latest events of >> pervasive >> monitoring (see draft-farrell-perpass-attack). > > It also leverages the original principle of BTNS, FWIW. > >> The working group is looking to produce experimental documents >> specifying the >> required TCP extensions and any additional informational documents >> needed. >> >> The high-level requirements for the protocol for providing TCP >> unauthenticated >> encryption and integrity protection are: >> >> - Deployable and usable without significant changes to existing Internet >> infrastructure, in particular it must be compatible with NATs (at the >> very minimum with the NATs that comply with BEHAVE requirements as >> documented >> in RFC4787, RFC5382 and RFC5508); >> >> - The protocol must be usable by unmodified applications. This effort >> is complementary >> to other security protocols developed in the IETF (such as TLS) as it >> protects >> those applications and protocols that are difficult to change or may >> even not >> be changed in a backward compatible way. It also provides some >> protection in >> scenarios where people are unwilling to do any change just for the >> sake of >> security (e.g., like configure encryption in an application). >> >> - When encryption is enabled, it must at least provide protection >> against >> passive eavesdropping by default, >> >> - Must gracefully fall-back to TCP if the remote peer does not >> support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it must always provide integrity >> protection of the >> payload data (it is open for discussion for the WG if the TCP header >> should or >> not be protected) >> >> - When encryption is enabled, it must always provide payload encryption. >> >> - Should attempt to use the least amount of TCP option space. > > ...especially in SYN segments. > >> - Must not require any authentication or configuration from >> applications or users. However, hooks for external authentication >> must be >> made available. The WG will not work on new authentication >> mechanisms. >> >> - The protocol must have acceptable performance. For example, the >> protocol may >> try to re-use existing cryptographic material for future >> communication between the >> same endpoints to avoid expensive public key operations on connection >> set up. >> >> - Hooks for allowing upper layers to disable encryption must be made >> available. >> The protocol may try to avoid redundant encryption when it is >> possible e.g. >> by detecting encryption performed by upper layers (notably, when TLS >> is used). > > When TLS is used, this defeats TCP-INC's ability to protect the TCP > header. > > It's OK to allow hooks to turn this off, but a better use case should > be provided as motivation. > >> - No extra linkability: when encryption is enabled the TCP traffic >> should not >> give a third party observer any extra way to associate those packets >> with the >> specific peers beyond information that would have been present in a >> cleartext session. >> >> - Client fingerprinting: some clients may want to avoid appearing as the >> same >> client when connecting to a remote peer on subsequent occasions. This >> should either >> be the default (clients cannot be "fingerprinted" by the server based >> on shared state) >> or some mechanism should be available for clients to drop or ignore >> shared state to avoid >> being fingerprintable. > > This should also include "any more than would be present for a > cleartext session". > >> Security features at the TCP-level can benefit other TCP extensions. >> For >> example, both Multipath TCP and TCP Fast Open require proof that some >> connections are >> related. Session resumption and Message Authentication Codes (MACs) can >> provide >> this evidence. The working group should identify synergies and >> design the >> security protocol in such a way that other TCP efforts can benefit from >> it. Of >> course, TCP extensions that break must be identified too, and kept to a >> minimum. >> >> The working group will produce the following documents: >> >> - A framework for unauthenticated encryption and integrity protection of >> TCP connections. >> This document will describe basic design considerations, including the >> motivation and the >> applicability of the proposed mechanism, the interaction with other >> security mechanisms in >> different layers of the stack, the interaction with external >> authentication mechanisms, the >> expected protection, privacy considerations and residual threats. >> >> - Extensions to current TCP to support unauthenticated key exchange and >> encryption and >> integrity protection. This covers all the protocol changes required. >> This will be a >> experimental document. >> >> - An extended API describing how applications can obtain further >> benefits of the >> proposed extensions. In particular, the hooks for supporting external >> authentication >> will be defined in this document and the hooks for disabling encryption. >> This will be an informational document. >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Apr 23 10:05:11 2014 Return-Path: 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 CE1D61A03D4 for ; Wed, 23 Apr 2014 10:05:10 -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 3Ee9qUzRye0n for ; Wed, 23 Apr 2014 10:05:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 409471A03CC for ; Wed, 23 Apr 2014 10:05:07 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0B30F11C5BDF for ; Wed, 23 Apr 2014 19:05:01 +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 9CD6B11C5C0D for ; Wed, 23 Apr 2014 19:05:00 +0200 (CEST) Message-ID: <5357F2EB.8010302@it.uc3m.es> Date: Wed, 23 Apr 2014 19:05:47 +0200 From: marcelo bagnulo braun 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> In-Reply-To: <5357F05C.3060507@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.000 X-TM-AS-Result: No--36.410-7.0-31-1 X-imss-scan-details: No--36.410-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/KbZp5hDDxgITJFy66uo6sMsI4C0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:05:11 -0000 Sorry, didnt finish the previous email. I am fine with all the other comments. Will add them in the next version. El 23/04/14 18:54, Joe Touch escribió: > Hi, all, > > Comments below... > > Joe > > > On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote: > ... >> TCP Increased Security (TCP Inc.) > > I like the title, FWIW. > >> The TCP Inc. WG will develop the TCP extensions to provide >> unauthenticated >> encryption and integrity protection of TCP streams. > > OK so far... > > > The WG will define the >> TCP extensions to perform an unauthenticated key exchange resulting in >> encryption >> without authentication. > > This implies in-band. I don't think in-band key exchange is viable; > there's no way to protect the SYNs, and it might sufficiently increase > SYN processing and server state to make a much larger attack surface. > > I would optimally prefer out-of-band exchange, perhaps that could be > bootstrapped with an initial in-band exchange. Less optimal would be > to leave this issue open for the WG to discuss, but I definitely don't > agree with mandating only in-band key exchange. > > I would thus prefer: > > The WG will define the > TCP extensions to utilize unauthenticated keys, resulting > in encryption and integrity protection without authentication. > > > This is better than plain-text because it thwarts >> passive eavesdropping, but is weaker than using authenticated keys, >> because it >> is vulnerable to man-in-the-middle attacks. This work is part of the >> IETF >> effort to harness the Internet architecture given the latest events of >> pervasive >> monitoring (see draft-farrell-perpass-attack). > > It also leverages the original principle of BTNS, FWIW. > >> The working group is looking to produce experimental documents >> specifying the >> required TCP extensions and any additional informational documents >> needed. >> >> The high-level requirements for the protocol for providing TCP >> unauthenticated >> encryption and integrity protection are: >> >> - Deployable and usable without significant changes to existing Internet >> infrastructure, in particular it must be compatible with NATs (at the >> very minimum with the NATs that comply with BEHAVE requirements as >> documented >> in RFC4787, RFC5382 and RFC5508); >> >> - The protocol must be usable by unmodified applications. This effort >> is complementary >> to other security protocols developed in the IETF (such as TLS) as it >> protects >> those applications and protocols that are difficult to change or may >> even not >> be changed in a backward compatible way. It also provides some >> protection in >> scenarios where people are unwilling to do any change just for the >> sake of >> security (e.g., like configure encryption in an application). >> >> - When encryption is enabled, it must at least provide protection >> against >> passive eavesdropping by default, >> >> - Must gracefully fall-back to TCP if the remote peer does not >> support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it must always provide integrity >> protection of the >> payload data (it is open for discussion for the WG if the TCP header >> should or >> not be protected) >> >> - When encryption is enabled, it must always provide payload encryption. >> >> - Should attempt to use the least amount of TCP option space. > > ...especially in SYN segments. > >> - Must not require any authentication or configuration from >> applications or users. However, hooks for external authentication >> must be >> made available. The WG will not work on new authentication >> mechanisms. >> >> - The protocol must have acceptable performance. For example, the >> protocol may >> try to re-use existing cryptographic material for future >> communication between the >> same endpoints to avoid expensive public key operations on connection >> set up. >> >> - Hooks for allowing upper layers to disable encryption must be made >> available. >> The protocol may try to avoid redundant encryption when it is >> possible e.g. >> by detecting encryption performed by upper layers (notably, when TLS >> is used). > > When TLS is used, this defeats TCP-INC's ability to protect the TCP > header. > > It's OK to allow hooks to turn this off, but a better use case should > be provided as motivation. > >> - No extra linkability: when encryption is enabled the TCP traffic >> should not >> give a third party observer any extra way to associate those packets >> with the >> specific peers beyond information that would have been present in a >> cleartext session. >> >> - Client fingerprinting: some clients may want to avoid appearing as the >> same >> client when connecting to a remote peer on subsequent occasions. This >> should either >> be the default (clients cannot be "fingerprinted" by the server based >> on shared state) >> or some mechanism should be available for clients to drop or ignore >> shared state to avoid >> being fingerprintable. > > This should also include "any more than would be present for a > cleartext session". > >> Security features at the TCP-level can benefit other TCP extensions. >> For >> example, both Multipath TCP and TCP Fast Open require proof that some >> connections are >> related. Session resumption and Message Authentication Codes (MACs) can >> provide >> this evidence. The working group should identify synergies and >> design the >> security protocol in such a way that other TCP efforts can benefit from >> it. Of >> course, TCP extensions that break must be identified too, and kept to a >> minimum. >> >> The working group will produce the following documents: >> >> - A framework for unauthenticated encryption and integrity protection of >> TCP connections. >> This document will describe basic design considerations, including the >> motivation and the >> applicability of the proposed mechanism, the interaction with other >> security mechanisms in >> different layers of the stack, the interaction with external >> authentication mechanisms, the >> expected protection, privacy considerations and residual threats. >> >> - Extensions to current TCP to support unauthenticated key exchange and >> encryption and >> integrity protection. This covers all the protocol changes required. >> This will be a >> experimental document. >> >> - An extended API describing how applications can obtain further >> benefits of the >> proposed extensions. In particular, the hooks for supporting external >> authentication >> will be defined in this document and the hooks for disabling encryption. >> This will be an informational document. >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Apr 23 10:19:38 2014 Return-Path: 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 3F70F1A03BF for ; Wed, 23 Apr 2014 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 DzNha0rcBhHc for ; Wed, 23 Apr 2014 10:19:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5641A1A021F for ; Wed, 23 Apr 2014 10:19:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NHIrYY002735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 10:18:54 -0700 (PDT) Message-ID: <5357F5FD.4070103@isi.edu> Date: Wed, 23 Apr 2014 10:18:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <5357F05C.3060507@isi.edu> <5357F2AD.9070307@it.uc3m.es> In-Reply-To: <5357F2AD.9070307@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/WJloWC16a11WHlpiHEOnVWPqOX0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:19:35 -0000 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. Joe From nobody Wed Apr 23 10:54:04 2014 Return-Path: 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 ; 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 ; 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 ; 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 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 , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > From nobody Wed Apr 23 11:00:29 2014 Return-Path: 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 9A16A1A048A for ; Wed, 23 Apr 2014 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 ckt92_lIzO5T for ; Wed, 23 Apr 2014 11:00:25 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 971721A047E for ; Wed, 23 Apr 2014 11:00:25 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3NI0J56013516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2014 11:00:19 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3NI0Itj013515; Wed, 23 Apr 2014 11:00:18 -0700 (PDT) (envelope-from jmg) Date: Wed, 23 Apr 2014 11:00:18 -0700 From: John-Mark Gurney To: marcelo bagnulo braun Message-ID: <20140423180018.GJ43976@funkthat.com> References: <53576572.5030805@it.uc3m.es> <5357F05C.3060507@isi.edu> <5357F2AD.9070307@it.uc3m.es> <5357F5FD.4070103@isi.edu> <5357FE5E.3070307@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5357FE5E.3070307@it.uc3m.es> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 23 Apr 2014 11:00:19 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/TN-aimLx9gFME9ttdrLXTvW08cM Cc: tcpcrypt@ietf.org, Joe Touch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:00:27 -0000 marcelo bagnulo braun wrote this message on Wed, Apr 23, 2014 at 19:54 +0200: > 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 Yes, this would be nice to know... > having a control connection to negotiate these things? > (something like > https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?) This should be entirely in kernel, as requiring a daemon to pass non-TCP traffic before any encrypted TCP traffic can be sent it a bad idea... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Wed Apr 23 11:37:46 2014 Return-Path: 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 6D2DD1A049A for ; Wed, 23 Apr 2014 11:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 zRNiWWbcIVv8 for ; Wed, 23 Apr 2014 11:37:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAEB1A0435 for ; Wed, 23 Apr 2014 11:37:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NIb6kI001662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 11:37:06 -0700 (PDT) Message-ID: <53580852.30704@isi.edu> Date: Wed, 23 Apr 2014 11:37:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney , marcelo bagnulo braun References: <53576572.5030805@it.uc3m.es> <5357F05C.3060507@isi.edu> <5357F2AD.9070307@it.uc3m.es> <5357F5FD.4070103@isi.edu> <5357FE5E.3070307@it.uc3m.es> <20140423180018.GJ43976@funkthat.com> In-Reply-To: <20140423180018.GJ43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/tU2n6nkPWXnIq6mLyz6ByVZG-H0 Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:37:44 -0000 On 4/23/2014 11:00 AM, John-Mark Gurney wrote: > marcelo bagnulo braun wrote this message on Wed, Apr 23, 2014 at 19:54 +0200: >> 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 > > Yes, this would be nice to know... In-band in a previous connection or completely out-of-band in a different protocol (like IKE is to IPsec). You could even do it inside the data of a TCP connection and use it on subsequent connections if you wanted to keep it "TCP". >> having a control connection to negotiate these things? >> (something like >> https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?) > > This should be entirely in kernel, as requiring a daemon to pass non-TCP > traffic before any encrypted TCP traffic can be sent it a bad idea... It should be integrated and automatic. How that is achieved is implementation-dependent, and we shouldn't care other than integrated and automatic. Joe From nobody Wed Apr 23 11:38:48 2014 Return-Path: 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 EAF601A049F for ; Wed, 23 Apr 2014 11:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 HF8U4vdLYHPZ for ; Wed, 23 Apr 2014 11:38:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE991A049A for ; Wed, 23 Apr 2014 11:38:43 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3NIcP7k002263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 11:38:25 -0700 (PDT) Message-ID: <535808A1.6020406@isi.edu> Date: Wed, 23 Apr 2014 11:38:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , 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> In-Reply-To: <5357FE5E.3070307@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/W-unYxo8mNPW7rLOl3Mi0X5XFiM 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:38:45 -0000 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. Joe From nobody Wed Apr 23 12:00:57 2014 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > From nobody Wed Apr 23 14:44:48 2014 Return-Path: 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 7B2C91A06CD for ; Wed, 23 Apr 2014 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 EjobqbcKpuv7 for ; Wed, 23 Apr 2014 14:44:45 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C90F81A06D6 for ; Wed, 23 Apr 2014 14:44:45 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id la4so1932339vcb.17 for ; Wed, 23 Apr 2014 14:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kpuWS4W2rh9W6ezkwPU9qSLsnbwJKW+RtQquHPGj/PA=; b=U1fHC2k1gxewVGAVn2MwJJbtR8g8IIqW/os3L+l/zvKmbiLso7XvCifeBHb7i0y5Fu 5gG5JOhuPnCnY+p2XzNBHRGYJv1vzc8tabgAssyV28hAhl3HnL7L0No5VPwYsJsPXlcy n2Jai5jmzwq/LuHsRCXBvXOj/Ac2KUzQbZuDWrqgJneqb4tmWXVCOY+Wx4KdoSguPPnK g7rhdiTEdcqIOyraQgVEgYT9KSSbZrldN5nSHDgZXNMghGR841HPiltc857xjrj9Km+M t+z6kjCzPE/a8JAMR+0jZtw552VokPe+UcquqcgR/Gls+pUqOCb1pK9nuvcRsiQ4PTxg MJZA== X-Received: by 10.220.92.193 with SMTP id s1mr1511310vcm.34.1398289479759; Wed, 23 Apr 2014 14:44:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 14:44:19 -0700 (PDT) In-Reply-To: <53575A81.300@it.uc3m.es> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> From: Tony Arcieri Date: Wed, 23 Apr 2014 14:44:19 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a11c1ea10bbfd6f04f7bca31f Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/N-e13iU_sgwXMrgCsVxvRHQ_rxQ Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 21:44:47 -0000 --001a11c1ea10bbfd6f04f7bca31f Content-Type: text/plain; charset=UTF-8 On Tue, Apr 22, 2014 at 11:15 PM, marcelo bagnulo braun wrote: > I think this may be a useful thing to do, but i am unconvinced we shoudl > explicitly mention it in the charter. My suggestion would be to leave it > for discussion and not mention it in the charter. Let me just say that if you do mention it in the charter, I will lose all interest in Tcpcrypt and completely abandon it. This is premature optimization. It's not "useful to avoid" until you have actually measured the performance impact. You don't have a protocol yet, AFAICT. You are still in the investigative stage, unless there's something I'm missing. Adding off-switches for security features "for speed" without measurements is completely antithetical to the goals I would hope Tcpcrypt has. Have any of you actually run something like "openssl speed -evp aes-128-gcm" on your platform? I get 1.33GB/s. Double encrypting: 1) Will provide a failsafe if one of the layers is compromised 2) Should have negligible performance overhead on modern CPUs. The overwhelming majority of server, desktop, and mobile processors support AES in hardware Adding off switches to security features: 1) Increases attack surface 2) Increases the chance of a mistake 3) Complicates the protocol in ways that make it harder to audit I have been mulling Tcpcrypt versus my own efforts. If Tcpcrypt seriously wants to go forward with this, particularly without a specified protocol or without anyone actually *measuring* the performance impact they want to prematurely optimize, I'm afraid I'll have to abandon Tcpcrypt as I think you're going down the wrong path. I'm serious. Choose wisely! -- Tony Arcieri --001a11c1ea10bbfd6f04f7bca31f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 22, 2014 at 11:15 PM, marcelo bagnulo braun <<= a href=3D"mailto:marcelo@it.uc3m.es" target=3D"_blank">marcelo@it.uc3m.es> wrote:
I think this may be a useful thing to do, but i am unconvi= nced we shoudl explicitly mention it in the charter. My suggestion would be= to leave it for discussion and not mention it in the charter.

Let me just say that if you do mention it in the charte= r, I will lose all interest in Tcpcrypt and completely abandon it.

This is premature optimization. It's not "useful = to avoid" until you have actually measured the performance impact. You= don't have a protocol yet, AFAICT. You are still in the investigative = stage, unless there's something I'm missing.

Adding off-switches for security features "f= or speed" without measurements is completely antithetical to the goals= I would hope Tcpcrypt has.

Have any of you actual= ly run something like "openssl speed -evp aes-128-gcm" on your pl= atform? I get 1.33GB/s.

Double encrypting:

1) Will pro= vide a failsafe if one of the layers is compromised
2) Should hav= e negligible performance overhead on modern CPUs. The overwhelming majority= of server, desktop, and mobile processors support AES in hardware

Adding off switches to security features:
1) Increases attack surface
2) Increases the chance o= f a mistake
3) Complicates the protocol in ways that make it hard= er to audit

I have been mulling Tcpcrypt versus my own efforts. If = Tcpcrypt seriously wants to go forward with this, particularly without a sp= ecified protocol or without anyone actually *measuring* the performance imp= act they want to prematurely optimize, I'm afraid I'll have to aban= don Tcpcrypt as I think you're going down the wrong path.

I'm serious. Choose wisely!

-- =
Tony Arcieri
--001a11c1ea10bbfd6f04f7bca31f-- From nobody Wed Apr 23 15:21:04 2014 Return-Path: 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 E30211A06E6 for ; Wed, 23 Apr 2014 15:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 uYYcXJK4__hD for ; Wed, 23 Apr 2014 15:20:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9E1A06E4 for ; Wed, 23 Apr 2014 15:20:58 -0700 (PDT) Received: from [128.9.184.138] ([128.9.184.138]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3NMKUpB015266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 15:20:30 -0700 (PDT) Message-ID: <53583CB2.3050604@isi.edu> Date: Wed, 23 Apr 2014 15:20:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri , marcelo bagnulo braun References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5Gsq7dRUCY5MCb6nHzx8r-4Rzis Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:21:00 -0000 On 4/23/2014 2:44 PM, Tony Arcieri wrote: > On Tue, Apr 22, 2014 at 11:15 PM, marcelo bagnulo braun > > wrote: > > I think this may be a useful thing to do, but i am unconvinced we > shoudl explicitly mention it in the charter. My suggestion would be > to leave it for discussion and not mention it in the charter. > > Let me just say that if you do mention it in the charter, I will lose > all interest in Tcpcrypt and completely abandon it. If you insist on such threats, please leave now. Otherwise, you're welcome to stay or leave as you like, as we all are. > This is premature optimization. It's not "useful to avoid" until you > have actually measured the performance impact. You don't have a protocol > yet, AFAICT. You are still in the investigative stage, unless there's > something I'm missing. > > Adding off-switches for security features "for speed" without > measurements is completely antithetical to the goals I would hope > Tcpcrypt has. > > Have any of you actually run something like "openssl speed -evp > aes-128-gcm" on your platform? I get 1.33GB/s. Yes, and if you run things twice you get half that performance. Regardless of what you're doing, there can be reasons it will be useful to disable it - energy, throughput, etc. - when you're in a trusted envinronment, e.g., doing a local backup. > Double encrypting: I've already noted that this isn't double - it's different layers, with different benefits, which I think is already known useful... > 1) Will provide a failsafe if one of the layers is compromised It's not a true failsafe unless you're doing the same kind of things at the same layers. No amount of TLS will protect TCP from RST attacks, e.g. > 2) Should have negligible performance overhead on modern CPUs. The > overwhelming majority of server, desktop, and mobile processors support > AES in hardware At a cost - I might not want to take either the performance or energy hit to backup my cellphone over a local WiFi with this protection because I don't worry about off-path attacks (maybe I should, but let's say I make that decision). > Adding off switches to security features: > > 1) Increases attack surface No. It means you have decided to not use it. > 2) Increases the chance of a mistake we're talking about default-on that can be disabled. That happens deliberately. > 3) Complicates the protocol in ways that make it harder to audit In the sense that any feature would do this, yes. However, in it's a single global switch; you either agree to use it or not. > I have been mulling Tcpcrypt versus my own efforts. If Tcpcrypt > seriously wants to go forward with this, particularly without a > specified protocol or without anyone actually *measuring* the > performance impact they want to prematurely optimize, I'm afraid I'll > have to abandon Tcpcrypt as I think you're going down the wrong path. I don't think we need an experiment to convince me that there's non-zero energy and performance cost. If you think it's zero, please do let us know and we can sell that capability! Joe \ From nobody Wed Apr 23 15:24:47 2014 Return-Path: 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 D5FE61A06EB for ; Wed, 23 Apr 2014 15:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5ARmDr_byocq for ; Wed, 23 Apr 2014 15:24:42 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84E1A06E4 for ; Wed, 23 Apr 2014 15:24:42 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so2018828veb.28 for ; Wed, 23 Apr 2014 15:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k93R5AhGOxRk1Foh3bqLEYHpJPBQPeC5mjEh7RbKsao=; b=qEtYYf6gxLrqBEaGjkgaSeUgdVbXW0o9BUjPIuoX0UUoJtzLigr69tKBI2qoBUvPlj OViimaOaGAW53vxEqIdyF9ve78wLCvc9j9VEdwSloYnuG4Kpsav+ZEKEcEV3USoqXmii +GoYtt4V/sL2RS5K5PJ7+XwyNxFesopoos5Dj1ac/vMvRvIX6PHx3t4Ng5Ed8Fi5S3fB g7B47k4NLaCjNdRaADVf7xU1tMpS4NstYtsEqcCnSAVnTF/JLqo95GKOz3gHcZYgMzCl 9sRorcVDWNx9ZOpmhmO4hJhGG0LPXP90FAA/qHI+/yx5+JgVxydg1E3oopVJnWjiITeQ gO8A== X-Received: by 10.52.99.168 with SMTP id er8mr13669783vdb.26.1398291876261; Wed, 23 Apr 2014 15:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 15:24:16 -0700 (PDT) In-Reply-To: <53583CB2.3050604@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 15:24:16 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=20cf3071cab093b53104f7bd326b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/4T4_W08XW5DFXXzUikIqHmxdYh8 Cc: marcelo bagnulo braun , "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:24:44 -0000 --20cf3071cab093b53104f7bd326b Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 3:20 PM, Joe Touch wrote: > I don't think we need an experiment to convince me that there's non-zero > energy and performance cost. If you think it's zero, please do let us know > and we can sell that capability! > You're shifting the goalposts. Can you absolutely, positively, 100% assure that this will have *absolutely zero* impact on the security of the protocol? Can you assure me that there will never, ever be a security vulnerability related to this feature? It sounds like you're prioritizing performance (without measuring!!!) over security. This is the wrong set of priorities, IMO. Perhaps I'm in the wrong place. -- Tony Arcieri --20cf3071cab093b53104f7bd326b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 3:20 PM, Joe Touch <touch@isi.edu> wrote:
I don't think we need an experiment to convince me that= there's non-zero energy and performance cost. If you think it's ze= ro, please do let us know and we can sell that capability!

You're shifting the goalposts. Can you absolutel= y, positively, 100% assure that this will have *absolutely zero* impact on = the security of the protocol? Can you assure me that there will never, ever= be a security vulnerability related to this feature?

It sounds like you're prioritizing performance (wit= hout measuring!!!) over security. This is the wrong set of priorities, IMO.=

Perhaps I'm in the wrong place.

--
Tony Arcieri
--20cf3071cab093b53104f7bd326b-- From nobody Wed Apr 23 15:38:23 2014 Return-Path: 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 DF96D1A0717 for ; Wed, 23 Apr 2014 15:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 MHlfnR1jhHwV for ; Wed, 23 Apr 2014 15:38:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id BBAED1A02A3 for ; Wed, 23 Apr 2014 15:38:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3NMbiX7019323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 15:37:44 -0700 (PDT) Message-ID: <535840B8.6040509@isi.edu> Date: Wed, 23 Apr 2014 15:37:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/VH656sUnyfM7p7LdvcICG_OIYR4 Cc: marcelo bagnulo braun , "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:38:20 -0000 On 4/23/2014 3:24 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 3:20 PM, Joe Touch > wrote: > > I don't think we need an experiment to convince me that there's > non-zero energy and performance cost. If you think it's zero, please > do let us know and we can sell that capability! > > You're shifting the goalposts. Can you absolutely, positively, 100% > assure that this will have *absolutely zero* impact on the security of > the protocol? Actually, I can claim that adding a feature to disable the security on demand will make this more likely to be widely deployed and used. FWIW, I don't think it's necessary to disable this *in the middle* of a connection - that seems like a real security vulnerability. > Can you assure me that there will never, ever be a > security vulnerability related to this feature? Strictly, no, but you can't assure me that the converse is true either. > It sounds like you're prioritizing performance (without measuring!!!) > over security. This is the wrong set of priorities, IMO. No one needs to measure the power cost to know it's non-zero. If it were, we'd have bigger problems (i.e., violation of the second law of thermodynamics). As with any system, we're setting the priorities we think will be important to get the result widely used. You and I disagree on the result, and the rough consensus of the group will determine what we end up working on, but there's no absolute right answer to those priorities. There's no such thing as perfect security; it's all a trade-off of complexity, cost, effort, and robustness (among other axes). Joe From nobody Wed Apr 23 15:58:33 2014 Return-Path: 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 940D81A0725 for ; Wed, 23 Apr 2014 15:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 oJyDhVeNbHfE for ; Wed, 23 Apr 2014 15:58:29 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B4D691A071B for ; Wed, 23 Apr 2014 15:58:29 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hu19so1989444vcb.37 for ; Wed, 23 Apr 2014 15:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zi/Jx1GJsqp/j7UyLarWuiGQStn7284QCzqrvp2ygkc=; b=p8w4V13Qo42PqpVS4dgqEA5lR2+Vts8ZsC4BaXfmO31gaR6CLZ7Rig/nTDrePSHTh3 RyCpdzwssOpe2mO1L0OoXSd3F/0VBnim5HS5BbAdIvJsSmpfh4IIkgdxDLldf98bTYkm 1GeGjOzyDEdfXilAuXAyxMeblmGHnLkWOXwjyYOoDfPks5tDSLwgc2D8Xt6Bk6JgIU4r lNcvsTcrmW4VxkfHsFd1QCh618dvE0ROr+JeVBC2rHj1ZG7VIQopmldT1jtxVUZb+WHa TxN1CA5r4IzO/9jJ3zD8hmz/TUUeI7RzquqLwYw0vd+np6MYTzVJwvyWZiVuExyOH/79 zVUw== X-Received: by 10.58.46.207 with SMTP id x15mr44645574vem.17.1398293903716; Wed, 23 Apr 2014 15:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 15:58:03 -0700 (PDT) In-Reply-To: <535840B8.6040509@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <535840B8.6040509@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 15:58:03 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e013a18c26c385404f7bdab99 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/fag4X_JrbFlbxAYscBo2VwSiXso Cc: marcelo bagnulo braun , "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:58:31 -0000 --089e013a18c26c385404f7bdab99 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 3:37 PM, Joe Touch wrote: > No one needs to measure the power cost to know it's non-zero. If it were, > we'd have bigger problems (i.e., violation of the second law of > thermodynamics). > It's still premature optimization, and will come at a non-zero cost to the protocol's security: http://c2.com/cgi/wiki?PrematureOptimization "For those who don't work to strict memory or CPU cycle limits, PrematureOptimization is an AntiPattern, since there is only cost and no benefit. For those who do, it is often confused with poor coding, or with misguided attempts at writing optimal code." Nobody here except me has even bothered to measure the performance and yet this feature is being discussed (before the protocol has even been implemented), which is putting out huge warning signs to me. -- Tony Arcieri --089e013a18c26c385404f7bdab99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 3:37 PM, Joe Touch <touch@isi.edu> wrote:
No one needs to measure the power cost to know it's non= -zero. If it were, we'd have bigger problems (i.e., violation of the se= cond law of thermodynamics).

It's= still premature optimization, and will come at a non-zero cost to the prot= ocol's security:


= "For those who don't work to strict memory or CPU cycle limits, Pr= ematureOptimization is an AntiPattern, since there is only cost and no bene= fit. For those who do, it is often confused with poor coding, or with misgu= ided attempts at writing optimal code."

Nobody here except me has even bothered to measure the performance and = yet this feature is being discussed (before the protocol has even been impl= emented), which is putting out huge warning signs to me.

--
Tony Arcieri
--089e013a18c26c385404f7bdab99-- From nobody Wed Apr 23 16:08:15 2014 Return-Path: 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 F230B1A0728 for ; Wed, 23 Apr 2014 16:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 ACc6ZWywHg72 for ; Wed, 23 Apr 2014 16:08:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5991A072A for ; Wed, 23 Apr 2014 16:08:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3NN74tN025426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 16:07:04 -0700 (PDT) Message-ID: <53584798.70808@isi.edu> Date: Wed, 23 Apr 2014 16:07:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <535840B8.6040509@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zHeECygfR3RZ6llcdV01vwXLeeg Cc: marcelo bagnulo braun , "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:08:12 -0000 On 4/23/2014 3:58 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 3:37 PM, Joe Touch > wrote: > > No one needs to measure the power cost to know it's non-zero. If it > were, we'd have bigger problems (i.e., violation of the second law > of thermodynamics). > > > It's still premature optimization, and will come at a non-zero cost to > the protocol's security: Security is a premature optimization too, in that sense. I.e., I already care about my cellphone's battery, but don't currently experience attacks on TCP connections that a TCP-level solution would be needed to secure. You keep claiming that nobody has measured performance impact of security, but that's not true (see refs below). The converse is that there's very little evidence of attacks at the TCP level of connections except between routers. So if you're core point is that performance is a premature optimization, then so is TCP-layer security, and then there's little utility in pursuing the solution at all. Joe J. Touch, “Performance Analysis of MD5,†in Proc. ACM Sigcomm ’95, pp. 77-86. J. Touch, Y. Yang, “Reducing the Impact of DoS Attacks on Endpoint IP Security,†Proc. NPSec 2006, in conjunction with ICNP 2006, Nov. 2006. From nobody Wed Apr 23 16:28:38 2014 Return-Path: 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 DD6081A0742 for ; Wed, 23 Apr 2014 16:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 eBFKd8vgk8Kd for ; Wed, 23 Apr 2014 16:28:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B75C1A072D for ; Wed, 23 Apr 2014 16:28:31 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 56DC520A7F for ; Wed, 23 Apr 2014 19:28:25 -0400 (EDT) Received: from betaweb1 ([10.202.2.10]) by compute3.internal (MEProxy); Wed, 23 Apr 2014 19:28:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:reply-to:date:in-reply-to:references; s= mesmtp; bh=YQVRkbH2+bAsIrVkAlJIycx/92o=; b=hBzY/cwQzVDq7NAwQGT1V smcP7r6vlC6rI9IMM6rCnjJ3nu8mjxfaaYMWyf7Z/WzG4dCxkbTOr+ZmosDA6CJc UD02lO0qkC/xyI7aBfr61/cjxqkYBhYyHrxZOOFboMj17x2kGlOuO4t86sJaQlzF YuQlGP1JDSU5FxqGK3N1p4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=YQVRkbH2+bAsIrVkAlJIycx/9 2o=; b=cbi/eEa5fNKM3XRVFWTfUAp1ZoJOrC7G1Cej8XY68T3zP7oQYW490+IoS UVifwR+QRWIvaNEL3SEPM9YNZ60s6Z5jYzrnlU/+j+5/mBv1uSbAR4JO2MGj/QBD JQab3NHb95Z4ry/cmdl+o6J+PkZ0H+pgmhWKNzoiQE58CpjYMM= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 256487400C1; Wed, 23 Apr 2014 19:28:25 -0400 (EDT) Message-Id: <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> X-Sasl-Enc: UX2B1LStdpbyB2H7ge2WvBfhpUbJYS5dj8FQUDxoA7so 1398295705 From: Alfie John To: tcpcrypt@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Thu, 24 Apr 2014 09:28:25 +1000 In-Reply-To: <53583CB2.3050604@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/S1KIs-vi274LXSkTtHZ7grDzJUg Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: Draft charter text X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:28:37 -0000 On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote: > > Adding off-switches for security features "for speed" without > > measurements is completely antithetical to the goals I would hope > > Tcpcrypt has. > > > > Have any of you actually run something like "openssl speed -evp aes-128- > > gcm" on your platform? I get 1.33GB/s. > > Yes, and if you run things twice you get half that performance. > Regardless of what you're doing, there can be reasons it will be > useful to disable it - energy, throughput, etc. - when you're in a > trusted envinronment, e.g., doing a local backup. In a trusted environment, you won't be enabling encryption to begin with. This sounds like complete straw-man to me. Alfie -- Alfie John alfiej@fastmail.fm From nobody Wed Apr 23 16:57:08 2014 Return-Path: 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 7777A1A0766 for ; Wed, 23 Apr 2014 16:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 u5oBlIGEz4cY for ; Wed, 23 Apr 2014 16:57:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1A1A0765 for ; Wed, 23 Apr 2014 16:57:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 092B46D4AB; Wed, 23 Apr 2014 19:56:53 -0400 (EDT) Message-ID: <53585342.7000204@iang.org> Date: Thu, 24 Apr 2014 00:56:50 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> In-Reply-To: <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bldRNvg2LgNdX578OO9phL7mCe8 Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:57:06 -0000 On 24/04/2014 00:28 am, Alfie John wrote: > On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote: >>> Adding off-switches for security features "for speed" without >>> measurements is completely antithetical to the goals I would hope >>> Tcpcrypt has. >>> >>> Have any of you actually run something like "openssl speed -evp aes-128- >>> gcm" on your platform? I get 1.33GB/s. >> >> Yes, and if you run things twice you get half that performance. >> Regardless of what you're doing, there can be reasons it will be >> useful to disable it - energy, throughput, etc. - when you're in a >> trusted envinronment, e.g., doing a local backup. > > In a trusted environment, you won't be enabling encryption to begin > with. This sounds like complete straw-man to me. not really. Example ssh: approximately everyone runs it in trusted environments and does not bother to disable the default setup. (philosophically, I'm with Tony on this one, but I'm more relaxed. I'm also thinking that the process of designing a new security protocol in a working group is going to force a bunch of 'premature optimisations' as per Joe's comment, so I'm not expecting to survive any consensus.) iang From nobody Wed Apr 23 17:03:41 2014 Return-Path: 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 F0F661A076B for ; Wed, 23 Apr 2014 17:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 M29MqCaxulVe for ; Wed, 23 Apr 2014 17:03:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 402E41A0765 for ; Wed, 23 Apr 2014 17:03:34 -0700 (PDT) Received: from [128.9.184.138] ([128.9.184.138]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O035Qh006920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 17:03:05 -0700 (PDT) Message-ID: <535854BD.7060808@isi.edu> Date: Wed, 23 Apr 2014 17:03:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: alfiej@fastmail.fm, tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> In-Reply-To: <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zis6JHOBw8dDUVbAoS-Uq4fX99U Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 00:03:39 -0000 On 4/23/2014 4:28 PM, Alfie John wrote: > On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote: >>> Adding off-switches for security features "for speed" without >>> measurements is completely antithetical to the goals I would hope >>> Tcpcrypt has. >>> >>> Have any of you actually run something like "openssl speed -evp aes-128- >>> gcm" on your platform? I get 1.33GB/s. >> >> Yes, and if you run things twice you get half that performance. >> Regardless of what you're doing, there can be reasons it will be >> useful to disable it - energy, throughput, etc. - when you're in a >> trusted envinronment, e.g., doing a local backup. > > In a trusted environment, you won't be enabling encryption to begin > with. This sounds like complete straw-man to me. To be clear, I'm advocating that it's useful to be able to turn TCP-INC "off" and not use it at all on a connection for this reason. I am not advocating for ways to change things in the middle of a connection. The only point about change in the middle of a connection is that key-rollover can already accommodate that if there's a null-mode algorithm, i.e., no new mechanism needs to be defined because (IMO) key rollover is already a requirement. Joe From nobody Wed Apr 23 19:41:14 2014 Return-Path: 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 EF07E1A02F3 for ; Wed, 23 Apr 2014 19:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 VYb_TYlO0KuL for ; Wed, 23 Apr 2014 19:41:06 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E89D91A02F5 for ; Wed, 23 Apr 2014 19:41:05 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so2246696veb.30 for ; Wed, 23 Apr 2014 19:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p7BSafTMXRO+yhwDKA87x7llYpyCgnHsSOkd6GIroVY=; b=maj4aQFM4LkViHOpLY9HX5ZEdHPEx8TNwww831SR5cdvPvieDPXWLLSnSEsVWgy4QQ BrqZrwQRMh7EyQ3TPQyr+3JXPn9X/DSEPRK3XquSQoRf9iPNVMnbmqZi3wdvY18rFO7o s5k0WZlf/KK2QcGTcOrSsUFkiyreYvpf4dKujejTdAWE7i+g6xRD97gbWlPbXv57sJWR IsQgisaSVpiWuAvZ9zvfr4/Ua7wNns6XbuzLPT2cJ5SFGcyqbIGxqRSQi/Bxd1deveLp 5IG5SDbYxhnNb3btr/sLzUUOIka8kz/pYX342JhQ1TeFGIM+datVoiy3goeDDd/5KAUQ R7Ww== X-Received: by 10.52.249.105 with SMTP id yt9mr2583vdc.34.1398307259936; Wed, 23 Apr 2014 19:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 19:40:38 -0700 (PDT) In-Reply-To: <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> From: Tony Arcieri Date: Wed, 23 Apr 2014 19:40:38 -0700 Message-ID: To: alfiej@fastmail.fm Content-Type: multipart/alternative; boundary=089e015368648411dc04f7c0c7b6 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/4VTMcej0sRgdN3Z5O-yLjs9AR2I Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 02:41:09 -0000 --089e015368648411dc04f7c0c7b6 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 4:28 PM, Alfie John wrote: > In a trusted environment, you won't be enabling encryption to begin with. > If you are dealing with remotely sensitive data, you will want to encrypt in a "trusted" environment too. Source: I work at a company that deals with remotely sensitive data, and we try to encrypt everything everywhere, in the same datacenter, in the same firewall zone (and we have many). It doesn't matter. We want all our flows encrypted. Period. On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch wrote: > To be clear, I'm advocating that it's useful to be able to turn TCP-INC > "off" and not use it at all on a connection for this reason. I am not > advocating for ways to change things in the middle of a connection. > Unless you can absolutely, positively guarantee that this will never be exploitable by an attacker, you are compromising the security of the protocol. TLS did this repeatedly and they're paying the price. I would personally like to see transport encryption that won't compromise security for dubious reasons (e.g. "it's slow, we think! but we didn't bother to measure") -- Tony Arcieri --089e015368648411dc04f7c0c7b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 4:28 PM, Alfie John <alfiej@fastmail.fm> wrote:
In a trusted environment, you won't be= enabling encryption to begin with.

If you are dealing with remotely sensitive data, you= will want to encrypt in a "trusted" environment too. Source: I w= ork at a company that deals with remotely sensitive data, and we try to enc= rypt everything everywhere, in the same datacenter, in the same firewall zo= ne (and we have many). It doesn't matter. We want all our flows encrypt= ed. Period.

On Wed, Apr= 23, 2014 at 5:03 PM, Joe Touch=C2=A0<touch@i= si.edu>=C2=A0wrote:
To be clear, I'm advocating that it= 9;s useful to be able to turn TCP-INC "off" and not use it at all= on a connection for this reason. I am not advocating for ways to change th= ings in the middle of a connection.
=C2=A0
Unless you c= an absolutely, positively guarantee that this will never be exploitable by = an attacker, you are compromising the security of the protocol. TLS did thi= s repeatedly and they're paying the price. I would personally like to s= ee transport encryption that won't compromise security for dubious reas= ons (e.g. "it's slow, we think! but we didn't bother to measur= e")

--
Tony Arcieri
--089e015368648411dc04f7c0c7b6-- From nobody Wed Apr 23 20:12:10 2014 Return-Path: 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 31D6E1A02EC for ; Wed, 23 Apr 2014 20:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 M3sWc1G7HkV4 for ; Wed, 23 Apr 2014 20:12:05 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 440B71A0115 for ; Wed, 23 Apr 2014 20:12:05 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so2165249veb.40 for ; Wed, 23 Apr 2014 20:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wSu8jAtMuXBcfAW+Got7CK+TMot73l8uqsKYd6N+eGU=; b=MBvA1kv+Al+mjp1vWK22l0nTVjQz1aef/aoP2CcIbpEjTXkBHut5GWHsqxso2t2ii1 4s9AJDMgaTz1QqkwvafSFN66W6SjyrHt/6y4YjMl469QmQbwDIbyTC53nlRgQ00IV3Oj 58i+6rezA8PZ3JTGdMe4+DX5BkgZjE8dqf99iDes8WV392BxyJs8814sxO5aSs9m8y05 mDlatCmmzAebqBDtQ8VLJgVMoYbYHPHr4luR2CxLQlnImmEi2NdL1DCcC8GxGLltGaTF YTFvGdM+wogbuwCuH2TSSIKOq07EtwAbWR8IHYF5T7igdV0FQBilFyyM/jh2mzjObzBn /F8Q== X-Received: by 10.52.249.105 with SMTP id yt9mr11040vdc.34.1398309119183; Wed, 23 Apr 2014 20:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 20:11:39 -0700 (PDT) In-Reply-To: <535854BD.7060808@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 20:11:39 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e0153686455d25804f7c136ff Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/z6fv7S941gWQoVtlksSiQ16pXZc Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:12:07 -0000 --089e0153686455d25804f7c136ff Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch wrote: > To be clear, I'm advocating that it's useful to be able to turn TCP-INC > "off" > What is the useful distinction between turning TCP-INC "off" versus not using it in the first place and using a normal TCP connection? The latter is well understood. The former seems like exactly the sort of thing that has lead to various TLS vulnerabilities. -- Tony Arcieri --089e0153686455d25804f7c136ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 5:03 PM, Joe Touch <touch= @isi.edu> wrote:
To be clear, I'm advocat= ing that it's useful to be able to turn TCP-INC "off"

What is the useful distinction between turning TCP-INC = "off" versus not using it in the first place and using a normal T= CP connection?
=C2=A0
The latter is well understood. Th= e former seems like exactly the sort of thing that has lead to various TLS = vulnerabilities.

--
Tony Arcieri
--089e0153686455d25804f7c136ff-- From nobody Wed Apr 23 20:38:48 2014 Return-Path: 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 C49D61A078D for ; Wed, 23 Apr 2014 20:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 K33eGEoltQF3 for ; Wed, 23 Apr 2014 20:38:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0E01A076D for ; Wed, 23 Apr 2014 20:38:40 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O3c1Ti017268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 20:38:11 -0700 (PDT) Message-ID: <5358871D.4080002@isi.edu> Date: Wed, 23 Apr 2014 20:38:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/GC5cXQ-goHLYGMi5UXP72-qUo-Q Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:38:42 -0000 On 4/23/2014 8:11 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch > wrote: > > To be clear, I'm advocating that it's useful to be able to turn > TCP-INC "off" > > > What is the useful distinction between turning TCP-INC "off" versus not > using it in the first place and using a normal TCP connection? None; you just need to set TCP's default to use TCP-INC, and have a user-controllable way to decide to not use TCP-INC. > The latter is well understood. The former seems like exactly the sort of > thing that has lead to various TLS vulnerabilities. Agreed. I am arguing only that there must be a way to decide that a given connection does not need TCP-INC at all. Joe From nobody Wed Apr 23 20:46:33 2014 Return-Path: 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 E879A1A0011 for ; Wed, 23 Apr 2014 20:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 efitXvvLWaTX for ; Wed, 23 Apr 2014 20:46:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5AE1A000F for ; Wed, 23 Apr 2014 20:46:29 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O3jhol018687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 20:45:53 -0700 (PDT) Message-ID: <535888EC.2040608@isi.edu> Date: Wed, 23 Apr 2014 20:45:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri , alfiej@fastmail.fm References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5KXHKCP48bbU_ijzzOBbCAvpMPQ Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:46:31 -0000 On 4/23/2014 7:40 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 4:28 PM, Alfie John > wrote: > > In a trusted environment, you won't be enabling encryption to begin > with. > > > If you are dealing with remotely sensitive data, you will want to > encrypt in a "trusted" environment too. Source: I work at a company that > deals with remotely sensitive data, and we try to encrypt everything > everywhere, in the same datacenter, in the same firewall zone (and we > have many). It doesn't matter. We want all our flows encrypted. Period. That's your choice. Others, in the same situation, would make sure that the data was encrypted *on the disk* (which, IMO, is a safer way to address sensitive data), in which case the only utility in encrypted connections is to protect the connection itself - which may or may not be needed in a given environment. > On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch > wrote: > > To be clear, I'm advocating that it's useful to be able to turn > TCP-INC "off" and not use it at all on a connection for this reason. > I am not advocating for ways to change things in the middle of a > connection. > > Unless you can absolutely, positively guarantee that this will never be > exploitable by an attacker, you are compromising the security of the > protocol. Unless you're proposing a one-time pad, you can't make that guarantee. > TLS did this repeatedly and they're paying the price. I would > personally like to see transport encryption that won't compromise > security for dubious reasons (e.g. "it's slow, we think! but we didn't > bother to measure") All security is a compromise, unless it's a one-time pad. We make trade-offs of strength vs. performance all the time - key length, rounds, etc. And again, I did pick up your gauntlet. I cited not one but two papers of my own that did such measurements; there are dozens of others. So, yes, we have 'bothered' to measure. Even on recent hardware with crypto support, everything costs cycles, time, energy, and throughput. If you have a better argument, this is the time to use it, but "we didn't bother to measure" is provably false. Joe From nobody Wed Apr 23 20:49:19 2014 Return-Path: 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 3B3511A02F5 for ; Wed, 23 Apr 2014 20:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 i_TaWrOEKSKE for ; Wed, 23 Apr 2014 20:49:14 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 893A61A02A3 for ; Wed, 23 Apr 2014 20:49:14 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so2253763vcb.14 for ; Wed, 23 Apr 2014 20:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RPP0Da6vkhts0KmA/aHpvL5Uhnqe/JtT+dDsVbcIBaQ=; b=jHe6xv5Xs7pTkdwg7MXx5pTRyHDEA3BYKZpuNl5Yv7VRegJpEGkRrEj7yuBZfHJTmz 4ye0eEnZhROEUcINEEVSRTyy4i9L8M26ARSEAC3Mu81iZZbqHO1P9mh1I5ecrSLa5ApU Ml98UKtqFHNoeyWNM4vDYeYyBG/Nyl17XgqtmjM7NZobVISRdZuP2ZVECHqx2vpUEhzg ePQQHBolIBDeY6chYnY1sJ/vPEu+YitCJBeE0nO87uguBmGemgJ7gQQjMYpwayiqTIEp 9uFm4vgZ2sai4W30wcuWIkMgPJG5tihCTL5Rvv7Az4q4oU+x9xGR7/HaF/sPSBQD27/Q 6r1g== X-Received: by 10.58.185.145 with SMTP id fc17mr49740372vec.14.1398311348454; Wed, 23 Apr 2014 20:49:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 20:48:47 -0700 (PDT) In-Reply-To: <535888EC.2040608@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 20:48:47 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b67052f35c9a304f7c1bbfe Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/275224YkNLz-_VlXKw70XzmaBJ8 Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:49:16 -0000 --047d7b67052f35c9a304f7c1bbfe Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 8:45 PM, Joe Touch wrote: > Unless you can absolutely, positively guarantee that this will never be > >> exploitable by an attacker, you are compromising the security of the >> protocol. >> > > Unless you're proposing a one-time pad, you can't make that guarantee. You want to add an encryption off-switch to Tcpcrypt. I'm saying: you shouldn't add the switch. If the switch isn't there, the attacker can't shut it off. It's really that simple. -- Tony Arcieri --047d7b67052f35c9a304f7c1bbfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 8:45 PM, Joe Touch <touch= @isi.edu> wrote:
Unless you can absolutely, p= ositively guarantee that this will never be
exploitable by an attacker, you are compromising the security of the
protocol.

Unless you're proposing a one-time pad, you can't make that guarant= ee.

You want to add an encryption off-switc= h to Tcpcrypt. I'm saying: you shouldn't add the switch. If the swi= tch isn't there, the attacker can't shut it off. It's really th= at simple.

--
Tony Arcieri
--047d7b67052f35c9a304f7c1bbfe-- From nobody Wed Apr 23 20:49:55 2014 Return-Path: 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 CCD041A02A3 for ; Wed, 23 Apr 2014 20:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 FyIxsFqXiKkL for ; Wed, 23 Apr 2014 20:49:52 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAF1A02F5 for ; Wed, 23 Apr 2014 20:49:51 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so2295845veb.1 for ; Wed, 23 Apr 2014 20:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jGtAjvvURFNIXDJfGRoZqpJc/Ussq6eGN/PCRLzUNbY=; b=t5m5PSX5HDuTAkqWM6fPvtFM3Avb+1Oi6Prp6qIqKFLoKdf1HNGBScYkSBipEo4AQu s+s9YtGQARLu0Cot3Qf92EIpXKbCj9tCqLYucnDtZy3+teIRhJcPUo8jMZXkZ2wZNDtj t5knCQt8gHafpqEgJe/4Kw5LFu68mzdk0DIludDR1+3q73R7BS24h5BvHF2uJyJm3kow keg4omJYyrSJsafqrvtha6Gt7Y4CaenfaKztVlMnK4adk7tjyddXOsjGlTYnFJRu9QsP smiAczUOALwA/E5AA+Sd64zd9L9mgHSDnpRclBIMhL3z4M5zfSSq5sRq4t0DCg2aH8g4 4I/w== X-Received: by 10.52.104.7 with SMTP id ga7mr13820942vdb.29.1398311385984; Wed, 23 Apr 2014 20:49:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 20:49:25 -0700 (PDT) In-Reply-To: References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 20:49:25 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a1136be727274a704f7c1bd17 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/S2i6lic1NYJcKf0KaEoUu39r-ZQ Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:49:54 -0000 --001a1136be727274a704f7c1bd17 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 8:48 PM, Tony Arcieri wrote: > Unless you're proposing a one-time pad, you can't make that guarantee. > > > You want to add an encryption off-switch to Tcpcrypt. I'm saying: you > shouldn't add the switch. If the switch isn't there, the attacker can't > shut it off. It's really that simple. > This is also the point in the conversation I seriously have to ask: are you working for the NSA to undermine this effort? -- Tony Arcieri --001a1136be727274a704f7c1bd17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 8:48 PM, Tony Arcieri <bascule@gmail.com> wrote:
=
Unless you're proposing a one-time pad, you can't make that guarant= ee.

You want to add an encryption off= -switch to Tcpcrypt. I'm saying: you shouldn't add the switch. If t= he switch isn't there, the attacker can't shut it off. It's rea= lly that simple.

This is also the point i= n the conversation I seriously have to ask: are you working for the NSA to = undermine this effort?

--
Tony Arcieri
--001a1136be727274a704f7c1bd17-- From nobody Wed Apr 23 20:54:37 2014 Return-Path: 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 328951A0422 for ; Wed, 23 Apr 2014 20:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 7wop4GLmE8eo for ; Wed, 23 Apr 2014 20:54:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 14A161A02F5 for ; Wed, 23 Apr 2014 20:54:32 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O3rgpE019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 20:53:52 -0700 (PDT) Message-ID: <53588ACA.3060406@isi.edu> Date: Wed, 23 Apr 2014 20:53:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/67_FOhe0KZfOFqrZfwq_oCjvCwg Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:54:34 -0000 On 4/23/2014 8:48 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 8:45 PM, Joe Touch > wrote: > > Unless you can absolutely, positively guarantee that this will never be > > exploitable by an attacker, you are compromising the security of the > protocol. > > Unless you're proposing a one-time pad, you can't make that guarantee. > > You want to add an encryption off-switch to Tcpcrypt. I'm saying: you > shouldn't add the switch. If the switch isn't there, the attacker can't > shut it off. It's really that simple. I don't want "encryption off" inside TCP-INC. I want "no need to use TCP-INC". If it's not there, nobody will install it. It's *that* simple. Joe From nobody Wed Apr 23 20:55:44 2014 Return-Path: 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 47F9B1A02F5 for ; Wed, 23 Apr 2014 20:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 7ebwxQ78scXZ for ; Wed, 23 Apr 2014 20:55:40 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A3E071A02A3 for ; Wed, 23 Apr 2014 20:55:40 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so2256058vcb.34 for ; Wed, 23 Apr 2014 20:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W1Bs5Z4TIfA5o519e0FDKtp3kA7eexqcWgsv/lczdhc=; b=ms0TcDjqkmxKrBfkJuuU0aFJkLafRUizVt/gH/cfV54mC3EfxOiGgXU7yfD9EwtfAT MhGinpWpPlu5shtjKDWp2CZxCbnez5ptagR/9ocrT3ODhEr2uo/QeJZ2V27WB6Sq/E4a tQCVmWDS3E99oKLkIiWf1ofqw80aEpvVWdpLBTyXoaUtm/I6n2m4qoe8pEjkFCxrFJuG 6Gvv+kXK6oz4TrWD4OMtliWcqux/5K79CQLepFTqHTmIe5gd/If2a6eUaNmIFp/xpAC5 A/aqo4tSlBKDWZLbJz//FxvKwzWdRmgunbU3iiZlKoFQzBLvnWjTz+n+DA4+Gjz9LTWu 3eXw== X-Received: by 10.220.162.6 with SMTP id t6mr46053621vcx.12.1398311734608; Wed, 23 Apr 2014 20:55:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 20:55:14 -0700 (PDT) In-Reply-To: <53588ACA.3060406@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 20:55:14 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c214ec3a0bac04f7c1d2eb Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/pEEPYGm9SEZepDyEL2dNJ3CDLvM Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:55:42 -0000 --001a11c214ec3a0bac04f7c1d2eb Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 8:53 PM, Joe Touch wrote: > I don't want "encryption off" inside TCP-INC. I want "no need to use > TCP-INC". > It's called TCP. Problem solved. ? -- Tony Arcieri --001a11c214ec3a0bac04f7c1d2eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 8:53 PM, Joe Touch <touch= @isi.edu> wrote:
I don't want "encry= ption off" inside TCP-INC. I want "no need to use TCP-INC".<= /div>

It's called TCP. Problem solved.
=

</thread> ?=C2=A0

-- Tony Arcieri
--001a11c214ec3a0bac04f7c1d2eb-- From nobody Wed Apr 23 20:59:32 2014 Return-Path: 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 328051A02F5 for ; Wed, 23 Apr 2014 20:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 XcAIkde5a2ee for ; Wed, 23 Apr 2014 20:59:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2888C1A02A3 for ; Wed, 23 Apr 2014 20:59:30 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O3wdsK020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 20:58:50 -0700 (PDT) Message-ID: <53588BF4.5090307@isi.edu> Date: Wed, 23 Apr 2014 20:58:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/t_0jrPXo5n5Di8ehffSonZs8-FU Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:59:31 -0000 On 4/23/2014 8:49 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 8:48 PM, Tony Arcieri > wrote: > > You want to add an encryption off-switch to Tcpcrypt. I'm saying: > you shouldn't add the switch. If the switch isn't there, the > attacker can't shut it off. It's really that simple. > > This is also the point in the conversation I seriously have to ask: are > you working for the NSA to undermine this effort? You've asked yourself; only you can answer. I work for USC, and (as a consultant) myself on occasion, and no one else. Joe From nobody Wed Apr 23 21:02:34 2014 Return-Path: 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 19FA11A02F5 for ; Wed, 23 Apr 2014 21:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 sRgX_LTng3ag for ; Wed, 23 Apr 2014 21:02:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8119B1A02A3 for ; Wed, 23 Apr 2014 21:02:29 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O41ghA021158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 21:01:52 -0700 (PDT) Message-ID: <53588CAA.7000101@isi.edu> Date: Wed, 23 Apr 2014 21:01:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/z2Db3Zvg5LidkqRNoeHQ0cjW8OQ Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 04:02:32 -0000 On 4/23/2014 8:55 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 8:53 PM, Joe Touch > wrote: > > I don't want "encryption off" inside TCP-INC. I want "no need to use > TCP-INC". > > It's called TCP. Problem solved. IP protocol 6 = TCP TCP includes, when enabled, TCP-INC. So IP protocol 6 = TCP=INC too. I.e., they're *both* TCP. If you default TCP-INC to system-wide being enabled, and there's no way to decide to use TCP without TCP-INC, we have a problem. That's an API issue. Yes, when you use TCP without TCP-INC it's the TCP we're all using today. From nobody Wed Apr 23 21:13:41 2014 Return-Path: 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 DF91C1A029F for ; Wed, 23 Apr 2014 21:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 sTARTLJTL5Vm for ; Wed, 23 Apr 2014 21:13:36 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id AED371A0025 for ; Wed, 23 Apr 2014 21:13:36 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so2240583veb.14 for ; Wed, 23 Apr 2014 21:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=88d3CvHQiV9SFDOKwfkyjyHKYVho34zLmDEiiqqWZMk=; b=VQ5CMerXSaPK8zJCDBgvjoXrFMwbMpfcvoFxqfdQY95KxtD/PRGAERF3wicoiy4fM7 yQLRVV6Nft7O+VUKOxmP+OgAsaNV9KcopA2ht31y0KywPBU9V2E2mBx0so7HiJ8wx+qb 0gh0YTDOtY79R0YIYBkflt2b7pSwNqemSmSSPJ3mxHZIqIcTt76TOQi7fd79BZaafeNM SWQnc20aco/JexomVvQB3zRZJcJePY3khu3oQL+6Je9eqgdadQT0fu1kNtMyxgXpptwx jRnfGwZYjBlSp583Gyn2fmEN0ISW+igobD4aQxSttdGaLUDzAPpiLd6GnATOheKfgzb7 AvrQ== X-Received: by 10.52.104.7 with SMTP id ga7mr13905087vdb.29.1398312810719; Wed, 23 Apr 2014 21:13:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 21:13:10 -0700 (PDT) In-Reply-To: <53588CAA.7000101@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 21:13:10 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a1136be725e305704f7c2127f Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/DN298opTyxaZpaeCLr0ZNMyv1SA Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 04:13:39 -0000 --001a1136be725e305704f7c2127f Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 9:01 PM, Joe Touch wrote: > If you default TCP-INC to system-wide being enabled, and there's no way to > decide to use TCP without TCP-INC, we have a problem. That's an API issue. > > Yes, when you use TCP without TCP-INC it's the TCP we're all using today. > So long as the API boundary is at the time the connection is initiated, i.e. before a single packet has been sent, at the time the socket has been opened, this distinction possibly makes sense. But I'd like to put the burden of proof on you: what is the overhead? Can you please go measure it and report back? I've at least done that due diligence. You have not. Anything in the nature of the subject of this thread, i.e. "disabling encryption in the middle of a connection" completely undermines the purpose of this protocol, IMO. -- Tony Arcieri --001a1136be725e305704f7c2127f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 9:01 PM, Joe Touch <touch= @isi.edu> wrote:
If you default TCP-INC to system-wide bein= g enabled, and there's no way to decide to use TCP without TCP-INC, we = have a problem. That's an API issue.

Yes, when you use TCP without TCP-INC it's the TCP we're all using = today.

So long as the API boundary is a= t the time the connection is initiated, i.e. before a single packet has bee= n sent, at the time the socket has been opened, this distinction possibly m= akes sense. But I'd like to put the burden of proof on you: what is the= overhead? Can you please go measure it and report back? I've at least = done that due diligence. You have not.

Anything in the nature of the subject of this thread, i.e. &= quot;disabling encryption in the middle of a connection" completely un= dermines the purpose of this protocol, IMO.

--
Tony Arcieri
--001a1136be725e305704f7c2127f-- From nobody Wed Apr 23 21:22:09 2014 Return-Path: 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 0272A1A02D0 for ; Wed, 23 Apr 2014 21:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no 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 jtgklqxil6i4 for ; Wed, 23 Apr 2014 21:22:05 -0700 (PDT) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 375F51A02A3 for ; Wed, 23 Apr 2014 21:22:05 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3O4LvtG014183 for ; Thu, 24 Apr 2014 00:21:57 -0400 Received: (qmail 24771 invoked by uid 0); 24 Apr 2014 04:21:57 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 24 Apr 2014 04:21:57 -0000 Message-ID: <53589161.4090700@mti-systems.com> Date: Thu, 24 Apr 2014 00:21:53 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> In-Reply-To: <53576572.5030805@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xMEO4XK4EzCLLIaxAIpRf_UB3uY 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 04:22:07 -0000 On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote: > > The TCP Inc. WG will develop the TCP extensions to provide unauthenticated > encryption and integrity protection of TCP streams. The WG will define the > TCP extensions to perform an unauthenticated key exchange resulting in > encryption > without authentication. This is better than plain-text because it thwarts > passive eavesdropping, but is weaker than using authenticated keys, > because it > is vulnerable to man-in-the-middle attacks. This work is part of the IETF > effort to harness the Internet architecture given the latest events of > pervasive > monitoring (see draft-farrell-perpass-attack). > I'm probably just very bad at locating this in all the discussion, but I have a sort of fundamental question ... why are we trying to do this inside TCP rather than just running TCP over IPsec w/ BTNS (over UDP, if NAT is the concern), or over DTLS? I know it's more fun to do it inside TCP, of course, but I wonder a little bit whether building a security sub-layer inside TCP (which is already hella complex and full of edge cases) is really a good idea when there are already a couple of reasonably decent security protocols designed to be layered over. Sorry for such a silly question, but it seems like it will come up during chartering and should be clearly motivated, as reading the requirements later on in the draft charter, it looks like you could cook up something with BTNS or DTLS under normal TCP to do all that, and it would protect the SYNs (which Joe mentioned is a challenge for TCP-based approaches). I think the charter should speak to this, at least very briefly. -- Wes Eddy MTI Systems From nobody Wed Apr 23 22:26:38 2014 Return-Path: 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 CB8DA1A0794 for ; Wed, 23 Apr 2014 22:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 2A8vEub3uLrQ for ; Wed, 23 Apr 2014 22:26:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 308C81A02CA for ; Wed, 23 Apr 2014 22:26:34 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O5PZ6Y004127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 22:25:45 -0700 (PDT) Message-ID: <5358A053.3050606@isi.edu> Date: Wed, 23 Apr 2014 22:25:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/XGcSLa07JbcO080zqwvrM7d-26I Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 05:26:37 -0000 On 4/23/2014 9:13 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 9:01 PM, Joe Touch > wrote: > > If you default TCP-INC to system-wide being enabled, and there's no > way to decide to use TCP without TCP-INC, we have a problem. That's > an API issue. > > Yes, when you use TCP without TCP-INC it's the TCP we're all using > today. > > > So long as the API boundary is at the time the connection is initiated, > i.e. before a single packet has been sent, at the time the socket has > been opened, this distinction possibly makes sense. That's what I've been saying. > But I'd like to put > the burden of proof on you: And I'd like you to read the papers I cited. If you had, you wouldn't keep asking for proof. > Anything in the nature of the subject of this thread, i.e. "disabling > encryption in the middle of a connection" completely undermines the > purpose of this protocol, IMO. We're already in agreement that it's not useful to do that in the middle of a connection. Which is why I changed the subject to something to more clearly identify the true nature of this thread thus far. Joe From nobody Wed Apr 23 22:29:44 2014 Return-Path: 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 9DF061A02CA for ; Wed, 23 Apr 2014 22:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5mYiQuUNSoDL for ; Wed, 23 Apr 2014 22:29:39 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2441A0063 for ; Wed, 23 Apr 2014 22:29:39 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so2337534vcb.14 for ; Wed, 23 Apr 2014 22:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e4aMyox+PUOPkippu7952lprFfnSTvYhA36jvyKkRP0=; b=UQ7PhHT2f0khw/89YgDGFuLrnbN+uLWNouyNpXH5hjHAhOw+CzwhhoZPCnMSkPQ9nl zca7y53O7Qa9HNaqj7JKvDVR4FVsvxBk0KrsLOuw0QIBLCA8a1LyW9wk0RlqREWhmcDd Mc2ixFkdh/rgggInjsry4MqyJ5cJF0ooECCtK1+Sdc59nQP6aSOKe5nXDrhpigvnLySt IQBtMvE3YimuywcaxKJKxStb9WILN6A2krzEa7R2TDOG7a2+B6d1Wxk34BItRILNpold xfWhw9Lr9VZ/pOT7aA9wbntXGCFE/wfJFYpcVCp5IUvmP6TmpSt1zFQiflz46VUnkvCr 9OfQ== X-Received: by 10.58.49.10 with SMTP id q10mr47850808ven.5.1398317373608; Wed, 23 Apr 2014 22:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 22:29:13 -0700 (PDT) In-Reply-To: <5358A053.3050606@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 22:29:13 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e013a04b65658ae04f7c322bc Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/pD6XaPPbbKhYl1I_afnfdm1IJzI Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 05:29:41 -0000 --089e013a04b65658ae04f7c322bc Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 10:25 PM, Joe Touch wrote: > And I'd like you to read the papers I cited. If you had, you wouldn't keep > asking for proof. > I did look at the papers you cited, namely: "Performance Analysis of MD5" (1995) and "Reducing the impact of DoS attacks on Endpoint IP Security" (2006) Was there something relevant to Tcpcrypt *today* you wished for me to glean from these papers? Did you cite some other papers besides these? It also seems you lied about connections to the NSA? Is there any reason I should continue talking to you? -- Tony Arcieri --089e013a04b65658ae04f7c322bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 10:25 PM, Joe Touch <touc= h@isi.edu> wrote:
And I'd like you to read the papers I cited. If you ha= d, you wouldn't keep asking for proof.

I did look at the papers you cited, namely= :

"Performance Analysis of MD5" (1995)

and

"Reducing the imp= act of DoS attacks on Endpoint IP Security" (2006)

Was there something relevant to Tcpcrypt *today* you wi= shed for me to glean from these papers? Did you cite some other papers besi= des these?

It also seems you lied about connection= s to the NSA? Is there any reason I should continue talking to you?

--
Tony Arcieri
--089e013a04b65658ae04f7c322bc-- From nobody Wed Apr 23 22:44:35 2014 Return-Path: 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 9D0CE1A07A8 for ; Wed, 23 Apr 2014 22:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 vL-xqyxVlJEV for ; Wed, 23 Apr 2014 22:44:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 22DB71A0794 for ; Wed, 23 Apr 2014 22:44:31 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O5hg81006822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 22:43:52 -0700 (PDT) Message-ID: <5358A493.8030707@isi.edu> Date: Wed, 23 Apr 2014 22:43:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Wesley Eddy , tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> In-Reply-To: <53589161.4090700@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/uiPHEVfETf-qLkilwH6p498PT3o 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 05:44:32 -0000 On 4/23/2014 9:21 PM, Wesley Eddy wrote: > On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote: >> >> The TCP Inc. WG will develop the TCP extensions to provide unauthenticated >> encryption and integrity protection of TCP streams. ... > I'm probably just very bad at locating this in all the discussion, but > I have a sort of fundamental question ... why are we trying to do this > inside TCP rather than just running TCP over IPsec w/ BTNS (over UDP, > if NAT is the concern), or over DTLS? I'll take a shot, because the reasons are very similar to the reason TCP-AO is needed vs. IPsec or TLS - can easily use per-connection keys, unlike IPsec IPsec keys would be costly to setup per-connection (e.g., IKE per connection), and would require pinning both source and dest ports; TCP has more state that can make deriving per-connection keys from IPsec-like aggregate keys feasible and more efficient (e.g., as was done in TCP-AO) - can allow key rollover without TCP impact, unlike IPsec IPsec key rollover would result in losses that would impact TCP's congestion control. TCP-AO show show key rollover can be supported without impacting TCP, and even using TCP itself to coordinate the key rollover I haven't considered the impact of running TCP over DTLS and whether it could support the above. The overhead would certainly be higher, but that alone might not be worth creating a new solution. However, at a minimum, a TCP-based solution might at least traverse stateful firewalls in ways that a UDP-based layering might not. > I know it's more fun to do it inside TCP, of course, but I wonder a > little bit whether building a security sub-layer inside TCP (which > is already hella complex and full of edge cases) is really a good > idea when there are already a couple of reasonably decent security > protocols designed to be layered over. See TCP-AO. It wasn't sufficient to layer that over IPsec. We didn't consider a DTLS-based approach at the time because TCP-AO predates DTLS. But see above for reasons a TCP solution might still be useful. I'm also not aware as to whether DTLS has an unauthenticated (BTNS-style) mode. > Sorry for such a silly question, but it seems like it will come up > during chartering and should be clearly motivated, as reading the > requirements later on in the draft charter, it looks like you could > cook up something with BTNS or DTLS under normal TCP to do all that, > and it would protect the SYNs (which Joe mentioned is a challenge > for TCP-based approaches). > > I think the charter should speak to this, at least very briefly. I agree. Joe From nobody Wed Apr 23 23:10:39 2014 Return-Path: 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 D08E71A0062 for ; Wed, 23 Apr 2014 23:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 rHIOYqRsUQHF for ; Wed, 23 Apr 2014 23:10:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7014F1A0309 for ; Wed, 23 Apr 2014 23:10:33 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3O69lbm010699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 23:09:57 -0700 (PDT) Message-ID: <5358AAAF.2040502@isi.edu> Date: Wed, 23 Apr 2014 23:09:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/qn77_MLqlEnnihS3gU2N2OPqpuc Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:10:36 -0000 On 4/23/2014 10:29 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 10:25 PM, Joe Touch > wrote: > > And I'd like you to read the papers I cited. If you had, you > wouldn't keep asking for proof. > > > I did look at the papers you cited, namely: > > "Performance Analysis of MD5" (1995) > > and > > "Reducing the impact of DoS attacks on Endpoint IP Security" (2006) > > Was there something relevant to Tcpcrypt *today* you wished for me to > glean from these papers? Did you cite some other papers besides these? Both papers indicate the performance cost of doing security. Crypto benchmarks are easy to find in any search engine. Here's one from 2014: http://www.tomshardware.com/reviews/mini-pc-round-up,3697-13.html > It also seems you lied about connections to the NSA? It seems you're not familiar with the concept of slander. You might want to review that before continuing to entertain your fantasy conspiracy theories. > Is there any reasIon > I should continue talking to you? Given how little you've learned so far, I hope not. Joe From nobody Wed Apr 23 23:29:38 2014 Return-Path: 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 259651A07AA for ; Wed, 23 Apr 2014 23:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 GOJbBpyS2_ES for ; Wed, 23 Apr 2014 23:29:32 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 232801A07A6 for ; Wed, 23 Apr 2014 23:29:31 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so2402821vcb.33 for ; Wed, 23 Apr 2014 23:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ti6YLHqDURAVqzlMCKj6Xhvkg+NIcF7H6YH9cu0BQlo=; b=ehe9wSpLJ/VW+FfJlRwEpVyCVEStjexHWyZwlth2hCA18fiZhDlWvKeKvDjzSGfYw5 wFKKYFn7kAVwIvB+Ycxk2wsi7hCHotqSv9wr1REwp0HUf5rsfxpFltvGqfchpSTwPJUL rT0XL5oLc7VMmBDVRHqIFIf3dTil0ThLI9vMF8PPSKHB7VuP8HjJzUx7jT2YfvODLub8 oSy9jMa/zXAGm1bjz/Sdz28Xd+PuAsC1hr6Qissg4+dDl3iprXUtt+GlHaCunOPhcYw8 9IPKsXmZ+dMAy8O+lOB1Y3Z33y+3Riz9h+07twh6skct8P/dt8m/1m9kfobmAD7YNLHh GUqw== X-Received: by 10.58.94.135 with SMTP id dc7mr34211veb.66.1398320964877; Wed, 23 Apr 2014 23:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 23 Apr 2014 23:29:04 -0700 (PDT) In-Reply-To: <5358AAAF.2040502@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> From: Tony Arcieri Date: Wed, 23 Apr 2014 23:29:04 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b6da62464c50304f7c3f813 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Pwmqdg7rQdeoPRy_R8_d7Y-kdXY Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:29:35 -0000 --047d7b6da62464c50304f7c3f813 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 11:09 PM, Joe Touch wrote: > Was there something relevant to Tcpcrypt *today* you wished for me to > >> glean from these papers? Did you cite some other papers besides these? >> > > Both papers indicate the performance cost of doing security. Crypto > benchmarks are easy to find in any search engine. Here's one from 2014: > http://www.tomshardware.com/reviews/mini-pc-round-up,3697-13.html You're citing out-of-date papers and Tom's Hardware articles? For the rest of us, there's EBACS: http://bench.cr.yp.to/ -- Tony Arcieri --047d7b6da62464c50304f7c3f813 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 11:09 PM, Joe Touch <touc= h@isi.edu> wrote:
Was there something relevant to Tcpcrypt *today* you = wished for me to
glean from these papers? Did you cite some other papers besides these?

Both papers indicate the performance cost of doing security. Crypto benchma= rks are easy to find in any search engine. Here's one from 2014:
http://www.tomshardware.com/reviews/mini-pc-rou= nd-up,3697-13.html

You're ci= ting out-of-date papers and Tom's Hardware articles?

For the rest of us, there's EBACS:


--
Tony Arcieri
--047d7b6da62464c50304f7c3f813-- From nobody Thu Apr 24 00:35:51 2014 Return-Path: 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 09B911A07C1 for ; Thu, 24 Apr 2014 00:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 e4onWG2j0THk for ; Thu, 24 Apr 2014 00:35:49 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 219AF1A07BB for ; Thu, 24 Apr 2014 00:35:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,917,1389772800"; d="asc'?scan'208";a="119026061" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 24 Apr 2014 00:35:35 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 00:35:35 -0700 From: "Eggert, Lars" To: Tony Arcieri Thread-Topic: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: Draft charter text Thread-Index: AQHPXrtqU057ntHrCke1O5U1q/j2ipsfNteAgAAFqQCAAJl9AIAAAJOAgAEA3oA= Date: Thu, 24 Apr 2014 07:35:34 +0000 Message-ID: <1939519E-0311-4712-A213-4AF901F13F93@netapp.com> References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.21] Content-Type: multipart/signed; boundary="Apple-Mail=_9417DB52-782A-44BB-88C0-106A11EADDFE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/B8yR0b3bXS6R-S9_IhWsyPkMJAo Cc: Paul Lambert , Marcelo Bagnulo , "tcpcrypt@ietf.org" , Olivier Bonaventure Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 07:35:50 -0000 --Apple-Mail=_9417DB52-782A-44BB-88C0-106A11EADDFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-4-23, at 18:16, Tony Arcieri wrote: > The negligible performance impact of double encryption pales in = comparison to the chance that an attacker will be able to maliciously = disable encryption, IMO.=20 Some of us are interested in running this at 40G and eventually 100G. Lars --Apple-Mail=_9417DB52-782A-44BB-88C0-106A11EADDFE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU1i+xtZcnpRveo1xAQIc3gP+O0y3z0uwDwycYM2mI8EI1hHDavDKyl3I PZkaLPAkpQil0cV7mSH6KifPvEbqCOcCS0f7pNAeZj4tlKiCzb3sSG0hMODNdMuT NqXzUtjtieCDUErhVYK8YfRN+SIyDIl1j1iEw07LrnFlJJwfUW03qGryzcaY+zF/ 1cuu1rIwBAA= =TWAF -----END PGP SIGNATURE----- --Apple-Mail=_9417DB52-782A-44BB-88C0-106A11EADDFE-- From nobody Thu Apr 24 01:24:29 2014 Return-Path: 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 A35D81A03E5 for ; Thu, 24 Apr 2014 01:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Po9OKRXh_0HK for ; Thu, 24 Apr 2014 01:24:24 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8F33C1A03A8 for ; Thu, 24 Apr 2014 01:24:24 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 18C236D679; Thu, 24 Apr 2014 04:24:13 -0400 (EDT) Message-ID: <5358CA2D.1060600@iang.org> Date: Thu, 24 Apr 2014 09:24:13 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> In-Reply-To: <5358871D.4080002@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5OosZ8TJw_0X_zbZrb1U7BnTiDw Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:24:26 -0000 On 24/04/2014 04:38 am, Joe Touch wrote: > > > On 4/23/2014 8:11 PM, Tony Arcieri wrote: >> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch > > wrote: >> >> To be clear, I'm advocating that it's useful to be able to turn >> TCP-INC "off" >> >> >> What is the useful distinction between turning TCP-INC "off" versus not >> using it in the first place and using a normal TCP connection? > > None; you just need to set TCP's default to use TCP-INC, and have a > user-controllable way to decide to not use TCP-INC. > >> The latter is well understood. The former seems like exactly the sort of >> thing that has lead to various TLS vulnerabilities. > > Agreed. I am arguing only that there must be a way to decide that a > given connection does not need TCP-INC at all. Surely that's outside the protocol, and therefore outside scope? iang From nobody Thu Apr 24 01:44:26 2014 Return-Path: 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 E18541A07D9 for ; Thu, 24 Apr 2014 01:44:24 -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 FATS2gtgaW6g for ; Thu, 24 Apr 2014 01:44:22 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD161A0125 for ; Thu, 24 Apr 2014 01:44:21 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 53626CD61C9 for ; Thu, 24 Apr 2014 10:44:15 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 47E8BCB7DD8 for ; Thu, 24 Apr 2014 10:44:15 +0200 (CEST) Message-ID: <5358CF10.3050802@it.uc3m.es> Date: Thu, 24 Apr 2014 10:45:04 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> In-Reply-To: <5358CA2D.1060600@iang.org> 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.006 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/T9LluZILZqr-je0kiQ3RyjetmB4 Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:44:25 -0000 El 24/04/14 10:24, ianG escribió: > On 24/04/2014 04:38 am, Joe Touch wrote: >> >> On 4/23/2014 8:11 PM, Tony Arcieri wrote: >>> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch >> > wrote: >>> >>> To be clear, I'm advocating that it's useful to be able to turn >>> TCP-INC "off" >>> >>> >>> What is the useful distinction between turning TCP-INC "off" versus not >>> using it in the first place and using a normal TCP connection? >> None; you just need to set TCP's default to use TCP-INC, and have a >> user-controllable way to decide to not use TCP-INC. >> >>> The latter is well understood. The former seems like exactly the sort of >>> thing that has lead to various TLS vulnerabilities. >> Agreed. I am arguing only that there must be a way to decide that a >> given connection does not need TCP-INC at all. > > Surely that's outside the protocol, and therefore outside scope? In the current version of the charter, this is includedin the extended API work, makes sense? > > iang > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu Apr 24 02:40:01 2014 Return-Path: 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 3C6DF1A07F8 for ; Thu, 24 Apr 2014 02:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 h1zJ8Wnyb8fd for ; Thu, 24 Apr 2014 02:39:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id C55851A013C for ; Thu, 24 Apr 2014 02:39:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9812F6D67D; Thu, 24 Apr 2014 05:39:48 -0400 (EDT) Message-ID: <5358DBE5.8030309@iang.org> Date: Thu, 24 Apr 2014 10:39:49 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> <1939519E-0311-4712-A213-4AF901F13F93@netapp.com> In-Reply-To: <1939519E-0311-4712-A213-4AF901F13F93@netapp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/DX9fm-q5U7n1jrdHeR5cE_xDZ9Y Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:39:59 -0000 On 24/04/2014 08:35 am, Eggert, Lars wrote: > On 2014-4-23, at 18:16, Tony Arcieri wrote: >> The negligible performance impact of double encryption pales in comparison to the chance that an attacker will be able to maliciously disable encryption, IMO. > > Some of us are interested in running this at 40G and eventually 100G. The charter says: ...This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring... - The protocol must be usable by unmodified applications. ... - The protocol must have acceptable performance. ... There is a clear tension between the goal of hyper-performance and the goal of surveillance mitigation for apps that don't know better. I wonder if this is a case of "pick one, or pick both and get neither?" iang From nobody Thu Apr 24 02:55:17 2014 Return-Path: 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 A23EE1A014B for ; Thu, 24 Apr 2014 02:55:15 -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 1PawK-P7_mVo for ; Thu, 24 Apr 2014 02:55:13 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id CF2211A013C for ; Thu, 24 Apr 2014 02:55:12 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7FAA711C59C9 for ; Thu, 24 Apr 2014 11:55:06 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (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 6571E11C5967 for ; Thu, 24 Apr 2014 11:55:06 +0200 (CEST) Message-ID: <5358DF79.1080803@it.uc3m.es> Date: Thu, 24 Apr 2014 11:55:05 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <5357614F.3060109@uclouvain.be> <5357660E.3040707@it.uc3m.es> <1939519E-0311-4712-A213-4AF901F13F93@netapp.com> <5358DBE5.8030309@iang.org> In-Reply-To: <5358DBE5.8030309@iang.org> 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.006 X-TM-AS-Result: No--20.404-7.0-31-1 X-imss-scan-details: No--20.404-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/T-b112C39LLI_3ir639cbTGh8WE Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:55:15 -0000 El 24/04/14 11:39, ianG escribió: > On 24/04/2014 08:35 am, Eggert, Lars wrote: >> On 2014-4-23, at 18:16, Tony Arcieri wrote: >>> The negligible performance impact of double encryption pales in comparison to the chance that an attacker will be able to maliciously disable encryption, IMO. >> Some of us are interested in running this at 40G and eventually 100G. > > The charter says: > > ...This work is part of the IETF effort to harness the Internet > architecture given the latest events of pervasive monitoring... > > - The protocol must be usable by unmodified applications. ... > > - The protocol must have acceptable performance. ... > > > > > > There is a clear tension between the goal of hyper-performance and the > goal of surveillance mitigation for apps that don't know better. > > I wonder if this is a case of "pick one, or pick both and get neither?" > I guess there are many things that are in tension (see for instance, protection and compatibility with NATs) One of the main challenges of any WG i guess is to make the right tradeoffs. IMHO, the charter should make clear what are the features that we are after and leave for the Wg to work out the tradeoffs. Regards, marcelo > > iang > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu Apr 24 02:56:09 2014 Return-Path: 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 733371A0800 for ; Thu, 24 Apr 2014 02:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6] autolearn=no 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 YQ8G5wwOPvOI for ; Thu, 24 Apr 2014 02:56:06 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id ED04E1A0803 for ; Thu, 24 Apr 2014 02:56:05 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 221CC6D62E; Thu, 24 Apr 2014 05:55:57 -0400 (EDT) Message-ID: <5358DFAD.3010501@iang.org> Date: Thu, 24 Apr 2014 10:55:57 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> In-Reply-To: <5358CF10.3050802@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/wX_stI063Vp1Nj7W2vmGPbsYKNU Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:56:07 -0000 On 24/04/2014 09:45 am, marcelo bagnulo braun wrote: > El 24/04/14 10:24, ianG escribió: >> On 24/04/2014 04:38 am, Joe Touch wrote: >>> >>> On 4/23/2014 8:11 PM, Tony Arcieri wrote: >>>> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch >>> > wrote: >>>> >>>> To be clear, I'm advocating that it's useful to be able to turn >>>> TCP-INC "off" >>>> >>>> >>>> What is the useful distinction between turning TCP-INC "off" versus not >>>> using it in the first place and using a normal TCP connection? >>> None; you just need to set TCP's default to use TCP-INC, and have a >>> user-controllable way to decide to not use TCP-INC. >>> >>>> The latter is well understood. The former seems like exactly the >>>> sort of >>>> thing that has lead to various TLS vulnerabilities. >>> Agreed. I am arguing only that there must be a way to decide that a >>> given connection does not need TCP-INC at all. >> >> Surely that's outside the protocol, and therefore outside scope? > > In the current version of the charter, this is includedin the extended > API work, makes sense? Yes, I see it in the charter, and it makes little sense to me, unless the objective was to kill it before it started with a "please-everyone" approach. Clearly, any implementation will include a switch to turn it on or off as part of its development process. Typically distros will include the new extension and default it to off, so that power users can test it out in the real world. When experiences are good, the distros will start pushing it out with default=on. And instructions on how to turn it off. Quite what it means to mandate *in the protocol* an off/on switch makes no sense to me. The devs implementing will know far more, and will be interpreting the need in far more precise ways than belong in the protocol. If anything, in order to recognise the situation and warn people that conforming implementations need to be checked, there could be a comment: "Implementations may include a switch to permit turning the encryption off on a per-connection basis." And leave it at that. Until you get more experience in what works and what is reliable, it's hard to say how this will pan out. (I am here assuming that the goal is as writ, and therefore the default and reliable expectation is that this stuff be on, hard. If the goal is not to address mass surveillance, and is something else, then that's a discussion that should be had and fixed in the charter.) iang From nobody Thu Apr 24 03:12:01 2014 Return-Path: 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 993361A0158 for ; Thu, 24 Apr 2014 03:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.873 X-Spam-Level: X-Spam-Status: No, score=-103.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, 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 8TWYyGcCJC8U for ; Thu, 24 Apr 2014 03:11:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAE31A01A8 for ; Thu, 24 Apr 2014 03:11:32 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C93B8894967 for ; Thu, 24 Apr 2014 12:11:25 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (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 BB42D86AB18 for ; Thu, 24 Apr 2014 12:11:25 +0200 (CEST) Message-ID: <5358E34D.6090105@it.uc3m.es> Date: Thu, 24 Apr 2014 12:11:25 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> In-Reply-To: <5358DFAD.3010501@iang.org> 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.006 X-TM-AS-Result: No--22.505-7.0-31-1 X-imss-scan-details: No--22.505-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5aaQJRlJ1CgTKZib8X2iTmSMZOk Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:11:54 -0000 El 24/04/14 11:55, ianG escribió: > On 24/04/2014 09:45 am, marcelo bagnulo braun wrote: >> El 24/04/14 10:24, ianG escribió: >>> On 24/04/2014 04:38 am, Joe Touch wrote: >>>> On 4/23/2014 8:11 PM, Tony Arcieri wrote: >>>>> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch >>>> > wrote: >>>>> >>>>> To be clear, I'm advocating that it's useful to be able to turn >>>>> TCP-INC "off" >>>>> >>>>> >>>>> What is the useful distinction between turning TCP-INC "off" versus not >>>>> using it in the first place and using a normal TCP connection? >>>> None; you just need to set TCP's default to use TCP-INC, and have a >>>> user-controllable way to decide to not use TCP-INC. >>>> >>>>> The latter is well understood. The former seems like exactly the >>>>> sort of >>>>> thing that has lead to various TLS vulnerabilities. >>>> Agreed. I am arguing only that there must be a way to decide that a >>>> given connection does not need TCP-INC at all. >>> Surely that's outside the protocol, and therefore outside scope? >> In the current version of the charter, this is includedin the extended >> API work, makes sense? > > Yes, I see it in the charter, and it makes little sense to me, unless > the objective was to kill it before it started with a "please-everyone" > approach. > > Clearly, any implementation will include a switch to turn it on or off > as part of its development process. Typically distros will include the > new extension and default it to off, so that power users can test it out > in the real world. When experiences are good, the distros will start > pushing it out with default=on. And instructions on how to turn it off. > > Quite what it means to mandate *in the protocol* an off/on switch makes > no sense to me. The devs implementing will know far more, and will be > interpreting the need in far more precise ways than belong in the protocol. > > If anything, in order to recognise the situation and warn people that > conforming implementations need to be checked, there could be a comment: > "Implementations may include a switch to permit turning the encryption > off on a per-connection basis." So basically you are saying that this should be part of the API and should be a switch available in the implementation that can be set but not by the application but by the system admin, is that it? > > And leave it at that. Until you get more experience in what works and > what is reliable, it's hard to say how this will pan out. > > (I am here assuming that the goal is as writ, and therefore the default > and reliable expectation is that this stuff be on, hard. If the goal is > not to address mass surveillance, and is something else, then that's a > discussion that should be had and fixed in the charter.) > > > > iang > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu Apr 24 03:15:01 2014 Return-Path: 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 0BCBE1A0158 for ; Thu, 24 Apr 2014 03:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6] autolearn=no 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 Y06V2p31Ea01 for ; Thu, 24 Apr 2014 03:14:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id C384A1A014B for ; Thu, 24 Apr 2014 03:14:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 6B4096D68B; Thu, 24 Apr 2014 06:14:46 -0400 (EDT) Message-ID: <5358E416.4050509@iang.org> Date: Thu, 24 Apr 2014 11:14:46 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> In-Reply-To: <5358E34D.6090105@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Z5UkBEcU8Dx4iOI2SA4WFZ0Tt6Y Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:14:59 -0000 On 24/04/2014 11:11 am, marcelo bagnulo braun wrote: > El 24/04/14 11:55, ianG escribió: >> On 24/04/2014 09:45 am, marcelo bagnulo braun wrote: >>> El 24/04/14 10:24, ianG escribió: >>>> On 24/04/2014 04:38 am, Joe Touch wrote: >>>>> On 4/23/2014 8:11 PM, Tony Arcieri wrote: >>>>>> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch >>>>> > wrote: >>>>>> >>>>>> To be clear, I'm advocating that it's useful to be able to turn >>>>>> TCP-INC "off" >>>>>> >>>>>> >>>>>> What is the useful distinction between turning TCP-INC "off" >>>>>> versus not >>>>>> using it in the first place and using a normal TCP connection? >>>>> None; you just need to set TCP's default to use TCP-INC, and have a >>>>> user-controllable way to decide to not use TCP-INC. >>>>> >>>>>> The latter is well understood. The former seems like exactly the >>>>>> sort of >>>>>> thing that has lead to various TLS vulnerabilities. >>>>> Agreed. I am arguing only that there must be a way to decide that a >>>>> given connection does not need TCP-INC at all. >>>> Surely that's outside the protocol, and therefore outside scope? >>> In the current version of the charter, this is includedin the extended >>> API work, makes sense? >> >> Yes, I see it in the charter, and it makes little sense to me, unless >> the objective was to kill it before it started with a "please-everyone" >> approach. >> >> Clearly, any implementation will include a switch to turn it on or off >> as part of its development process. Typically distros will include the >> new extension and default it to off, so that power users can test it out >> in the real world. When experiences are good, the distros will start >> pushing it out with default=on. And instructions on how to turn it off. >> >> Quite what it means to mandate *in the protocol* an off/on switch makes >> no sense to me. The devs implementing will know far more, and will be >> interpreting the need in far more precise ways than belong in the >> protocol. >> >> If anything, in order to recognise the situation and warn people that >> conforming implementations need to be checked, there could be a comment: >> "Implementations may include a switch to permit turning the encryption >> off on a per-connection basis." > > So basically you are saying that this should be part of the API and > should be a switch available in the implementation that can be set but > not by the application but by the system admin, is that it? No, that's not what I am saying. iang >> And leave it at that. Until you get more experience in what works and >> what is reliable, it's hard to say how this will pan out. >> >> (I am here assuming that the goal is as writ, and therefore the default >> and reliable expectation is that this stuff be on, hard. If the goal is >> not to address mass surveillance, and is something else, then that's a >> discussion that should be had and fixed in the charter.) >> >> >> >> iang >> >> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >> > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Thu Apr 24 04:34:52 2014 Return-Path: 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 CDB1E1A0193 for ; Thu, 24 Apr 2014 04:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.873 X-Spam-Level: X-Spam-Status: No, score=-103.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, 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 BY2oojvOgOHx for ; Thu, 24 Apr 2014 04:34:45 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 452E21A0191 for ; Thu, 24 Apr 2014 04:34:44 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C82F8B6FB4 for ; Thu, 24 Apr 2014 13:34:38 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.87.138] (unknown [163.117.87.138]) (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 10CDB86A869 for ; Thu, 24 Apr 2014 13:34:38 +0200 (CEST) Message-ID: <5358F6CD.7030500@it.uc3m.es> Date: Thu, 24 Apr 2014 13:34:37 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> <5358E416.4050509@iang.org> In-Reply-To: <5358E416.4050509@iang.org> 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.006 X-TM-AS-Result: No--25.408-7.0-31-1 X-imss-scan-details: No--25.408-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xwGkvdShFv_RX85cdoR4Esn9c_w Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:34:50 -0000 El 24/04/14 12:14, ianG escribió: > On 24/04/2014 11:11 am, marcelo bagnulo braun wrote: >> El 24/04/14 11:55, ianG escribió: >>> On 24/04/2014 09:45 am, marcelo bagnulo braun wrote: >>>> El 24/04/14 10:24, ianG escribió: >>>>> On 24/04/2014 04:38 am, Joe Touch wrote: >>>>>> On 4/23/2014 8:11 PM, Tony Arcieri wrote: >>>>>>> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch >>>>>> > wrote: >>>>>>> >>>>>>> To be clear, I'm advocating that it's useful to be able to turn >>>>>>> TCP-INC "off" >>>>>>> >>>>>>> >>>>>>> What is the useful distinction between turning TCP-INC "off" >>>>>>> versus not >>>>>>> using it in the first place and using a normal TCP connection? >>>>>> None; you just need to set TCP's default to use TCP-INC, and have a >>>>>> user-controllable way to decide to not use TCP-INC. >>>>>> >>>>>>> The latter is well understood. The former seems like exactly the >>>>>>> sort of >>>>>>> thing that has lead to various TLS vulnerabilities. >>>>>> Agreed. I am arguing only that there must be a way to decide that a >>>>>> given connection does not need TCP-INC at all. >>>>> Surely that's outside the protocol, and therefore outside scope? >>>> In the current version of the charter, this is includedin the extended >>>> API work, makes sense? >>> Yes, I see it in the charter, and it makes little sense to me, unless >>> the objective was to kill it before it started with a "please-everyone" >>> approach. >>> >>> Clearly, any implementation will include a switch to turn it on or off >>> as part of its development process. Typically distros will include the >>> new extension and default it to off, so that power users can test it out >>> in the real world. When experiences are good, the distros will start >>> pushing it out with default=on. And instructions on how to turn it off. >>> >>> Quite what it means to mandate *in the protocol* an off/on switch makes >>> no sense to me. The devs implementing will know far more, and will be >>> interpreting the need in far more precise ways than belong in the >>> protocol. >>> >>> If anything, in order to recognise the situation and warn people that >>> conforming implementations need to be checked, there could be a comment: >>> "Implementations may include a switch to permit turning the encryption >>> off on a per-connection basis." >> So basically you are saying that this should be part of the API and >> should be a switch available in the implementation that can be set but >> not by the application but by the system admin, is that it? Sorry, i meant, this should _not_ be part of the API and should be a switch available in the implementation that can be set but not by the application but by the system admin, better now? > > No, that's not what I am saying. > > iang > > >>> And leave it at that. Until you get more experience in what works and >>> what is reliable, it's hard to say how this will pan out. >>> >>> (I am here assuming that the goal is as writ, and therefore the default >>> and reliable expectation is that this stuff be on, hard. If the goal is >>> not to address mass surveillance, and is something else, then that's a >>> discussion that should be had and fixed in the charter.) >>> >>> >>> >>> iang >>> >>> >>> _______________________________________________ >>> Tcpcrypt mailing list >>> Tcpcrypt@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpcrypt >>> >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu Apr 24 05:41:53 2014 Return-Path: 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 A8E001A01CD for ; Thu, 24 Apr 2014 05:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 yYAXs050n9jm for ; Thu, 24 Apr 2014 05:41:47 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id CCB921A01B3 for ; Thu, 24 Apr 2014 05:41:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3OCfetv025907 for ; Thu, 24 Apr 2014 08:41:40 -0400 Received: (qmail 1054 invoked by uid 0); 24 Apr 2014 12:41:40 -0000 X-TCPREMOTEIP: 107.45.66.66 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.66.66) by 0 with ESMTPA; 24 Apr 2014 12:41:36 -0000 Message-ID: <5359067C.7000306@mti-systems.com> Date: Thu, 24 Apr 2014 08:41:32 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <5358A493.8030707@isi.edu> In-Reply-To: <5358A493.8030707@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/lXNoLoNSsU_0IhZ7Z_hTKI1LOi4 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:41:51 -0000 On 4/24/2014 1:43 AM, Joe Touch wrote: > > > On 4/23/2014 9:21 PM, Wesley Eddy wrote: >> On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote: >>> >>> The TCP Inc. WG will develop the TCP extensions to provide >>> unauthenticated >>> encryption and integrity protection of TCP streams. > ... >> I'm probably just very bad at locating this in all the discussion, but >> I have a sort of fundamental question ... why are we trying to do this >> inside TCP rather than just running TCP over IPsec w/ BTNS (over UDP, >> if NAT is the concern), or over DTLS? > > I'll take a shot, because the reasons are very similar to the reason > TCP-AO is needed vs. IPsec or TLS > > - can easily use per-connection keys, unlike IPsec > IPsec keys would be costly to setup per-connection (e.g., > IKE per connection), and would require pinning both > source and dest ports; TCP has more state > that can make deriving per-connection keys from > IPsec-like aggregate keys feasible and more efficient > (e.g., as was done in TCP-AO) This was the one I thought of too, but wasn't sure if there might be some IKE extensions possible to get a similar effect that might be lower-impact (like done in user-space, and maybe valuable for other flows than just TCP). > - can allow key rollover without TCP impact, unlike IPsec > IPsec key rollover would result in losses that would > impact TCP's congestion control. TCP-AO show show > key rollover can be supported without impacting > TCP, and even using TCP itself to coordinate the > key rollover This part is interesting and I hadn't thought of it; thanks. > I haven't considered the impact of running TCP over DTLS and whether it > could support the above. The overhead would certainly be higher, but > that alone might not be worth creating a new solution. Yeah, and I hesitated to suggest that too, because it winds up looking like an RTCWEB towering Jenga stack of protocols. > However, at a minimum, a TCP-based solution might at least traverse > stateful firewalls in ways that a UDP-based layering might not. > >> I know it's more fun to do it inside TCP, of course, but I wonder a >> little bit whether building a security sub-layer inside TCP (which >> is already hella complex and full of edge cases) is really a good >> idea when there are already a couple of reasonably decent security >> protocols designed to be layered over. > > See TCP-AO. It wasn't sufficient to layer that over IPsec. We didn't > consider a DTLS-based approach at the time because TCP-AO predates DTLS. > But see above for reasons a TCP solution might still be useful. Yes, I know AO just a little since I was co-chair of the working group for it :). At the time AO was done, some of the criticisms of IPsec were captured in: http://tools.ietf.org/html/draft-bellovin-tcpsec-01 I could summarize those as: - no good API for protecting an individual TCP connection - NAT traversal issues - masking fields used for QoS or TE I don't think "TCP in IPsec in UDP" was considered at the time. > I'm also not aware as to whether DTLS has an unauthenticated > (BTNS-style) mode. Nor am I, but adding it (if needed) would *seem to me* simpler than the equivalent TCP modifications, plus be deployable and upgradeable in userland. I'm sure there are dozens of people who know better though. -- Wes Eddy MTI Systems From nobody Thu Apr 24 05:51:20 2014 Return-Path: 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 746E91A01D2 for ; Thu, 24 Apr 2014 05:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6] autolearn=no 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 oHIrom3iQ3xh for ; Thu, 24 Apr 2014 05:51:11 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4FD1A01B9 for ; Thu, 24 Apr 2014 05:51:11 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id BCCE06D4B0; Thu, 24 Apr 2014 08:51:00 -0400 (EDT) Message-ID: <535908B2.8010900@iang.org> Date: Thu, 24 Apr 2014 13:50:58 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> <5358E416.4050509@iang.org> <5358F6CD.7030500@it.uc3m.es> In-Reply-To: <5358F6CD.7030500@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/rZpOKYqduvevJpyy2Om2_-UIthk Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:51:12 -0000 On 24/04/2014 12:34 pm, marcelo bagnulo braun wrote: > El 24/04/14 12:14, ianG escribió: >> On 24/04/2014 11:11 am, marcelo bagnulo braun wrote: >>> El 24/04/14 11:55, ianG escribió: ... >>>> Clearly, any implementation will include a switch to turn it on or off >>>> as part of its development process. Typically distros will include the >>>> new extension and default it to off, so that power users can test it >>>> out >>>> in the real world. When experiences are good, the distros will start >>>> pushing it out with default=on. And instructions on how to turn it >>>> off. >>>> >>>> Quite what it means to mandate *in the protocol* an off/on switch makes >>>> no sense to me. The devs implementing will know far more, and will be >>>> interpreting the need in far more precise ways than belong in the >>>> protocol. >>>> >>>> If anything, in order to recognise the situation and warn people that >>>> conforming implementations need to be checked, there could be a >>>> comment: >>>> "Implementations may include a switch to permit turning the >>>> encryption >>>> off on a per-connection basis." >>> So basically you are saying that this should be part of the API and >>> should be a switch available in the implementation that can be set but >>> not by the application but by the system admin, is that it? > > Sorry, i meant, > > this should _not_ be part of the API Well, the API is typically out of scope of the protocol, that's an implementation issue, so I'm not saying anything about the API. But, if we were to drift over to that discussion (and this might be necessary or indicative of a flaw in the process) then yes, it might be in the API, it might just come out in the wash. Reason for this is that (iirc) KEX must be acceptable as handled externally. Which means you have the requirement that in initiation of the connection, the key must be providable. I.e., it must be an option to say "open this connection, use this key." Which then means that it is pretty easy to provide a null key and thus encryption is likely off. Which is to say, there is no necessary presumption of a transparent mode that just bootstraps, thus contradicting the goal of having apps use this stuff without knowing about it, and gaining some security. ==> some choices aren't clear yet. To me, it seems that some design has to be done before some of these choices can be highlighted and requirements can be tied down. Process seems backwards. > and should be a switch available in > the implementation NO, not should, but will. There *will be* a switch, whether the protocol likes it or not. That's just how these things will get implemented. The challenge is to get rid of the switch. > that can be set but not by the application but by the > system admin, That will be the implementation's choice. I'm not saying, either way, at all. Obviously, choices here will be dramatic, which is why Tony is against it. If a sysadm can set it, we're back to IPSec and it's a no go. If the implementation is expected to set it, we're back to choosing TLS and it won't be used... iang From nobody Thu Apr 24 08:55:44 2014 Return-Path: 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 034BA1A036B for ; Thu, 24 Apr 2014 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 ST-JK9vWcLht for ; Thu, 24 Apr 2014 08:55:40 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4B1A0227 for ; Thu, 24 Apr 2014 08:55:40 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3OFtXv9031036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2014 08:55:33 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3OFtX7c031035; Thu, 24 Apr 2014 08:55:33 -0700 (PDT) (envelope-from jmg) Date: Thu, 24 Apr 2014 08:55:33 -0700 From: John-Mark Gurney To: Wesley Eddy Message-ID: <20140424155532.GR43976@funkthat.com> References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53589161.4090700@mti-systems.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 24 Apr 2014 08:55:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/z264Zfe1qDrZkl-fvpslVktA6jM Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:55:42 -0000 Wesley Eddy wrote this message on Thu, Apr 24, 2014 at 00:21 -0400: > On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote: > > > > The TCP Inc. WG will develop the TCP extensions to provide unauthenticated > > encryption and integrity protection of TCP streams. The WG will define the > > TCP extensions to perform an unauthenticated key exchange resulting in > > encryption > > without authentication. This is better than plain-text because it thwarts > > passive eavesdropping, but is weaker than using authenticated keys, > > because it > > is vulnerable to man-in-the-middle attacks. This work is part of the IETF > > effort to harness the Internet architecture given the latest events of > > pervasive > > monitoring (see draft-farrell-perpass-attack). > > > I'm probably just very bad at locating this in all the discussion, but > I have a sort of fundamental question ... why are we trying to do this > inside TCP rather than just running TCP over IPsec w/ BTNS (over UDP, > if NAT is the concern), or over DTLS? Have you read the original tcpcrypt paper? > I know it's more fun to do it inside TCP, of course, but I wonder a > little bit whether building a security sub-layer inside TCP (which > is already hella complex and full of edge cases) is really a good > idea when there are already a couple of reasonably decent security > protocols designed to be layered over. > > Sorry for such a silly question, but it seems like it will come up > during chartering and should be clearly motivated, as reading the > requirements later on in the draft charter, it looks like you could > cook up something with BTNS or DTLS under normal TCP to do all that, > and it would protect the SYNs (which Joe mentioned is a challenge > for TCP-based approaches). > > I think the charter should speak to this, at least very briefly. It does very briefly: - The protocol must be usable by unmodified applications. All the things you mentioned seems like it would require agreement between systems and management by a sysadmin, but this is targeted to end users system (like smart phones) too... If TCP is the only protocol allowed through a firewall, how are any of your other solutions going to work? The goal is to make it very easy for everyone to deploy... Configuring IPSEC is a pain, and as Joe mentions, most implementations don't handle key roll over properly (even though apparently, you're allowed to keep both the old key and the new key around for the transition period to handle this case)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Thu Apr 24 09:01:48 2014 Return-Path: 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 4F60B1A0395 for ; Thu, 24 Apr 2014 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DNh3VG3-9Ytu for ; Thu, 24 Apr 2014 09:01:46 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD1371A02AD for ; Thu, 24 Apr 2014 09:01:45 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3OG1aoZ031151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2014 09:01:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3OG1aEk031150; Thu, 24 Apr 2014 09:01:36 -0700 (PDT) (envelope-from jmg) Date: Thu, 24 Apr 2014 09:01:36 -0700 From: John-Mark Gurney To: Joe Touch Message-ID: <20140424160136.GS43976@funkthat.com> References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535854BD.7060808@isi.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 24 Apr 2014 09:01:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5d85-0aHBPgscBEZOHPpVY9NFoU Cc: alfiej@fastmail.fm, tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:01:47 -0000 Joe Touch wrote this message on Wed, Apr 23, 2014 at 17:03 -0700: > > > On 4/23/2014 4:28 PM, Alfie John wrote: > >On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote: > >>>Adding off-switches for security features "for speed" without > >>>measurements is completely antithetical to the goals I would hope > >>>Tcpcrypt has. > >>> > >>>Have any of you actually run something like "openssl speed -evp aes-128- > >>>gcm" on your platform? I get 1.33GB/s. > >> > >>Yes, and if you run things twice you get half that performance. > >>Regardless of what you're doing, there can be reasons it will be > >>useful to disable it - energy, throughput, etc. - when you're in a > >>trusted envinronment, e.g., doing a local backup. > > > >In a trusted environment, you won't be enabling encryption to begin > >with. This sounds like complete straw-man to me. > > To be clear, I'm advocating that it's useful to be able to turn TCP-INC > "off" and not use it at all on a connection for this reason. I am not > advocating for ways to change things in the middle of a connection. > > The only point about change in the middle of a connection is that > key-rollover can already accommodate that if there's a null-mode > algorithm, i.e., no new mechanism needs to be defined because (IMO) key > rollover is already a requirement. IMO, rolling over to a null-mode algorithm is the equivalent of turning TCP-INC off in the middle of a connection... If this is allowed we MUST require that both sides agree to the downgrade, and not allow one side to do it... So, please don't say you don't advocate turning off TCP-INC when you make the above statement... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Thu Apr 24 10:28:43 2014 Return-Path: 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 BD8521A0227 for ; Thu, 24 Apr 2014 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 tjbYSsfSeK2I for ; Thu, 24 Apr 2014 10:28:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE41A01DB for ; Thu, 24 Apr 2014 10:28:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OHQvXk001299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 10:27:09 -0700 (PDT) Message-ID: <53594962.2050802@isi.edu> Date: Thu, 24 Apr 2014 10:26:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <20140424160136.GS43976@funkthat.com> In-Reply-To: <20140424160136.GS43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/0ik1M47Qzu2CYmM0wEuqTlYAoyI Cc: alfiej@fastmail.fm, tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:28:41 -0000 On 4/24/2014 9:01 AM, John-Mark Gurney wrote: > Joe Touch wrote this message on Wed, Apr 23, 2014 at 17:03 -0700: >> >> >> On 4/23/2014 4:28 PM, Alfie John wrote: >>> On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote: >>>>> Adding off-switches for security features "for speed" without >>>>> measurements is completely antithetical to the goals I would hope >>>>> Tcpcrypt has. >>>>> >>>>> Have any of you actually run something like "openssl speed -evp aes-128- >>>>> gcm" on your platform? I get 1.33GB/s. >>>> >>>> Yes, and if you run things twice you get half that performance. >>>> Regardless of what you're doing, there can be reasons it will be >>>> useful to disable it - energy, throughput, etc. - when you're in a >>>> trusted envinronment, e.g., doing a local backup. >>> >>> In a trusted environment, you won't be enabling encryption to begin >>> with. This sounds like complete straw-man to me. >> >> To be clear, I'm advocating that it's useful to be able to turn TCP-INC >> "off" and not use it at all on a connection for this reason. I am not >> advocating for ways to change things in the middle of a connection. >> >> The only point about change in the middle of a connection is that >> key-rollover can already accommodate that if there's a null-mode >> algorithm, i.e., no new mechanism needs to be defined because (IMO) key >> rollover is already a requirement. > > IMO, rolling over to a null-mode algorithm is the equivalent of turning > TCP-INC off in the middle of a connection... If this is allowed we > MUST require that both sides agree to the downgrade, and not allow one > side to do it... Both sides have to agree to the key rollover anyway. > So, please don't say you don't advocate turning off TCP-INC when you > make the above statement... I am not advocating for downgrade; I am demonstrating how a mechanism that's already necessary can support downgrade with no additional complexity. Also, there are useful cases for upgrade - starting with NULL keys and enabling encryption later. That cannot be done unless TCP-INC is negotiated in the three-way handshake at the beginning of a connection. Joe From nobody Thu Apr 24 10:42:36 2014 Return-Path: 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 C9CD21A036B for ; Thu, 24 Apr 2014 10:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 COYqHMkUL7t6 for ; Thu, 24 Apr 2014 10:42:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DE4691A0227 for ; Thu, 24 Apr 2014 10:42:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OHg0Yo006377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 10:42:00 -0700 (PDT) Message-ID: <53594CE9.4020805@isi.edu> Date: Thu, 24 Apr 2014 10:42:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> <5358E416.4050509@iang.org> <5358F6CD.7030500@it.uc3m.es> <535908B2.8010900@iang.org> In-Reply-To: <535908B2.8010900@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/XB-yYCyZ1Ff3cCTFHVqi0zpckEk Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:42:34 -0000 On 4/24/2014 5:50 AM, ianG wrote: ... >> Sorry, i meant, >> >> this should _not_ be part of the API > > Well, the API is typically out of scope of the protocol, that's an > implementation issue, so I'm not saying anything about the API. A protocol is: - endpoint state - upper and lower layer interface actions - message actions (formats of what is sent/received) - rules for how the above three interact If you omit the API, you don't have a protocol. RFC793 includes an API, and all protocols should. The IETF's position on this has often confused API with "API implementation", and by claiming that an API isn't a core part of a protocol, has hampered protocol specification for many years. It's time to stop that error. Joe From nobody Thu Apr 24 11:18:11 2014 Return-Path: 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 601D11A0395 for ; Thu, 24 Apr 2014 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dPuBKNk_2iuy for ; Thu, 24 Apr 2014 11:18:01 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 647651A0381 for ; Thu, 24 Apr 2014 11:18:01 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 43F8A6D5EB; Thu, 24 Apr 2014 14:17:49 -0400 (EDT) Message-ID: <5359554B.201@iang.org> Date: Thu, 24 Apr 2014 19:17:47 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> <5358E416.4050509@iang.org> <5358F6CD.7030500@it.uc3m.es> <535908B2.8010900@iang.org> <53594CE9.4020805@isi.edu> In-Reply-To: <53594CE9.4020805@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/kjTkGh-OMwoJ_6KslSYx0Mq_svg Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:18:03 -0000 On 24/04/2014 18:42 pm, Joe Touch wrote: > > > On 4/24/2014 5:50 AM, ianG wrote: > ... >>> Sorry, i meant, >>> >>> this should _not_ be part of the API >> >> Well, the API is typically out of scope of the protocol, that's an >> implementation issue, so I'm not saying anything about the API. > > A protocol is: > > - endpoint state > - upper and lower layer interface actions > - message actions (formats of what is sent/received) > - rules for how the above three interact > > If you omit the API, you don't have a protocol. RFC793 includes an API, > and all protocols should. Ah. So, by API we don't mean Application Programming Interface, which is by definition an implementation issue as it's programming, but Interface Actions (IA) which is by nature a protocol issue. Fine, so s/API/IA/g and I'm cool. > The IETF's position on this has often confused API with "API > implementation", and by claiming that an API isn't a core part of a > protocol, has hampered protocol specification for many years. It's time > to stop that error. Yes, I can see that... iang From nobody Thu Apr 24 11:50:27 2014 Return-Path: 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 AC6161A036B for ; Thu, 24 Apr 2014 11:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 8MbDISthWxNo for ; Thu, 24 Apr 2014 11:50:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 68AD11A0330 for ; Thu, 24 Apr 2014 11:50:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OIo6dE028515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 11:50:06 -0700 (PDT) Message-ID: <53595CDE.3000403@isi.edu> Date: Thu, 24 Apr 2014 11:50:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <534569A0.9020505@fifthhorseman.net> <20140410085034.tv16loo60c0wco8k@webcartero01.uc3m.es> <5348528D.1030101@isi.edu> <20140413090902.x1yd873rkcco4g8o@webcartero01.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535854BD.7060808@isi.edu> <5358871D.4080002@isi.edu> <5358CA2D.1060600@iang.org> <5358CF10.3050802@it.uc3m.es> <5358DFAD.3010501@iang.org> <5358E34D.6090105@it.uc3m.es> <5358E416.4050509@iang.org> <5358F6CD.7030500@it.uc3m.es> <535908B2.8010900@iang.org> <53594CE9.4020805@isi.edu> <5359554B.201@iang.org> In-Reply-To: <5359554B.201@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/DFrezcC9kXDQRv3xZqWknURbu5c Subject: Re: [Tcpcrypt] disabling encryption in the middle of a connection (was Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:50:24 -0000 On 4/24/2014 11:17 AM, ianG wrote: > On 24/04/2014 18:42 pm, Joe Touch wrote: >> >> >> On 4/24/2014 5:50 AM, ianG wrote: >> ... >>>> Sorry, i meant, >>>> >>>> this should _not_ be part of the API >>> >>> Well, the API is typically out of scope of the protocol, that's an >>> implementation issue, so I'm not saying anything about the API. >> >> A protocol is: >> >> - endpoint state >> - upper and lower layer interface actions >> - message actions (formats of what is sent/received) >> - rules for how the above three interact >> >> If you omit the API, you don't have a protocol. RFC793 includes an API, >> and all protocols should. > > Ah. So, by API we don't mean Application Programming Interface, which > is by definition an implementation issue as it's programming, but > Interface Actions (IA) which is by nature a protocol issue. In the transport world, "application" is defined as the layer above transport, so API is an accurate term. However, yes, this is intended as "the interface to the upper and lower layer events", not merely "how Unix function calls are arranged". > Fine, so s/API/IA/g and I'm cool. Me too ;-) Joe From nobody Thu Apr 24 11:52:52 2014 Return-Path: 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 4E5721A0330 for ; Thu, 24 Apr 2014 11:52:47 -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 jeFBh5EumqBE for ; Thu, 24 Apr 2014 11:52:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 748C31A032B for ; Thu, 24 Apr 2014 11:52:43 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D11C18A7476; Thu, 24 Apr 2014 20:52:36 +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 9EE87767947; Thu, 24 Apr 2014 20:52:36 +0200 (CEST) Message-ID: <53595D73.2020609@it.uc3m.es> Date: Thu, 24 Apr 2014 20:52:35 +0200 From: marcelo bagnulo braun 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: <874n1i7hvo.fsf@ta.scs.stanford.edu> In-Reply-To: <874n1i7hvo.fsf@ta.scs.stanford.edu> X-Forwarded-Message-Id: <874n1i7hvo.fsf@ta.scs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20654.001 X-TM-AS-Result: No--18.105-7.0-31-1 X-imss-scan-details: No--18.105-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/j8FgcjH64jBKPsmQabBeyFRpA5Q Cc: David Mazieres expires 2014-04-06 PDT Subject: [Tcpcrypt] Fwd: Disabling encryption, null ciphers, double encryption X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:52:47 -0000 -------- Mensaje original -------- Asunto: Participating in the tcpcrypt discussion Fecha: Thu, 24 Apr 2014 10:32:43 -0700 De: David Mazieres expires 2014-07-23 PDT Para: marcelo bagnulo braun Forwarding this email on behalf of David Mazieres as it seems his email address bounces in the tcpcrypt ml... From: David Mazieres To: tcpcrypt@ietf.org Subject: Disabling encryption, null ciphers, double encryption Reply-To: David Mazieres expires 2014-07-22 PDT Date: Wed, 23 Apr 2014 17:50:57 -0700 Message-ID: <878uqv4kjy.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Nobody forces you to use TCP for a particular application. But if you choose TCP, you get congestion control. There's no configuration option by which you can disable the congestion window or plug in the "null congestion window decrease algorithm." Such concepts make no sense because everybody uses TCP with the expectation that it will react to network congestion. That is the sense in which TCP Inc. must provide forward secrecy. Once TCP Inc. is active on a connection, there must be no null or weak ciphers, there must be no way to disable encryption, and implementations should not provide access to session keys in such a way that they can be logged or otherwise disclosed. Not everyone will want to use TCP Inc., but when it's active, users must have confidence that their communications are protected from passive eavesdroppers regardless of configuration. Of course, incremental deployment will be critical. Systems will ship with TCP Inc. long before enabling it by default. We can't expect people to turn it on all at once, either, meaning implementations must allow selection of TCP Inc. vs. plain TCP on a per-connection basis. Some will likely use this per-connection control to disable TCP Inc. underneath SSL and avoid "double encryption" (which could more precisely be termed "encryption at two separate layers"). We can argue about whether or not that's advisable, but it depends on the situation and is not something we can prevent anyway. Conversely, applications may wish to tweak behavior such as endpoint authentication in the presence of TCP Inc. Doing so requires an out-of-band signaling mechanism for compatibility. Such a signaling mechanism will allow applications to disable application-layer encryption in the presence of TCP Inc., particularly where TCP Inc. is deemed more secure than legacy or home-grown application-layer crypto (which often lacks forward secrecy). Whether disabling application-layer encryption over TCP Inc. is advisable depends on the specifics, but cannot be prevented in any case. So to summarize: TCP Inc. is just an option. However, once enabled, it must provide security guarantees consistent across all permissible configurations. Certain mandatory features of TCP Inc. will, among other uses, permit the avoidance of double encryption. Fortunately, the success of the TCP Inc. working group does not require consensus on the advisability of avoiding double encryption. David From nobody Thu Apr 24 11:53:09 2014 Return-Path: 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 2F94A1A038E for ; Thu, 24 Apr 2014 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 TFipmckJVymd for ; Thu, 24 Apr 2014 11:52:58 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C01A0381 for ; Thu, 24 Apr 2014 11:52:58 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3OIqoFY012874 for ; Thu, 24 Apr 2014 14:52:50 -0400 Received: (qmail 7162 invoked by uid 0); 24 Apr 2014 18:52:50 -0000 X-TCPREMOTEIP: 107.45.66.66 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.66.66) by 0 with ESMTPA; 24 Apr 2014 18:52:47 -0000 Message-ID: <53595D7A.2030503@mti-systems.com> Date: Thu, 24 Apr 2014 14:52:42 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John-Mark Gurney References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> In-Reply-To: <20140424155532.GR43976@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Xm7Mnmub93NHvLwc96O64J-pki0 Cc: tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:53:02 -0000 On 4/24/2014 11:55 AM, John-Mark Gurney wrote: > Wesley Eddy wrote this message on Thu, Apr 24, 2014 at 00:21 -0400: >> On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote: >>> >>> The TCP Inc. WG will develop the TCP extensions to provide >>> unauthenticated encryption and integrity protection of TCP >>> streams. The WG will define the TCP extensions to perform an >>> unauthenticated key exchange resulting in encryption without >>> authentication. This is better than plain-text because it >>> thwarts passive eavesdropping, but is weaker than using >>> authenticated keys, because it is vulnerable to man-in-the-middle >>> attacks. This work is part of the IETF effort to harness the >>> Internet architecture given the latest events of pervasive >>> monitoring (see draft-farrell-perpass-attack). >> >> >> I'm probably just very bad at locating this in all the discussion, >> but I have a sort of fundamental question ... why are we trying to >> do this inside TCP rather than just running TCP over IPsec w/ BTNS >> (over UDP, if NAT is the concern), or over DTLS? > > Have you read the original tcpcrypt paper? Yes (assuming you mean USENIX 2010). >> >> I think the charter should speak to this, at least very briefly. > > It does very briefly: - The protocol must be usable by unmodified > applications. > > All the things you mentioned seems like it would require agreement > between systems and management by a sysadmin, but this is targeted > to end users system (like smart phones) too... If TCP is the only > protocol allowed through a firewall, how are any of your other > solutions going to work? Automation only requires a little imagination, so I guess while I know the claims about configuration and management are based on some reality, I don't find them very compelling. TCP being the only way through a particular firewall does indeed sound like a good scenario to motivate this work over other options though. Thanks for that example. Personally, I think applicability for MPTCP and TFO is another good motivation, and might even find those as more compelling than the the data encryption functionality. Marcelo's draft already nicely mentions those, and I'm fine with what he has written there. Using some odd layering of DTLS or IPsec+UDP would seem less easy to apply to the MPTCP and TFO problems than a tcpcrypt-like approach. -- Wes Eddy MTI Systems From nobody Thu Apr 24 12:26:41 2014 Return-Path: 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 437301A03F4 for ; Thu, 24 Apr 2014 12:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 M57ezv8RtCvG for ; Thu, 24 Apr 2014 12:26:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D638E1A03D6 for ; Thu, 24 Apr 2014 12:26:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OJQEiw010464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 12:26:14 -0700 (PDT) Message-ID: <53596556.1070009@isi.edu> Date: Thu, 24 Apr 2014 12:26:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/2Mm5bUW8SjeQItqZug8Cw8m2Sgg Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:26:40 -0000 On 4/23/2014 11:29 PM, Tony Arcieri wrote: > On Wed, Apr 23, 2014 at 11:09 PM, Joe Touch > wrote: > > Was there something relevant to Tcpcrypt *today* you wished for me to > > glean from these papers? Did you cite some other papers besides > these? > > > Both papers indicate the performance cost of doing security. Crypto > benchmarks are easy to find in any search engine. Here's one from 2014: > http://www.tomshardware.com/__reviews/mini-pc-round-up,3697-__13.html > > > You're citing out-of-date papers and Tom's Hardware articles? > > For the rest of us, there's EBACS: > > http://bench.cr.yp.to/ I cited a few places that measured the network performance. The bench.cr.yp.to version doesn't appear to do that. Network performance is important because of the kinds of effects shown in my (granted, now 'ancient') MD5 Sigcomm paper - in-situ performance does not take into account the additional "data touching" overheads required to move the data through the crypto processor, vs. doing DMA to the NIC. Joe From nobody Thu Apr 24 13:08:24 2014 Return-Path: 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 E9D2E1A038E for ; Thu, 24 Apr 2014 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 bljJK6OM_qCY for ; Thu, 24 Apr 2014 13:08:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A65DE1A0389 for ; Thu, 24 Apr 2014 13:08:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OK7bmj023199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 13:07:38 -0700 (PDT) Message-ID: <53596F09.9010901@isi.edu> Date: Thu, 24 Apr 2014 13:07:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <874n1i7hvo.fsf@ta.scs.stanford.edu> <53595D73.2020609@it.uc3m.es> In-Reply-To: <53595D73.2020609@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/iVwNj_jha1-Fv41yop2-XeitOY8 Cc: David Mazieres expires 2014-04-06 PDT Subject: Re: [Tcpcrypt] Fwd: Disabling encryption, null ciphers, double encryption X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:08:19 -0000 Hi, all, I think a significant point is being lost about disabling encryption during a TCP-INC connection - whether at the beginning (i.e., allowing upgrade) or later (i.e., allowing downgrade). I don't think anyone is proposing UNILATERAL change to the security of a connection. Connection parameters need to be negotiated. If a user doesn't want to accept the terms of a connection - or a proposed change - they can always simply decline. The idea of one-size-fits-all security is part of what has led us to alternate approaches - because that one size is usually the problem. Let's please not repeat past mistakes on that. Joe On 4/24/2014 11:52 AM, marcelo bagnulo braun wrote: > > > > -------- Mensaje original -------- > Asunto: Participating in the tcpcrypt discussion > Fecha: Thu, 24 Apr 2014 10:32:43 -0700 > De: David Mazieres expires 2014-07-23 PDT > > Para: marcelo bagnulo braun > > > Forwarding this email on behalf of David Mazieres as it seems his email > address bounces in the tcpcrypt ml... > > > From: David Mazieres > To: tcpcrypt@ietf.org > Subject: Disabling encryption, null ciphers, double encryption > Reply-To: David Mazieres expires 2014-07-22 PDT > > Date: Wed, 23 Apr 2014 17:50:57 -0700 > Message-ID: <878uqv4kjy.fsf@ta.scs.stanford.edu> > MIME-Version: 1.0 > Content-Type: text/plain > > Nobody forces you to use TCP for a particular application. But if you > choose TCP, you get congestion control. There's no configuration option > by which you can disable the congestion window or plug in the "null > congestion window decrease algorithm." Such concepts make no sense > because everybody uses TCP with the expectation that it will react to > network congestion. > > That is the sense in which TCP Inc. must provide forward secrecy. Once > TCP Inc. is active on a connection, there must be no null or weak > ciphers, there must be no way to disable encryption, and implementations > should not provide access to session keys in such a way that they can be > logged or otherwise disclosed. Not everyone will want to use TCP Inc., > but when it's active, users must have confidence that their > communications are protected from passive eavesdroppers regardless of > configuration. > > Of course, incremental deployment will be critical. Systems will ship > with TCP Inc. long before enabling it by default. We can't expect > people to turn it on all at once, either, meaning implementations must > allow selection of TCP Inc. vs. plain TCP on a per-connection basis. > Some will likely use this per-connection control to disable TCP > Inc. underneath SSL and avoid "double encryption" (which could more > precisely be termed "encryption at two separate layers"). We can argue > about whether or not that's advisable, but it depends on the situation > and is not something we can prevent anyway. > > Conversely, applications may wish to tweak behavior such as endpoint > authentication in the presence of TCP Inc. Doing so requires an > out-of-band signaling mechanism for compatibility. Such a signaling > mechanism will allow applications to disable application-layer > encryption in the presence of TCP Inc., particularly where TCP Inc. is > deemed more secure than legacy or home-grown application-layer crypto > (which often lacks forward secrecy). Whether disabling > application-layer encryption over TCP Inc. is advisable depends on the > specifics, but cannot be prevented in any case. > > So to summarize: TCP Inc. is just an option. However, once enabled, it > must provide security guarantees consistent across all permissible > configurations. Certain mandatory features of TCP Inc. will, among > other uses, permit the avoidance of double encryption. Fortunately, the > success of the TCP Inc. working group does not require consensus on the > advisability of avoiding double encryption. > > David > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Thu Apr 24 13:40:48 2014 Return-Path: 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 BAC9F1A0389 for ; Thu, 24 Apr 2014 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no 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 xD9b9Cgd0N9r for ; Thu, 24 Apr 2014 13:40:46 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB11A0165 for ; Thu, 24 Apr 2014 13:40:45 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so1384188igq.16 for ; Thu, 24 Apr 2014 13:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hj8wINhFQEjOc9Qd7wLZH6uPjjkBzO2ctexQFsKzTeE=; b=mpvrfzYHi4fN8kmH5/CKCRHxqQOnw3vwp5lsz/r+Fe5l/woldZYy26M8iuikt+Jwm9 4PMDzaQowSaIRxE4zWEEmgkInsVaoEutz9WB5Ey/lOq6IFjEnqV9dh3ec/OOv9lYYy6p CH98vc6f1+72JELTqMSL3O23xHvF3hvIVrcYze2QdeHs+DBhD3hTlDyTbAVp6GURU46C Zi33CB53pwI6YdioKwRLU0QqgwcudPKVfD4TiLB/lzhhW+qSVT3BGh+R98NpBKHF3ftk AphnD6xY1ONkH/0B5BESkXp5Se03prDuMviK2vcIEPiSaHE69+yQ7QExkAqDK0POlJGw i4zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hj8wINhFQEjOc9Qd7wLZH6uPjjkBzO2ctexQFsKzTeE=; b=YTzgGyKtSLpvcwBDnY2Y88/UUdx4VigVMi2dML3rC2l7JKgPIe3dwbMrXAme7bS1iF s5HMO4L1/YMkX/vFZ98sRtyIIDkytDZ+R8gKeB4CH8N5Y2q2zu7D/46IV/wmxuXtOh2O H0oEC9MaKfZL+2xKW71X8vI8KVHPBx24PC9DcSx9m/tpPW0mHc6A9o1VqFSAczeTed89 1rCeXND9JDOlA6OhgtuKU8lvXbrNNKAziAWThAQAgncE0TXG+qSlYspeEskYHXnmpCu8 OoR/a3sxEQY8AVnI/QY7TvajaejSxTJkiV2B27ulCGLqQ9lpHLrIMwDUoW1LrmO2YBVR dzAQ== X-Gm-Message-State: ALoCoQkYU58jcVFKNKPb6gXYvGddbC3XdKzMTrsmLXOM6WqM1mcBQGfbQis8rmOly3xbdvPukvHF0Jk13MoBN3oeHOc47CxngVdk5qq2pBDV5Z0CuMwzC005rucl95vVfwDEazcjOyLQ8FtP4BOedFIdNRL/7Z+NyEnEwym5Sf9xi0+xykxcYVGKv25pY5G1BBd1Y2ji2Fcj MIME-Version: 1.0 X-Received: by 10.43.159.197 with SMTP id lz5mr3790855icc.55.1398372039471; Thu, 24 Apr 2014 13:40:39 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Thu, 24 Apr 2014 13:40:39 -0700 (PDT) In-Reply-To: <53596F09.9010901@isi.edu> References: <874n1i7hvo.fsf@ta.scs.stanford.edu> <53595D73.2020609@it.uc3m.es> <53596F09.9010901@isi.edu> Date: Thu, 24 Apr 2014 13:40:39 -0700 Message-ID: From: Chris Palmer To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/jswvTiVCFiXIaqUxV3j8tKUZQjM Cc: marcelo bagnulo braun , David Mazieres expires 2014-04-06 PDT , tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Fwd: Disabling encryption, null ciphers, double encryption X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:40:47 -0000 On Thu, Apr 24, 2014 at 1:07 PM, Joe Touch wrote: > The idea of one-size-fits-all security is part of what has led us to > alternate approaches - because that one size is usually the problem. Let's > please not repeat past mistakes on that. People who want non-secure TCP already have it. It's called "TCP". The past mistakes we must avoid are endless configuration possibilities, modes, weird corner-cases, features that are really misfeatures, et c. From nobody Thu Apr 24 14:14:38 2014 Return-Path: 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 82E7C1A03EC for ; Thu, 24 Apr 2014 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XKlhQwVVppIg for ; Thu, 24 Apr 2014 14:14:33 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 786671A03E7 for ; Thu, 24 Apr 2014 14:14:33 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so3579859veb.23 for ; Thu, 24 Apr 2014 14:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t8b/ZZ7Dd9N8D9z61oRvXxKq3tBnyf72btF3Y7vEA4o=; b=NLJ4APv/u0N66Dxt4vceGUhPA3YLu1geuwNDjCZWKMWVeSZmuqX5PxDfWfUd1rkdxP 6JRAU2WD4N0KcE6/m1/d0+HUY90JW28tWP3o4Wlh23kn2xEhQ6OAyebXmsMShuDT1IpO fl9VOZ2HgIDTmGbKULeBSKV/LmTxB/90Kv00Tzgu6GJ4jtgMFSaMyG1qEWlZrZZnD7eh +SnEgW493KScGnmPkpqum4deH1KO0kSp5ShpJQ8fleUZtIVecZOak6fiu2DJeFmzlPne 3tHs0IvOS7HOVMVDVyNVZvaxADhKTUIPYt+2NTw17Aw0e5ewl3sRXqQ3quoIbbSQuM9D R+pQ== X-Received: by 10.58.185.244 with SMTP id ff20mr363139vec.40.1398374067187; Thu, 24 Apr 2014 14:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Thu, 24 Apr 2014 14:14:07 -0700 (PDT) In-Reply-To: <53596556.1070009@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> From: Tony Arcieri Date: Thu, 24 Apr 2014 14:14:07 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b66f63789b53c04f7d05511 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/98BvYj5KyOmUTMgE7Emf1P-z9UM Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:14:35 -0000 --047d7b66f63789b53c04f7d05511 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 12:26 PM, Joe Touch wrote: > I cited a few places that measured the network performance. The > bench.cr.yp.to version doesn't appear to do that. > > Network performance is important because of the kinds of effects shown in > my (granted, now 'ancient') MD5 Sigcomm paper - in-situ performance does > not take into account the additional "data touching" overheads required to > move the data through the crypto processor, vs. doing DMA to the NIC. You cited a paper: 1) From last millennium. It predates the Pentium II 2) It's about an obsolete hash function, not encryption 3) Your complaint is *my source* isn't taking into the overhead of going through the CPU instead of using direct DMA? Where's your source that talks about this on computers that aren't two decades old? You are making the claim. The onus is on you to deliver the proof. Where's the proof? Can you please link something that's actually germane to the discussion? Can it talk about this millennium's computers? Can it talk about encryption instead of hash functions? Can it actually address the issue of the very overhead you claim my source doesn't matter? I'm just pointing you at these sources as a courtesy. You're the one who claims it's slow. You have the burden of proof. So, can you provide *relevant* papers? -- Tony Arcieri --047d7b66f63789b53c04f7d05511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 12:26 PM, Joe Touch <touch@isi.edu> wrote:
I cited a few places that measured the network performance.= The bench.cr.yp.to= version doesn't appear to do that.

Network performance is important because of the kinds of effects shown in m= y (granted, now 'ancient') MD5 Sigcomm paper - in-situ performance = does not take into account the additional "data touching" overhea= ds required to move the data through the crypto processor, vs. doing DMA to= the NIC.

You cited a paper:

1) From las= t millennium. It predates the Pentium II
2) It's about an obs= olete hash function, not encryption
3) Your complaint is *my sour= ce* isn't taking into the overhead of going through the CPU instead of = using direct DMA?

Where's your source that talks about this on comput= ers that aren't two decades old?

You are= making the claim. The onus is on you to deliver the proof.

Where's the proof? Can you please link something that's = actually germane to the discussion? Can it talk about this millennium's= computers? Can it talk about encryption instead of hash functions? Can it = actually address the issue of the very overhead you claim my source doesn&#= 39;t matter?

I'm just pointing you at these sources as a courtes= y. You're the one who claims it's slow. You have the burden of proo= f.

So, can you provide *relevant* papers?

--
Tony Arcieri
--047d7b66f63789b53c04f7d05511-- From nobody Thu Apr 24 15:26:59 2014 Return-Path: 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 38C4B1A0410 for ; Thu, 24 Apr 2014 15:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 8yKXB2UDPU0t for ; Thu, 24 Apr 2014 15:26:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 96A641A0406 for ; Thu, 24 Apr 2014 15:26:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3OMQaYN006525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 15:26:36 -0700 (PDT) Message-ID: <53598F9C.9020501@isi.edu> Date: Thu, 24 Apr 2014 15:26:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Xp7TrEe0L5aPJCi10YvEsLYXAMg Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:26:57 -0000 On 4/24/2014 2:14 PM, Tony Arcieri wrote: > On Thu, Apr 24, 2014 at 12:26 PM, Joe Touch > wrote: > > I cited a few places that measured the network performance. The > bench.cr.yp.to version doesn't appear to do > that. > > Network performance is important because of the kinds of effects > shown in my (granted, now 'ancient') MD5 Sigcomm paper - in-situ > performance does not take into account the additional "data > touching" overheads required to move the data through the crypto > processor, vs. doing DMA to the NIC. > > > You cited a paper: > > 1) From last millennium. It predates the Pentium II And it's still true. Old doesn't mean out of date. > 2) It's about an obsolete hash function, not encryption That function is still widely used. It's one of the fastest ones you can run, so if that one is slow, then everything will be slower. > 3) Your complaint is *my source* isn't taking into the overhead of going > through the CPU instead of using direct DMA? Most sources don't. That paper didn't; the later NPSec paper did, though. > Where's your source that talks about this on computers that aren't two > decades old? > > You are making the claim. The onus is on you to deliver the proof. The onus on you is to ask a relevant question. So far, all you keep saying is "show me proof", and when someone does (like me), you say "that's not proof because it's old". > Where's the proof? Can you please link something that's actually germane > to the discussion? Can it talk about this millennium's computers? Can it > talk about encryption instead of hash functions? Can it actually address > the issue of the very overhead you claim my source doesn't matter? Encryption itself is easier than hash functions, but useless without a hash function. Encryption can be a lot faster because it requires less mixing of the data, but integrity protection requires a hash anyway. So yes, measuring the speed of either encryption or authentication will tell you a lot. The NPSec paper did just that, and compared the results - both stand-alone and in a network environment. > I'm just pointing you at these sources as a courtesy. You're the one who > claims it's slow. You have the burden of proof. > > So, can you provide *relevant* papers? You are confusing me - and this list - for a search engine. If you know what you want, then look it up. Your wild claim is that performance doesn't matter - and those of us who have been doing research on security performance for a long time already know better. The burden of proof is on you to explain why we should run a class on this mailing list, rather than have you come up to speed on a community that's been around "since the last millenium", as you put it. Joe From nobody Thu Apr 24 15:49:20 2014 Return-Path: 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 06FA51A0403 for ; Thu, 24 Apr 2014 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Uy6ocRtgTqDn for ; Thu, 24 Apr 2014 15:49:16 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 46ACC1A040D for ; Thu, 24 Apr 2014 15:49:16 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so3795321vcb.4 for ; Thu, 24 Apr 2014 15:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OSBsVmjD2e9bd318uQM+CxyRmqAKt+9R45RyE8jK3dM=; b=l/grEkmOhmLwytLWGlTU5gE7JHzc7WHb2e0ie8bJAfh2c6BrOc6E4WglSBfu2mgEZy 3IfHPKMrunruSqE/hTUvND75eHF8I3AQaoF7SKGtZ43yne3ZXGbVabwqD2e+cDHwsmZ+ RacVjoY01GG+rLWvja/Xs6XpgCmFuvp2fFpGCzqDLWVSvDYQ118iQ3/XcIVilF8UntzT 4CVnUed//2kCG0ClkU9tJKP22SoBwywl126wQxycoxueWUh0oCDxEwVMfbOUETV7InSr QZRnkMcQCVPznK5bV/tJC5zxbfd6H+k9wA5M7a6ChwYpZyLzAMIiUOWWujRZEqEVRg6H lYbQ== X-Received: by 10.58.55.170 with SMTP id t10mr3212275vep.29.1398379749983; Thu, 24 Apr 2014 15:49:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Thu, 24 Apr 2014 15:48:49 -0700 (PDT) In-Reply-To: <53598F9C.9020501@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> From: Tony Arcieri Date: Thu, 24 Apr 2014 15:48:49 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b2e5336424d0604f7d1a8d5 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/CqucNv3BPquHqye8pWtnYWRXBNA Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:49:18 -0000 --047d7b2e5336424d0604f7d1a8d5 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch wrote: > You are confusing me - and this list - for a search engine. If you know > what you want, then look it up. Your wild claim is that performance doesn't > matter - and those of us who have been doing research on security > performance for a long time already know better. > So you're saying we should compromise the security of the protocol because you've been "doing research in security performance for a long time" and therefore you're right? This isn't an answer. It's called being a blowhard. I have already given you way more hard data than you've supplied me. I think it's clear I know the costs better than you do (since you seem to like blowhards: I come from a professional background, not an academic one). And I don't think they justify your proposal. Perhaps if you provided some evidence for your position, I'd believe you, but you simply sidestep my questions. This is the point where I look at your CV and all the work you've done for DARPA and the NSA and have to worry why one of your first proposals is adding an encryption off-switch to the charter. If I didn't know better, I'd say you're here to poison this effort. -- Tony Arcieri --047d7b2e5336424d0604f7d1a8d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 3:26 PM, Joe Touch <touch@isi.edu> wrote:
You are confusing me - and this list - for a search engine.= If you know what you want, then look it up. Your wild claim is that perfor= mance doesn't matter - and those of us who have been doing research on = security performance for a long time already know better.

So you're saying we should compro= mise the security of the protocol because you've been "doing resea= rch in security performance for a long time" and therefore you're = right?

This isn't an answer. It's called being a= blowhard.

I have already given you way more hard = data than you've supplied me. I think it's clear I know the costs b= etter than you do (since you seem to like blowhards: I come from a professi= onal background, not an academic one). And I don't think they justify y= our proposal.

Perhaps if you provided some evidence for your position= , I'd believe you, but you simply sidestep my questions. This is the po= int where I look at your CV and all the work you've done for DARPA and = the NSA and have to worry why one of your first proposals is adding an encr= yption off-switch to the charter.

If I didn't know better, I'd say you're her= e to poison this effort.

--
Tony Arcieri
--047d7b2e5336424d0604f7d1a8d5-- From nobody Thu Apr 24 15:59:27 2014 Return-Path: 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 23BA11A041A for ; Thu, 24 Apr 2014 15:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 t13F5n2phjzf for ; Thu, 24 Apr 2014 15:59:24 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D31A0413 for ; Thu, 24 Apr 2014 15:59:24 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so3767475veb.35 for ; Thu, 24 Apr 2014 15:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zCFyF724T+cjq/H7UU4julZzeoBx6mF3pgYHZIUDFs0=; b=eub4BGPlZyxphcDraALhqYBHegGacOyMKa4DuwhJeqe/vtIcEy4nPmgqkU/cixFYe7 svwW5tZoInkTKtKEHOqJ44qty1uoxBIGyH9h/LAJoTqQ7n4lyVa/b2tVnifC+v2p25VO GYkkMFRXo0Lhlekdyr6/Bx3NfyOfZ16bHlotjpEZ51hjoaj6iCmjfz2VbjxsWu54jhpd YAJ1lYqaM62WLDfJ009gFnukVkhGSBqqrU1BNixIknErgd7TDslVW2GCLK6lH8g+mhjl 9NVmu6LNcOvNCRPmB2zLm9CzwRMJYqkyaEU6y5xUZU4d7cJ+l2+ZF6NmC9wDrMw1JwAu jBQg== X-Received: by 10.221.20.199 with SMTP id qp7mr3362912vcb.24.1398380358204; Thu, 24 Apr 2014 15:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Thu, 24 Apr 2014 15:58:58 -0700 (PDT) In-Reply-To: <53598F9C.9020501@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> From: Tony Arcieri Date: Thu, 24 Apr 2014 15:58:58 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a11339e2e8302b504f7d1ccf6 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Bj4nrinh1dN39p54qOh3t34mwes Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:59:26 -0000 --001a11339e2e8302b504f7d1ccf6 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch wrote: > And it's still true. Old doesn't mean out of date. > Newsflash: MD5 IS KNOWN TO BE BROKEN. This alone makes this citation out of date. Furthermore, from your paper's abstract: "The analysis indicates that MD5 software currently runs at 85 Mbps on a 190 Mhz RISC architecture, a rate that cannot be improved more than 20-40%. " Further newsflash: computers are a lot faster than 190MHz now. > 2) It's about an obsolete hash function, not encryption >> > > That function is still widely used. It's one of the fastest ones you can > run, so if that one is slow, then everything will be slower. MD5 is known to be broken and shouldn't be used in new software, and more modern hash functions like Blake2b are faster. The onus on you is to ask a relevant question. So far, all you keep saying > is "show me proof", and when someone does (like me), you say "that's not > proof because it's old". > You're citing a paper for a broken hash function which isn't used in modern authenticated encryption algorithms like AES-GCM. Modern CPUs support instructions like AES-NI and PCLMULTQDQ. > Encryption itself is easier than hash functions, but useless without a > hash function. > I assume you're referring to authenticated encryption, in which case you seem to be confusing a hash function with a MAC, unless you're talking about key exchange which should be a one-time cost at session setup. > So yes, measuring the speed of either encryption or authentication will > tell you a lot. The NPSec paper did just that, and compared the results - > both stand-alone and in a network environment. > And would you seriously propose using MD5 for authentication in Tcpcrypt? -- Tony Arcieri --001a11339e2e8302b504f7d1ccf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 3:26 PM, Joe Touch <touch@isi.edu> wrote:
And it's still true. Old doesn't mean out of date.<= br>

Newsflash: MD5 IS KNOWN TO BE BRO= KEN. This alone makes this citation out of date.=C2=A0

=
Furthermore, from your paper's abstract:

"The analysis indicates that MD5 softwar= e currently runs at 85 Mbps on a 190 Mhz RISC architecture, a rate that can= not be improved more than 20-40%.= =C2=A0"

Further newsflash: computers are a lot faster than 190M= Hz now.
=C2=A0
2) It's about an= obsolete hash function, not encryption

That function is still widely used. It's one of the fastest ones you ca= n run, so if that one is slow, then everything will be slower.
=

MD5 is known to be broken and shouldn't be used in = new software, and more modern hash functions like Blake2b are faster.

The onus on you is to ask a= relevant question. So far, all you keep saying is "show me proof"= ;, and when someone does (like me), you say "that's not proof beca= use it's old".

You're citing a paper for a brok= en hash function which isn't used in modern authenticated encryption al= gorithms like AES-GCM. Modern CPUs support instructions like AES-NI and PCL= MULTQDQ.
=C2=A0
Enc= ryption itself is easier than hash functions, but useless without a hash fu= nction.

I assume you're referring to authentic= ated encryption, in which case you seem to be confusing a hash function wit= h a MAC, unless you're talking about key exchange which should be a one= -time cost at session setup.
=C2=A0
So yes, measuring the spe= ed of either encryption or authentication will tell you a lot. The NPSec pa= per did just that, and compared the results - both stand-alone and in a net= work environment.

And would you seriously propose usin= g MD5 for authentication in Tcpcrypt?

--
Tony= Arcieri
--001a11339e2e8302b504f7d1ccf6-- From nobody Thu Apr 24 16:10:11 2014 Return-Path: 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 7821E1A0420 for ; Thu, 24 Apr 2014 16:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 baBOY4DGbk1Z for ; Thu, 24 Apr 2014 16:10:04 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE51A041D for ; Thu, 24 Apr 2014 16:10:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ON9NEY020000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 16:09:23 -0700 (PDT) Message-ID: <535999A3.1090808@isi.edu> Date: Thu, 24 Apr 2014 16:09:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/7Z9iiEh1UPdiXq06UbAm-HSUFe4 Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:10:07 -0000 On 4/24/2014 3:48 PM, Tony Arcieri wrote: > On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch > wrote: > > You are confusing me - and this list - for a search engine. If you > know what you want, then look it up. Your wild claim is that > performance doesn't matter - and those of us who have been doing > research on security performance for a long time already know better. > > So you're saying we should compromise the security of the protocol > because you've been "doing research in security performance for a long > time" and therefore you're right? You are the one claiming that this compromises the security of the protocol. I've already pointed out repeatedly that NULL mode would only be useful if *both* ends agreed to use it. Other than the vacuous platitude that "anything that makes security more complex makes it weaker", you have shown no PROOF at all. FWIW, if you still haven't figured out how to use a search engine, here's a specific, fairly recent ref that includes info on CPU hardware support for crypto: http://dl.acm.org/citation.cfm?id=1851200 Note that the number of cores needed to support 1 Gbps is NOT ZERO. Until it is, there's something else I could have done with that core, and that's a cost. And this paper didn't bother to measure the data touching overhead costs. One of the reasons we don't keep up-to-date numbers on that cost is that those of us who do performance know what it is (roughly 30%), and nobody wants to pay researchers to find out info they already know. ... >This is the point where I > look at your CV and all the work you've done for DARPA and the NSA and > have to worry why one of your first proposals is adding an encryption > off-switch to the charter. DARPA paid for the Internet, so maybe you should stop using it. The NSA is one of many agencies that support my research, all of which has been published in peer-reviewed venues. If you don't believe any of it, then you're welcome to conduct your own research, write your own paper, and defend *your* position. And no, demanding proof from others does not make you right until proven otherwise. Joe From nobody Thu Apr 24 16:13:53 2014 Return-Path: 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 1028E1A0427 for ; Thu, 24 Apr 2014 16:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 uDA5on5XNWaR for ; Thu, 24 Apr 2014 16:13:47 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBD21A0420 for ; Thu, 24 Apr 2014 16:13:47 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so3761692veb.4 for ; Thu, 24 Apr 2014 16:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a+kE0/rwGFbzGVFRScOlidXQpJuZnl6Pgx5eDpKcmQY=; b=aSAYODsCGJpKODInKGLgnhSZ2ik6tTjzv9x7EbS/AsebdHO46a2dcfxo2D3AkNiqQE 6F3+nHtlfTB6RR1eW4b0SqGktWiZp2hrqhMdwAHP1AhKY/+tWG92/j9E7LfhtNgDS/1t IwlcGq+nhfZQPRlppHAM1mdrM94g8jqAvf91Hcln0UHhhyAn4R7iKhMEEjfjysrEk+XX xzuS9/wKBOaIfs3+UO7SQjGr4If/yIuh+dg5QXaKn1TqVXgBzq269ALsM9x7lUyOalKq 0bX0YH0b1QpNsqZ5IOwD+Ba4PAfVWCxt6cH2aGw7JS6qWcA8nohMn0gyCOg1gODbAgWF aePg== X-Received: by 10.58.13.104 with SMTP id g8mr3446598vec.16.1398381221109; Thu, 24 Apr 2014 16:13:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Thu, 24 Apr 2014 16:13:20 -0700 (PDT) In-Reply-To: <535999A3.1090808@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> From: Tony Arcieri Date: Thu, 24 Apr 2014 16:13:20 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b2e7386f1e53604f7d1fffe Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/3hvde42XJjaeKSN_-NFMh0w-TNY Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:13:49 -0000 --047d7b2e7386f1e53604f7d1fffe Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 4:09 PM, Joe Touch wrote: > The NSA is one of many agencies that support my research > That's funny, because earlier you claimed: On Wed, Apr 23, 2014 at 8:58 PM, Joe Touch wrote: > > On 4/23/2014 8:49 PM, Tony Arcieri wrote: > >> This is also the point in the conversation I seriously have to ask: are >> you working for the NSA to undermine this effort? >> > > You've asked yourself; only you can answer. > > I work for USC, and (as a consultant) myself on occasion, and no one else. -- Tony Arcieri --047d7b2e7386f1e53604f7d1fffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 4:09 PM, Joe Touch <touch@isi.edu> wrote:
The NSA is one of many agencies that support my research

That's funny, because earlier you claimed:

On Wed, Apr 23, 2014 at 8:58 PM, Joe Touch=C2=A0<touch@i= si.edu>=C2=A0wrote:
On 4/23/2014 8:49 PM, Tony Arcieri wrote:
This is also the point in the conversation I seriously have= to ask: are
you working for the NSA to undermine this effort?
=

You've asked yourself; only you can answer.

I work for USC, and (as a consultant) myself on occasion, and no one else.<= /blockquote>
=C2=A0
--
Tony Arcieri
--047d7b2e7386f1e53604f7d1fffe-- From nobody Thu Apr 24 16:27:07 2014 Return-Path: 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 8A0561A0412 for ; Thu, 24 Apr 2014 16:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 z5yohzcQah0H for ; Thu, 24 Apr 2014 16:27:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 507CE1A0294 for ; Thu, 24 Apr 2014 16:27:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ONQfbu024855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 16:26:41 -0700 (PDT) Message-ID: <53599DB1.2060303@isi.edu> Date: Thu, 24 Apr 2014 16:26:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <534ACCE5.2080103@isi.edu> <53575A81.300@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/QRC5DqXnFigLoJUz_T3PFXn8BvI Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:27:04 -0000 On 4/24/2014 3:58 PM, Tony Arcieri wrote: > On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch > wrote: > > And it's still true. Old doesn't mean out of date. > > > Newsflash: MD5 IS KNOWN TO BE BROKEN. This alone makes this citation out > of date. > > Furthermore, from your paper's abstract: > > "The analysis indicates that MD5 software currently runs at 85 Mbps on a > 190 Mhz RISC architecture, a rate that cannot be improved more than > 20-40%. " > > Further newsflash: computers are a lot faster than 190MHz now. Had you read the paper, you would find that the speed expected is based on the number of opcodes/second of the processor. The improvement referred to in the abstract is based on code rearrangement and hardware, not using a faster clock. See Section 3.1.2. The number of opcodes per word is 40-50, which means roughly 1.5 opcodes per bit. Ivy Bridge i7's do 3.5 instructions per cycle, so at best, at 3GHz is 10Gbps - i.e., that's you're entire CPU just to run the fastest hash algorithm at 10Gbps. > 2) It's about an obsolete hash function, not encryption > > That function is still widely used. It's one of the fastest ones you > can run, so if that one is slow, then everything will be slower. > > MD5 is known to be broken and shouldn't be used in new software, and > more modern hash functions like Blake2b are faster. MD5 MAC is known susceptible to birthday attacks. MD5 HMAC is not known susceptible - see RFC 6151. > The onus on you is to ask a relevant question. So far, all you keep > saying is "show me proof", and when someone does (like me), you say > "that's not proof because it's old". > > You're citing a paper for a broken hash function which isn't used in > modern authenticated encryption algorithms like AES-GCM. Modern CPUs > support instructions like AES-NI and PCLMULTQDQ. Those are opcodes have a cost - they make very costly crypto functions that used to cost ~30 opcodes/byte (i.e., >4 per bit) now cost roughly 0.5 opcodes/bit. You continue to provide the proof you ask for - that there is a nonzero cost to doing these functions. > Encryption itself is easier than hash functions, but useless without > a hash function. > > I assume you're referring to authenticated encryption, in which case you > seem to be confusing a hash function with a MAC, unless you're talking > about key exchange which should be a one-time cost at session setup. > > So yes, measuring the speed of either encryption or authentication > will tell you a lot. The NPSec paper did just that, and compared the > results - both stand-alone and in a network environment. > > And would you seriously propose using MD5 for authentication in Tcpcrypt? No, but using it for comparison is still valid, because it's still a lot faster than the current alternatives (e.g., SHA1). Joe From nobody Thu Apr 24 16:30:42 2014 Return-Path: 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 62FDD1A042C for ; Thu, 24 Apr 2014 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 KxF6xmf7Hfyl for ; Thu, 24 Apr 2014 16:30:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D13A91A042B for ; Thu, 24 Apr 2014 16:30:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ONUDw4025929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 16:30:14 -0700 (PDT) Message-ID: <53599E85.7010902@isi.edu> Date: Thu, 24 Apr 2014 16:30:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/uG-ZxfHdymPL450nIHdY1hcEWLY Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:30:41 -0000 On 4/24/2014 4:13 PM, Tony Arcieri wrote: > On Thu, Apr 24, 2014 at 4:09 PM, Joe Touch > wrote: > > The NSA is one of many agencies that support my research > > > That's funny, because earlier you claimed: > > On Wed, Apr 23, 2014 at 8:58 PM, Joe Touch > wrote: > > On 4/23/2014 8:49 PM, Tony Arcieri wrote: > > This is also the point in the conversation I seriously have to > ask: are > you working for the NSA to undermine this effort? > > > You've asked yourself; only you can answer. > > I work for USC, and (as a consultant) myself on occasion, and no one > else. You really can't read. I work for - i.e., am employed by - USC. I have received funding for research performed while a USC employee from many places. Your turn. How about we start discussing who you *say* you work for? Joe From nobody Thu Apr 24 16:46:04 2014 Return-Path: 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 7F59C1A0467 for ; Thu, 24 Apr 2014 16:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 lgX_PIPkyxLY for ; Thu, 24 Apr 2014 16:46:01 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7F1A0463 for ; Thu, 24 Apr 2014 16:46:00 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3699173veb.25 for ; Thu, 24 Apr 2014 16:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SH8f00x6IIWuiK4XeaauR/3NTMDaPhOAXuMtF1azMtI=; b=y/RySN8zt/WlA8pf7iWS0HIesTVLxjWeLnUv13K11KdIW2QO39HnjermqXGOiANUV2 bOVlmWosZIo7rVPeFFeSqxcNg3/KYlS4Y9A2lqEZZKecVrm9snQZL8Ls2qAZddLgy5wa Ni6FNuViNjrhT9f/e2R+yGa7qH3GNLGfAFvH8WPgLuQRt+VWTC2tjXeLJ69TkuTAvN5m FAbcu3toMhTkJSGsBVO6eS15Gf3GeV1UfA+AKVdYnwgmwkaswoFP5JjvTAArdSHoS7wZ 637DOUTfol5OHlnuY9wZybN5QOV5QSW6OWG6w/D/wfbegwXEGfhiBduUuaoJEYnnwicP 7jfw== X-Received: by 10.220.105.130 with SMTP id t2mr3563774vco.18.1398383154645; Thu, 24 Apr 2014 16:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Thu, 24 Apr 2014 16:45:33 -0700 (PDT) In-Reply-To: <53599E85.7010902@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> From: Tony Arcieri Date: Thu, 24 Apr 2014 16:45:33 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b34375231524b04f7d27341 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/4jY-fKdFmAmNtId3p07eWed7P-0 Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:46:02 -0000 --047d7b34375231524b04f7d27341 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 4:30 PM, Joe Touch wrote: > I have received funding for research performed while a USC employee from > many places. > So let me get this straight: you didn't actually work for the NSA, you just did some work that they gave you money for. Is that it? You really can't read. No, I'm just not a fan of USSID 18-style twisting of language to lie about things. And I'm calling you a liar. You lied about your involvement with the NSA. Your turn. How about we start discussing who you *say* you work for? I am the most deep cover NSA sleeper agent the world has ever seen -- Tony Arcieri --047d7b34375231524b04f7d27341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 4:30 PM, Joe Touch <touch@isi.edu> wrote:
I have received funding for research performed while a USC = employee from many places.

So let me = get this straight: you didn't actually work for the NSA, you just did s= ome work that they gave you money for. Is that it?

You really can't read.

No, I'm just not a fan of USSID 18-style twisting o= f language to lie about things. And I'm calling you a liar. You lied ab= out your involvement with the NSA.

Your turn. How about we start discussing who you *say* you work for?

I am the most deep cover NSA sleeper agent the wo= rld has ever seen

--
Tony Arcieri
--047d7b34375231524b04f7d27341-- From nobody Thu Apr 24 16:59:57 2014 Return-Path: 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 80D3E1A043A for ; Thu, 24 Apr 2014 16:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 MaWzF-GH5YWx for ; Thu, 24 Apr 2014 16:59:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC81A0440 for ; Thu, 24 Apr 2014 16:59:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3ONxBSI003913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 16:59:11 -0700 (PDT) Message-ID: <5359A54F.7060201@isi.edu> Date: Thu, 24 Apr 2014 16:59:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/QzzC15US-AMCNvXSGeiusDUKjl0 Cc: alfiej@fastmail.fm, "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:59:56 -0000 On 4/24/2014 4:45 PM, Tony Arcieri wrote: > On Thu, Apr 24, 2014 at 4:30 PM, Joe Touch > wrote: > > I have received funding for research performed while a USC employee > from many places. > > So let me get this straight: you didn't actually work for the NSA, you > just did some work that they gave you money for. Is that it? Yup. Just like how DARPA gave money to people at UCLA and BBN initially, and lots of others over the years, to create the Internet. It's called government funded research. It's what made the Internet possible, so that lots of companies can make billions and not pay for what got them there. > You really can't read. > > No, I'm just not a fan of USSID 18-style twisting of language to lie > about things. Like I said, you can't read. > And I'm calling you a liar. You lied about your > involvement with the NSA. I stated clear and direct facts and you have zero proof otherwise (you know, you're fond of proof, right?). Further, I'll confirm that I'm not funded by the NSA right now, and that the project I was working on involved tunnel configuration, not encryption or authentication protocols. Which is more than you have done. Joe From nobody Thu Apr 24 17:15:57 2014 Return-Path: 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 6D3C71A0445 for ; Thu, 24 Apr 2014 17:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 wB0_DoveZ92k for ; Thu, 24 Apr 2014 17:15:52 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7871A043A for ; Thu, 24 Apr 2014 17:15:52 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 0C8156D581; Thu, 24 Apr 2014 20:15:42 -0400 (EDT) Message-ID: <5359A92E.4060606@iang.org> Date: Fri, 25 Apr 2014 01:15:42 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> In-Reply-To: <535999A3.1090808@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zUlVPAm1vdfQo7LThRMPx5Naxag Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 00:15:54 -0000 On 25/04/2014 00:09 am, Joe Touch wrote: > You are the one claiming that this compromises the security of the > protocol. Count me in ;) > I've already pointed out repeatedly that NULL mode would only > be useful if *both* ends agreed to use it. Doesn't cut the mustard for me. Firstly, that isn't shown in the charter, secondly nobody knows what it will look like when it gets delivered, thirdly we know that the obligatory existence of a defined mode creates an entire axis or dimension of state complexity. Fourthly if you get your NULL in there, everyone else will want their vanity suite in too, and it'll be SSL sweet madness all over again. Fifthly, we've been here before: systems fail when people add too much stuff of marginal utility (which includes the terabyters). Sixthly, people are pissed. They don't want another kitchen sink. This might be the last chance IETF WGs have to make a showing in this field, there are already serious competitors looking to sweep the whole lot away, and they know the IETF isn't the right forum for security protocols. Fixing TCP to go opportunistic isn't going to hold them back for long, but if it presents an alphabet soup of options, it'll just make the job soooo much easier [0]. > Other than the vacuous > platitude that "anything that makes security more complex makes it > weaker", you have shown no PROOF at all. Standing on proof is an old academic trick to push arguments into a black hole. Proof by citation is a joke because every academic paper finishes with "more funds required, please" and every paper committee is made of swap buddies and other peers. Instead of 'proof' we've got data: 20 years of experience in what happens to secure protocols that aim for complexity. 130 if you count Kerckhoffs. iang [0] wait, why am I arguing against, again? From nobody Thu Apr 24 17:59:33 2014 Return-Path: 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 CDB601A0442 for ; Thu, 24 Apr 2014 17:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no 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 keppY_Y_8_2A for ; Thu, 24 Apr 2014 17:59:31 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id E0B9E1A02AA for ; Thu, 24 Apr 2014 17:59:30 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id hl10so1627585igb.0 for ; Thu, 24 Apr 2014 17:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fYSOTF4ngpz2zBws+xIA72y76aJ+LLK47m5b7nTx7mI=; b=MvQda5R+cp2nD54JNIeUSzsWB5+zTYsC6KrYbXwagJT43Hs/F45RBVCNoTJIWhlRhn uHq+qu2Sj4mhF1rF6h/6C/spV8CTuADXAf5q5HtBw60DeNpqVh078CSqxE28k3P79QlZ 3Ol46MYvJbJwQ4VHdwHmFWgydnyzJ7NwPwffYIcbzHPfo/EN7sLaUAjockA/sXSkqFbI es8AQiFga/4mfGbrvCOzs1AtBuMtX2ZBXYudMB1KZQMU6polJyzQvkSSgOH5Fznuvktl /mdKTRW7OH2vrIoGfN6UWL3DW+z18gRCaGgZS7kCggt5afK4qh4lY2dvd8uquNauCDEr 5iHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fYSOTF4ngpz2zBws+xIA72y76aJ+LLK47m5b7nTx7mI=; b=k7tDY4ZeNKm06l21cw0qn0DQFgcjfSBnNELXYVT/5hZECJbU3o0wpyoEDpjl4ghnrL bLVHRkzXb2ew73aP2SFo9tOEU7MKUvGYGKJAAZvQJz/zLzRe5lk0Z/YwRlNQp9FUmsOS h0vIJ/eVwLPW84KDWawmuzdsGvBTLk7EEbRMjAevzafkFokFOwF3PlJujQ9HWrm3bCiU /eHWOuia7fANHh4TWTXV8QIqpq6+RK/51KNTGr0BtaaROm5KoKa4ZvtgOAeQPzk6+Xxf L2MINIlfOehWFjE136uEO9x44M8Ovt4rWDkv4znArEz0si7aMbHSmVb3cf7MUsE1auP2 8TIg== X-Gm-Message-State: ALoCoQnEt7epYIR/2P08F8yhpPW8TixW8alOz13n1XxGxp2HQJgOSwUsXyhPci6BwMa2s3LOgzKqOJLimHKO4Xzd0BnnkfMBYEuOlQ5Dy2qvOlfO/qnu05uOdCWNxLJS53VozjnEG4U/mH2RrBVliMV6ZHU/USmxzIJRnSfNqFBaKARwFPtHrX2XPzxjQF4jW3n9ZXt8pYZK MIME-Version: 1.0 X-Received: by 10.43.140.144 with SMTP id ja16mr4835859icc.46.1398387564478; Thu, 24 Apr 2014 17:59:24 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Thu, 24 Apr 2014 17:59:24 -0700 (PDT) In-Reply-To: <5359A92E.4060606@iang.org> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> Date: Thu, 24 Apr 2014 17:59:24 -0700 Message-ID: From: Chris Palmer To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/um9HieBLOcRDf2JhutrDjBNJTtA Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 00:59:32 -0000 On Thu, Apr 24, 2014 at 5:15 PM, ianG wrote: >> You are the one claiming that this compromises the security of the >> protocol. > > Count me in ;) I'm pretty sure every practicing security engineer worth her cybers knows from experience that (a) complexity is bad; (b) we already have unencrypted TCP; and (c) the performance argument is either a red herring or better answered with "Well, you can always use... TCP." > Sixthly, people are pissed. They don't want another kitchen sink. This > might be the last chance IETF WGs have to make a showing in this field, > there are already serious competitors looking to sweep the whole lot > away, and they know the IETF isn't the right forum for security > protocols. Fixing TCP to go opportunistic isn't going to hold them back > for long, but if it presents an alphabet soup of options, it'll just > make the job soooo much easier [0]. I'm sorry, Joe, but ianG is 200% right. From nobody Thu Apr 24 18:14:49 2014 Return-Path: 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 EF5571A0197 for ; Thu, 24 Apr 2014 18:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 vbmG623R7Se5 for ; Thu, 24 Apr 2014 18:14:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2E27E1A0182 for ; Thu, 24 Apr 2014 18:14:47 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3P1E9C4025692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 18:14:09 -0700 (PDT) Message-ID: <5359B6E1.50107@isi.edu> Date: Thu, 24 Apr 2014 18:14:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> In-Reply-To: <5359A92E.4060606@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/NiR6Lbl0TRMF5CVrYqPJ0eiDALc Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 01:14:49 -0000 On 4/24/2014 5:15 PM, ianG wrote: > On 25/04/2014 00:09 am, Joe Touch wrote: > >> You are the one claiming that this compromises the security of the >> protocol. > > Count me in ;) You'll need to do more than that... (see below). > >> I've already pointed out repeatedly that NULL mode would only >> be useful if *both* ends agreed to use it. > > Doesn't cut the mustard for me. Firstly, that isn't shown in the > charter, It doesn't need to be in the charter per se. Any solution would be evaluated against the charter requirements and its own safety. There's no need to make the decision of how that's achieved in the charter. Further, some of these requirements don't belong in the charter either; the charter should describe the minimum aspects needed, and let the solutions provide and justify their own approach. > secondly nobody knows what it will look like when it gets > delivered, It could look at least partly like this: http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00 < thirdly we know that the obligatory existence of a defined > mode creates an entire axis or dimension of state complexity. Every bit in a protocol does that. That itself does not make the overall solution more vulnerable. > Fourthly if you get your NULL in there, everyone else will want their > vanity suite in too, and it'll be SSL sweet madness all over again. Slippery slope argument; you get to complain after other people try to get their modes in, not just because one mode is considered important to add now. > Fifthly, we've been here before: systems fail when people add too much > stuff of marginal utility (which includes the terabyters). And we've been where systems fail because they lack functionality too. > Sixthly, people are pissed. They don't want another kitchen sink. Again you're back to the slippery slope argument. I don't want kitchen-sink either. I just have a specific need for NULL - or something like NULL - at some phases of the connection. I've discussed some of the details offline with a subset of people, and I'll post it when it's written up better. > This > might be the last chance IETF WGs have to make a showing in this field, That's both always true and never true for all IETF output. > there are already serious competitors looking to sweep the whole lot > away, and they know the IETF isn't the right forum for security > protocols. Fixing TCP to go opportunistic isn't going to hold them back > for long, but if it presents an alphabet soup of options, it'll just > make the job soooo much easier [0]. Again, nobody is asking for alphabet soup, just one option that others feel is contentious. Why not at least wait for a proposal before declaring that the approach isn't valid? >> Other than the vacuous >> platitude that "anything that makes security more complex makes it >> weaker", you have shown no PROOF at all. > > Standing on proof is an old academic trick to push arguments into a > black hole. FWIW, I wasn't really asking for proof; I was playing off the terms of the other list contributor. > Proof by citation is a joke because every academic paper > finishes with "more funds required, please" A good academic paper (and there are lots of bad ones) makes a clear contribution, and ought to also point the way to future investigation. The former is what the citation-as-proof is about; the latter is how research moves forward. As to "more funds required, please", I hear that a lot more from industry (upgrades? software updates? patches?) than from academia. > and every paper committee is made of swap buddies and other peers. There are certainly some, but more likely is a group of researchers who all can't see that their work is useless because they all do research in the same area. Sort of like industry running off the cliff loving ATM a few years back, until they realized otherwise. Love-fests happen in every community. > Instead of 'proof' we've got data: 20 years of experience in what > happens to secure protocols that aim for complexity. 130 if you count > Kerckhoffs. The plural of anecdote is not data. My peers know that; do yours? Joe From nobody Thu Apr 24 18:17:00 2014 Return-Path: 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 4522C1A01B5 for ; Thu, 24 Apr 2014 18:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 XVLo3sg90RSS for ; Thu, 24 Apr 2014 18:16:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 236471A0197 for ; Thu, 24 Apr 2014 18:16:56 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3P1GTJn026267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 18:16:29 -0700 (PDT) Message-ID: <5359B76D.4050909@isi.edu> Date: Thu, 24 Apr 2014 18:16:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Chris Palmer , ianG References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1s_W8dGfRYG8T9Ka_J71607zgno Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 01:16:57 -0000 On 4/24/2014 5:59 PM, Chris Palmer wrote: > On Thu, Apr 24, 2014 at 5:15 PM, ianG wrote: > >>> You are the one claiming that this compromises the security of the >>> protocol. >> >> Count me in ;) > > I'm pretty sure every practicing security engineer worth her cybers > knows from experience that (a) complexity is bad; (b) we already have > unencrypted TCP; and (c) the performance argument is either a red > herring or better answered with "Well, you can always use... TCP." The performance argument is to use TCP. What we don't want is something that makes all TCP encrypted and we can't shut that off. However, anyone who thinks complexity is bad can use what we have now (e.g., IPsec, TLS, etc.) and leave the group now. Because adding *anything* to TCP necessarily makes it more complex than it is now. Joe From nobody Fri Apr 25 03:33:10 2014 Return-Path: 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 A94FF1A0366 for ; Fri, 25 Apr 2014 03:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Q9czbN0Z6A_T for ; Fri, 25 Apr 2014 03:33:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDFE1A0139 for ; Fri, 25 Apr 2014 03:33:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AA84A209A1 for ; Fri, 25 Apr 2014 06:33:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Fri, 25 Apr 2014 06:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:reply-to:in-reply-to:references:subject:date; s= mesmtp; bh=UdGD5z9+gfH39ENVYKoRPWBXuw4=; b=N8YZFpHHpM6hpfesZFbO5 3V/2cmtKPIsUWgIqwKDMJO/VprYS4xwmoMVH5MDHZaQE9e8Mg0qFO7+YFiIHJ0ZY IxL+ZW5pjajubQYbmT0db+inHpULhU/6HP7B8YHSWph93cd1q7Hyzqb0laoNDIEJ cSeJGUpVxNk4Y5VHQVkc40= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:reply-to:in-reply-to :references:subject:date; s=smtpout; bh=UdGD5z9+gfH39ENVYKoRPWBX uw4=; b=OmTRT1K3Mtyjr4CSFpVYY1xligdyri9fr0GkEDwL9pB5AfreVAco3dsi oSTBplRJTM1KIKbyHNbUc2vUcxSI4U6suuQCbGgHKHUe6ISgsojoxSKjxUbRM1kU 2LNl6XEECAN54k1+jtqNCTM27v0R4Isjjnn9tzJmQj1CnmAykTM= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 8E9FF11DD21; Fri, 25 Apr 2014 06:33:00 -0400 (EDT) Message-Id: <1398421980.19889.110278405.0F37EF4F@webmail.messagingengine.com> X-Sasl-Enc: hIs+doSZ6XA4DaKZolh+4y0t6NU23/kteC6SWTcWSg82 1398421980 From: Alfie John To: tcpcrypt@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-aafac2c3 In-Reply-To: <5359B76D.4050909@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <5359B76D.4050909@isi.edu> Date: Fri, 25 Apr 2014 20:33:00 +1000 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/iARKij9evvcqzikCX8OKZO6Efnk Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:33:09 -0000 On Fri, Apr 25, 2014, at 11:16 AM, Joe Touch wrote: > The performance argument is to use TCP. What we don't want is something > that makes all TCP encrypted and we can't shut that off. In today's climate I think encryption by default is what everyone wants. If you need plain-text, you should have to be made to jump through hoops to get it. Because in practice, the only people who need plain-text are developers debugging their code and the government debugging their citizens. > However, anyone who thinks complexity is bad can use what we have now > (e.g., IPsec, TLS, etc.) and leave the group now. Because adding > *anything* to TCP necessarily makes it more complex than it is now. Ah IPSec. Funny you should mention that [0]: "Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied." -- John Gilmore Alfie [0] http://thread.gmane.org/gmane.technology.liberationtech/1185 -- Alfie John alfiej@fastmail.fm From nobody Fri Apr 25 14:24:40 2014 Return-Path: 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 9917F1A03CE for ; Fri, 25 Apr 2014 14:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 QxbTQ37rfYWC for ; Fri, 25 Apr 2014 14:24:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C46B51A031D for ; Fri, 25 Apr 2014 14:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4CD33BE74; Fri, 25 Apr 2014 22:24:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwx663ncqKeL; Fri, 25 Apr 2014 22:24:29 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.68.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B54CBE70; Fri, 25 Apr 2014 22:24:29 +0100 (IST) Message-ID: <535AD28D.30701@cs.tcd.ie> Date: Fri, 25 Apr 2014 22:24:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> <5359A54F.7060201@isi.edu> In-Reply-To: <5359A54F.7060201@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/w2dZpU_LOj_JURGQ0ShsDCCDSxE Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:24:39 -0000 On 04/25/2014 12:59 AM, Joe Touch wrote: > >> You really can't read. >> >> No, I'm just not a fan of USSID 18-style twisting of language to lie >> about things. > > Like I said, you can't read. Wow. Have to say that's not a very mature sequence of exchanges. Which is a pity. Probably better to just not continue that thread I'd say. S. From nobody Fri Apr 25 14:28:34 2014 Return-Path: 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 189181A03D8 for ; Fri, 25 Apr 2014 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cS2sESoNbmaM for ; Fri, 25 Apr 2014 14:28:29 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9301A03CE for ; Fri, 25 Apr 2014 14:28:29 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 53E436D62A; Fri, 25 Apr 2014 17:28:19 -0400 (EDT) Message-ID: <535AD372.5040103@iang.org> Date: Fri, 25 Apr 2014 22:28:18 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <5359B6E1.50107@isi.edu> In-Reply-To: <5359B6E1.50107@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/mlT6X2PeWFTADSRXJitZDDb2gVI Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:28:32 -0000 I see. In the below and in other posts, you've made it clear you've made decisions, and as you say, you're going to fight to the death on any diversion from your path. Take no prisoners, not on your watch, your mission and you've chosen to accept it. I get it. Your proof-of-work responses suggest that reasons and opinions here count for little, so what's the process from here; do opponents fade away and let you have it, coz you'll out respond them? Or is there a way to take a straw vote? It's not a bid deal for me, because I have low expectations as to the IETF WGs creating tcpcrypt for the people as opposed to for themselves. The 'anecdotal evidence' suggests where this is going. I even don't mind that you've responding with proof-of-work rejoinders, it's an efficient coordination method to reach the chosen goal. What I'm curious about, though, is where the silent majority stand -- what do people who aren't saying think? What did the mandate say, and what thought those who were at the deciding plenum to add opp-enc to TCP? iang On 25/04/2014 02:14 am, Joe Touch wrote: > > > On 4/24/2014 5:15 PM, ianG wrote: >> On 25/04/2014 00:09 am, Joe Touch wrote: >> >>> You are the one claiming that this compromises the security of the >>> protocol. >> >> Count me in ;) > > You'll need to do more than that... (see below). > >> >>> I've already pointed out repeatedly that NULL mode would only >>> be useful if *both* ends agreed to use it. >> >> Doesn't cut the mustard for me. Firstly, that isn't shown in the >> charter, > > It doesn't need to be in the charter per se. Any solution would be > evaluated against the charter requirements and its own safety. There's > no need to make the decision of how that's achieved in the charter. > > Further, some of these requirements don't belong in the charter either; > the charter should describe the minimum aspects needed, and let the > solutions provide and justify their own approach. > >> secondly nobody knows what it will look like when it gets >> delivered, > > It could look at least partly like this: > http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00 > > < thirdly we know that the obligatory existence of a defined >> mode creates an entire axis or dimension of state complexity. > > Every bit in a protocol does that. That itself does not make the overall > solution more vulnerable. > >> Fourthly if you get your NULL in there, everyone else will want their >> vanity suite in too, and it'll be SSL sweet madness all over again. > > Slippery slope argument; you get to complain after other people try to > get their modes in, not just because one mode is considered important to > add now. > >> Fifthly, we've been here before: systems fail when people add too much >> stuff of marginal utility (which includes the terabyters). > > And we've been where systems fail because they lack functionality too. > >> Sixthly, people are pissed. They don't want another kitchen sink. > > Again you're back to the slippery slope argument. I don't want > kitchen-sink either. I just have a specific need for NULL - or something > like NULL - at some phases of the connection. I've discussed some of the > details offline with a subset of people, and I'll post it when it's > written up better. > >> This >> might be the last chance IETF WGs have to make a showing in this field, > > That's both always true and never true for all IETF output. > >> there are already serious competitors looking to sweep the whole lot >> away, and they know the IETF isn't the right forum for security >> protocols. Fixing TCP to go opportunistic isn't going to hold them back >> for long, but if it presents an alphabet soup of options, it'll just >> make the job soooo much easier [0]. > > Again, nobody is asking for alphabet soup, just one option that others > feel is contentious. Why not at least wait for a proposal before > declaring that the approach isn't valid? > >>> Other than the vacuous >>> platitude that "anything that makes security more complex makes it >>> weaker", you have shown no PROOF at all. >> >> Standing on proof is an old academic trick to push arguments into a >> black hole. > > FWIW, I wasn't really asking for proof; I was playing off the terms of > the other list contributor. > >> Proof by citation is a joke because every academic paper >> finishes with "more funds required, please" > > A good academic paper (and there are lots of bad ones) makes a clear > contribution, and ought to also point the way to future investigation. > The former is what the citation-as-proof is about; the latter is how > research moves forward. > > As to "more funds required, please", I hear that a lot more from > industry (upgrades? software updates? patches?) than from academia. > >> and every paper committee is made of swap buddies and other peers. > > There are certainly some, but more likely is a group of researchers who > all can't see that their work is useless because they all do research in > the same area. Sort of like industry running off the cliff loving ATM a > few years back, until they realized otherwise. Love-fests happen in > every community. > >> Instead of 'proof' we've got data: 20 years of experience in what >> happens to secure protocols that aim for complexity. 130 if you count >> Kerckhoffs. > > The plural of anecdote is not data. > > My peers know that; do yours? > > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Fri Apr 25 14:32:08 2014 Return-Path: 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 1F3041A0679 for ; Fri, 25 Apr 2014 14:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 4z6RUe7_3IkK for ; Fri, 25 Apr 2014 14:32:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE41A0345 for ; Fri, 25 Apr 2014 14:32:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94F7ABE70; Fri, 25 Apr 2014 22:31:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bDgLVQ7Quq6; Fri, 25 Apr 2014 22:31:56 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.68.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5CFEBBE76; Fri, 25 Apr 2014 22:31:54 +0100 (IST) Message-ID: <535AD44A.2000603@cs.tcd.ie> Date: Fri, 25 Apr 2014 22:31:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Chris Palmer , ianG References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/fx_EoBktAs4rgtT16dQh8GtFvso Cc: tcpcrypt@ietf.org Subject: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:32:06 -0000 On 04/25/2014 01:59 AM, Chris Palmer wrote: > On Thu, Apr 24, 2014 at 5:15 PM, ianG wrote: > >>> You are the one claiming that this compromises the security of the >>> protocol. >> >> Count me in ;) > > I'm pretty sure every practicing security engineer worth her cybers > knows from experience that (a) complexity is bad; (b) we already have > unencrypted TCP; and (c) the performance argument is either a red > herring or better answered with "Well, you can always use... TCP." I agree about the complexity argument and that's why I'd lean against NULL cipher features myself. Not the strongest argument because its fairly abstract but simpler really is much better and is also something where we (the IETF and IETF security folk) need to do better IMO. Apart from that, I don't think there's real history of accidental use of such or real downgrade attacks to such. At least afaik. If there were that'd be a very strong argument against. All that said, I don't think this needs to be decided right now and nor do I think we're in a position where we could make a sensible yes/no decision on this topic now, before we have more detail of TCP Inc. (great name btw:-) figured out. >> Sixthly, people are pissed. They don't want another kitchen sink. This >> might be the last chance IETF WGs have to make a showing in this field, >> there are already serious competitors looking to sweep the whole lot >> away, and they know the IETF isn't the right forum for security >> protocols. Fixing TCP to go opportunistic isn't going to hold them back >> for long, but if it presents an alphabet soup of options, it'll just >> make the job soooo much easier [0]. > > I'm sorry, Joe, but ianG is 200% right. IMO ianG is quite wrong there but it doesn't matter since that's commentary that has no direct impact on what we're trying to do here. There are plenty of other lists for such discussion. S. > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Fri Apr 25 14:44:35 2014 Return-Path: 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 4D0DA1A03D9 for ; Fri, 25 Apr 2014 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Uo_8bMOEPTUh for ; Fri, 25 Apr 2014 14:44:31 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 518FC1A03D8 for ; Fri, 25 Apr 2014 14:44:31 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so5401493veb.38 for ; Fri, 25 Apr 2014 14:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dm/OSwhEjpDKLqJ3rVLfp6ZqgdA9GBw0Qa8bq+QK6oU=; b=x1JSDV0uY+ZMF9iYJyoNaKV/EwLMluJy77Ll+u1tRP34/ZS73QrUfawlrKS2WmVwg/ gWG8jB2J5GlQGKcJq4idhzm9yX+avIOqI2jLeEU5TOyXSqlA3oy1Q8ydO7/pnJPehHyR I7249eiBst2ytF0JRicgQ9h2PgonnVx8cNagaumMWCvAb6AsqI0nKpPVWkj6dwZ9FcMg zKdHwsA2mYhMByRDtii+DL5ykAlAWszXsqwhZMVITTfBNN5OvXt98cAvONLNwfxlJnx1 1r0keIUrqRygQONY+BCotF8/G6gzIbCSExT2aQ5VN0H+IuD8vM7oG4sL83o2nqbv57Kr ObTQ== X-Received: by 10.58.122.164 with SMTP id lt4mr8721246veb.2.1398462264659; Fri, 25 Apr 2014 14:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 14:44:04 -0700 (PDT) In-Reply-To: <535AD44A.2000603@cs.tcd.ie> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> From: Tony Arcieri Date: Fri, 25 Apr 2014 14:44:04 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b2ed25584543504f7e4dec8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/RjzfrEJibPhSYG2m8GhV5-vW-b4 Cc: "tcpcrypt@ietf.org" , Chris Palmer , ianG Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:44:33 -0000 --047d7b2ed25584543504f7e4dec8 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 2:31 PM, Stephen Farrell wrote: > IMO ianG is quite wrong there but it doesn't matter since that's > commentary that has no direct impact on what we're trying to do > here. There are plenty of other lists for such discussion. I'd like to cite this quote again: "Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied." -- John Gilmore There is already a cloud of suspicion hanging over Tcpcrypt that even at its inception it's been tainted by the NSA in order to undermine its security. Adding encryption off-switches as one of the first features of what is supposed to be a "ubiquitous encryption" protocol does not lend credence to its mission! The only way this mistrust can be repaired is through quick and decisive action on the part of its leaders. -- Tony Arcieri --047d7b2ed25584543504f7e4dec8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 25, 2014 at 2:31 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
IMO ianG is quite wrong there but it doesn't matter si= nce that's
commentary that has no direct impact on what we're trying to do
here. There are plenty of other lists for such discussion.

I'd like to cite this quote again:

= =C2=A0 "Ev= ery once in a while, someone not an NSA employee, but who had
=C2=A0 longstan= ding ties to NSA, would make a suggestion that reduced privacy
=C2=A0 or security, but which seemed t= o make sense when viewed by people who
=C2=A0 didn'= ;t know much about crypto. For example, using the same IV
=C2=A0 (initialization vector) throughout= a session, rather than making a new
=C2=A0 one for = each packet. Or, retaining a way to for this encryption
=C2=A0 protocol to specify that no encryption= is to be applied."

=C2=A0 =C2=A0 -- John Gilm= ore

There is already a cloud of suspicion h= anging over Tcpcrypt that even at its inception it's been tainted by th= e NSA in order to undermine its security.

Adding encryption off-switches as one of the firs= t features of what is supposed to be a "ubiquitous encryption" pr= otocol does not lend credence to its mission!

The only way this mistrust can be repaired is th= rough quick and decisive action on the part of its leaders.

--
Tony Arcieri
--047d7b2ed25584543504f7e4dec8-- From nobody Fri Apr 25 14:50:27 2014 Return-Path: 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 680981A055D for ; Fri, 25 Apr 2014 14:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 es-378YvAXZY for ; Fri, 25 Apr 2014 14:50:21 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8E1A050E for ; Fri, 25 Apr 2014 14:50:21 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hu19so5400270vcb.23 for ; Fri, 25 Apr 2014 14:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r5I9Uh53mgp5D+zvj541KWn7P0OWHTeLF2MTWqzNPng=; b=MCGyqxyio3Yu55FlMFvno8+84+l6JJXad9Hk9NZnlkZ2F5NuFLkYeH0mIZaa7t1n3y o6rrGIuSidobauH/CZ/nK4nYUoUurRog9XKMsHqpNZIP65vBZUbCRq4u+bVYw8X5zsKj cLsqBQR4ElpqwFHc87M49k0cf3k/v9/lTLTHCmNgaFvE/qwAbq52bHajHkhEJnNFZYdS FL1rbATwZGAYUgaOQFC2fwELsTBKwnkKe3fxo8ffya+FyumzGQOEP1gt2xnacf5ciDtV krCTpeE16T+JkcBDfHQmZjPYDidP7m3cVzRZjsvFRmH1wUYvEe/LeH3HmkNTUCT6K46Q SIVg== X-Received: by 10.58.123.71 with SMTP id ly7mr8674041veb.11.1398462614754; Fri, 25 Apr 2014 14:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 14:49:54 -0700 (PDT) In-Reply-To: References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> From: Tony Arcieri Date: Fri, 25 Apr 2014 14:49:54 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0115f0a2625a1304f7e4f337 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/AjXkmla93dDq6SPI1uA_HxiYqe4 Cc: "tcpcrypt@ietf.org" , Chris Palmer , ianG Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:50:23 -0000 --089e0115f0a2625a1304f7e4f337 Content-Type: text/plain; charset=UTF-8 Here's an analogy: Let's imagine we're pursuing a "full disk encryption" technology. Some might argue that there are files on your hard drive that are already encrypted. Would double encrypting these files be silly? Well, you can try to make that argument, but some might make the argument that if you added off-switches for files you assumed were already encrypted, your full disk encryption technology ceases to be full disk encryption. I think the idea of a "most-of-your-disk-but-we-want-some-files-plaintext-encryption" technology is rather silly. What's the point then? Tcpcrypt is already going down the arguably silly path of pursuing unauthenticated opportunistic encryption which is known to be vulnerable to active Man-in-the-Middle attacks. But it's doing this for a good cause: encrypt everything. ...or is it? Well, it seems certain people who have taken grant money from the NSA in the past are opposed to that mission. -- Tony Arcieri --089e0115f0a2625a1304f7e4f337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's an analogy:

Let's imag= ine we're pursuing a "full disk encryption" technology.
=

Some might argue that there are files = on your hard drive that are already encrypted. Would double encrypting thes= e files be silly?

Well, you can try to make that argument, but some might make the argument t= hat if you added off-switches for files you assumed were already encrypted,= your full disk encryption technology ceases to be full disk encryption.

I think the= idea of a "most-of-your-disk-but-we-want-some-files-plaintext-encrypt= ion" technology is rather silly. What's the point then?

Tcpcrypt is already going down the arg= uably silly path of pursuing unauthenticated opportunistic encryption which= is known to be vulnerable to active Man-in-the-Middle attacks. But it'= s doing this for a good cause: encrypt everything.

...or is it= ? Well, it seems certain people who have taken grant money from the NSA in = the past are opposed to that mission.

--
Tony Arcieri=
--089e0115f0a2625a1304f7e4f337-- From nobody Fri Apr 25 14:55:49 2014 Return-Path: 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 B6C221A0680 for ; Fri, 25 Apr 2014 14:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2dF7Nb4LR_bu for ; Fri, 25 Apr 2014 14:55:46 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DF1F61A0670 for ; Fri, 25 Apr 2014 14:55:45 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so5270573veb.25 for ; Fri, 25 Apr 2014 14:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UrvfIIIFiDCFT8Ss65qgkdZlhVSkv5W8aBn6bZcUWlM=; b=HCqK9nG2OlJAGpoW+m7kKvAQN0eEqwxyyVCwWQOg0ORSsNT856I9P7DgvdRqTZdb3E n+5wRSfTXmtlKi0MRwPJPb9YNQmCOUvLxout9fn/a4ENN8rqSo7wrPxA194PoORFN42H sBoorVj6f5zuS7BIziDFDmKDu9D9LM37oALNRioEni6QDmR2aB+nneprUYQZko8QmuLD bxajwcL/qFlxp6zkrWcRbmYnfVGw4mbm1BguvlH6A8kKXhE2mmNHIl9CwxJDaHDHjZfW tauOAZN3WVERfUfWrewaO3eVXFYwo0sArm+9oSZJkgUn5+iSSRlxMX1MGWbfGA8hYt4i LnvQ== X-Received: by 10.220.81.194 with SMTP id y2mr3186302vck.29.1398462939301; Fri, 25 Apr 2014 14:55:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 14:55:19 -0700 (PDT) In-Reply-To: <535AD28D.30701@cs.tcd.ie> References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> <5359A54F.7060201@isi.edu> <535AD28D.30701@cs.tcd.ie> From: Tony Arcieri Date: Fri, 25 Apr 2014 14:55:19 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2d860ba8d3904f7e50605 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/VXUf--WxiMbPco50QAssuykFgDI Cc: "tcpcrypt@ietf.org" , Joe Touch Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:55:47 -0000 --001a11c2d860ba8d3904f7e50605 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 2:24 PM, Stephen Farrell wrote: > Wow. Have to say that's not a very mature sequence of exchanges. > Which is a pity. Probably better to just not continue that thread > I'd say. This working group needs to deal with the reality that there is an organization that has actively worked to undermine these sorts of efforts repeatedly in the past, and that this person has taken money from them, and this is exactly how they have poisoned previous cryptographic standards. Unless this working group actively resists their efforts, they are going to fall prey to them. If I think that's happening, I will be sure to tell anyone and everyone that I think Tcpcrypt is tainted by the NSA and is not to be trusted. -- Tony Arcieri --001a11c2d860ba8d3904f7e50605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 25, 2014 at 2:24 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
Wow. Have to say that's = not a very mature sequence of exchanges.
Which is a pity. Probably better to just not continue that thread
I'd say.

This working group needs to de= al with the reality that there is an organization that has actively worked = to undermine these sorts of efforts repeatedly in the past, and that this p= erson has taken money from them, and this is exactly how they have poisoned= previous cryptographic standards.

Unless this working group actively resists their effort= s, they are going to fall prey to them.

If I think= that's happening, I will be sure to tell anyone and everyone that I th= ink Tcpcrypt is tainted by the NSA and is not to be trusted.

--
Tony Arcieri
--001a11c2d860ba8d3904f7e50605-- From nobody Fri Apr 25 15:05:06 2014 Return-Path: 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 49D061A06D0 for ; Fri, 25 Apr 2014 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 WmRnP80V9PvA for ; Fri, 25 Apr 2014 15:05:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id D228A1A0690 for ; Fri, 25 Apr 2014 15:05:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7AC3321184; Fri, 25 Apr 2014 18:04:55 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Fri, 25 Apr 2014 18:04:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=tyleIdJspmBJ8/AeThXjistyf9w=; b=Qb5k1 Z/8QhWmUaXsjy/QCFV5DoSHQbl/iw/b75LwF8+owV4bSzvfR8/KBFZub86wNukD6 HikO6Bm2Ymh1dChoG9wn3IAiI68Y0C5gMwdK+1JrHmi7U5bPbiwD6RiV4vwGCuev HAzUSGAWDUPYimozqEDhmMG3GHmAZprSaITzYo= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 52FF0114F3F; Fri, 25 Apr 2014 18:04:55 -0400 (EDT) Message-Id: <1398463495.23831.110504821.6A80D6D3@webmail.messagingengine.com> X-Sasl-Enc: ZCEXso8nygsXP42T5OISfJ29kVpJlhfDeTCXAq/L4zwZ 1398463495 From: Mark Handley To: Tony Arcieri , Stephen Farrell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1398463495238310"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aafac2c3 Date: Fri, 25 Apr 2014 15:04:55 -0700 In-Reply-To: References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/dccs_Ai1WuzQqxlG0W8SS1Xk7bY Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:05:05 -0000 This is a multi-part message in MIME format. --_----------=_1398463495238310 Content-Transfer-Encoding: 7bit Content-Type: text/plain There is already a cloud of suspicion hanging over Tcpcrypt that even at its inception it's been tainted by the NSA in order to undermine its security. Sorry, please take a look at the authors of the tcpcrypt draft please, and tell me which of us you think may have been tainted by the NSA? The NSA certainly wasn't at UCL when we dreamed this protocol up several years ago, and I don't remember anyone from any security agency begging me to bring the work to the IETF, either the first time I tried a couple of years ago, or more recently. Mark --_----------=_1398463495238310 Content-Transfer-Encoding: 7bit Content-Type: text/html
 
There is already a cloud of suspicion hanging over Tcpcrypt that even at its inception it's been tainted by the NSA in order to undermine its security.
 
Sorry, please take a look at the authors of the tcpcrypt draft please, and tell me which of us you think may have been tainted by the NSA?  The NSA certainly wasn't at UCL when we dreamed this protocol up several years ago, and I don't remember anyone from any security agency begging me to bring the work to the IETF, either the first time I tried a couple of  years ago, or more recently.
 
Mark
--_----------=_1398463495238310-- From nobody Fri Apr 25 15:06:28 2014 Return-Path: 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 BDF311A06AD for ; Fri, 25 Apr 2014 15:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.272] 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 05VsroBn4oqZ for ; Fri, 25 Apr 2014 15:06:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 44C881A0690 for ; Fri, 25 Apr 2014 15:06:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 385DCBE74; Fri, 25 Apr 2014 23:06:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxuknpW5Xj-d; Fri, 25 Apr 2014 23:06:16 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.68.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EFCD6BE58; Fri, 25 Apr 2014 23:06:15 +0100 (IST) Message-ID: <535ADC57.7000403@cs.tcd.ie> Date: Fri, 25 Apr 2014 23:06:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/cIFdC6ejQeofh5CGo2pwHzDw1a4 Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:06:26 -0000 On 04/25/2014 10:44 PM, Tony Arcieri wrote: > There is already a cloud of suspicion hanging over Tcpcrypt that even at > its inception it's been tainted by the NSA in order to undermine its > security. That's just totally misguided IMO. The whole "taint" thing I mean and has nothing to do with this list really. If you have a technical proposal, write an I-D. If you have a technical issue with a proposal raise the technical argument. If you want to follow conspiracy theories then perhaps that'd be better done elsewhere since the *only* real defence we have against an organisation willing to waste US$250M/yr to bugger up Internet security is to be as open as we can about trying to make Internet security better. (The 250/yr seems real but the "this person/statement/paper/I-D is evidence that you're an NSA stooge" is pure consipracy theory stuff IMO.) And being as open as we need to be *requires* that you take participants at face value and evaluate their technical contributions on their merits or else you rapidly end up with a membership cabal of one sort or another, and/or the sort of frankly silly and destructive thread we've just seen. So again - I'd ask that you drop the conspiracy stuff at least on this list, and we all get back to the technical work which is what we want to get done here. If you want to discuss the generic topic of how to handle the fact that IETF participants are and have been and will always be funded by all sorts of organisations on an IETF list, then I'd suggest maybe the perpass list and not here. Though personally I think that's a bit of a stretch as a valid topic even there really, but it might be a discussion worth having in a mature way to get it properly done once at least. S. From nobody Fri Apr 25 15:15:27 2014 Return-Path: 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 5693D1A0673 for ; Fri, 25 Apr 2014 15:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NUo4qFsUCMOC for ; Fri, 25 Apr 2014 15:15:21 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06B1A03F2 for ; Fri, 25 Apr 2014 15:15:21 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so5290217veb.25 for ; Fri, 25 Apr 2014 15:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cFnqkSr74umUiPesQYyDJCyG5hZVBH4RUOTatevN79E=; b=NDOhZ9nwrKRHid4r2Q6g1/9iP6z8lAlOpyj91Dge8s8MNTTxGESKxAQgolK2otzof4 /4bQUPqVhwUHLaTGo4+efvD/X2vb82e49wM4wRjLHjGo9LckHwKSbZuhcGn1pfbfuZke brOsAdHMCMnrbRjet/+XhtbH4mA978+GKkrJUmuo4D00RUAxiOgvXLEd5LnVgNdJM99z RCs8yaPfzf/kHY5AMTsgv0hQFLxgfFj0zIuafo8jVALUioDl6b+MQ5XFoxivDr4ucgHU yAYR2B8OT0GxOUaMgBvQSQrQn1t7SUg+a6lWxnDyJAuy4/D7wUoIosWrR9y4jucNgxbp JJTg== X-Received: by 10.58.123.71 with SMTP id ly7mr8772949veb.11.1398464114523; Fri, 25 Apr 2014 15:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 15:14:54 -0700 (PDT) In-Reply-To: <1398463495.23831.110504821.6A80D6D3@webmail.messagingengine.com> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398463495.23831.110504821.6A80D6D3@webmail.messagingengine.com> From: Tony Arcieri Date: Fri, 25 Apr 2014 15:14:54 -0700 Message-ID: To: Mark Handley Content-Type: multipart/alternative; boundary=089e0115f0a2c7041f04f7e54c75 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/LIcoH1MssbM2sU7-pat9TraBNP0 Cc: "tcpcrypt@ietf.org" , Stephen Farrell Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:15:23 -0000 --089e0115f0a2c7041f04f7e54c75 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 3:04 PM, Mark Handley wrote: > Sorry, please take a look at the authors of the tcpcrypt draft please, > and tell me which of us you think may have been tainted by the NSA? The > NSA certainly wasn't at UCL when we dreamed this protocol up several years > ago, and I don't remember anyone from any security agency begging me to > bring the work to the IETF, either the first time I tried a couple of > years ago, or more recently. > I have no problems with the majority of people involved. I'm talking about Joe Touch, who is probably the main impetus for this thread. -- Tony Arcieri --089e0115f0a2c7041f04f7e54c75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 25, 2014 at 3:04 PM, Mark Handley <m.handley@cs.ucl.ac.uk= > wrote:
Sorry, please take a look at the = authors of the tcpcrypt draft please, and tell me which of us you think may= have been tainted by the NSA?=C2=A0 The NSA certainly wasn't at UCL wh= en we dreamed this protocol up several years ago, and I don't remember = anyone from any security agency begging me to bring the work to the IETF, e= ither the first time I tried a couple of=C2=A0 years ago, or more recently.=

I have no pr= oblems with the majority of people involved.

I'= ;m talking about Joe Touch, who is probably the main impetus for this threa= d.

--
Tony Arcieri
--089e0115f0a2c7041f04f7e54c75-- From nobody Fri Apr 25 15:16:27 2014 Return-Path: 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 74E8B1A068E for ; Fri, 25 Apr 2014 15:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no 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 y6quZbOPlh45 for ; Fri, 25 Apr 2014 15:16:22 -0700 (PDT) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id B5CFD1A03F2 for ; Fri, 25 Apr 2014 15:16:22 -0700 (PDT) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTP id 3EB3BC021F for ; Fri, 25 Apr 2014 22:16:13 +0000 (UTC) Message-ID: <535ADEA8.4070609@witmond.nl> Date: Sat, 26 Apr 2014 00:16:08 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> In-Reply-To: <535AD44A.2000603@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PBTXPSTALLRGOQBGODVE" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/T5bKVrQPmn5Pf4tAxdBUj4l3uIg Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:16:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PBTXPSTALLRGOQBGODVE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/25/14 23:31, Stephen Farrell wrote: > Apart from that, I don't think there's real history of accidental > use of such or real downgrade attacks to such. At least afaik. If > there were that'd be a very strong argument against. I've heard a story about someone being tasked to find out if they could speed up their web service. After some man-page reading and config tweaking, the administrator made a huge improvement in speed. He found out that the NULL-cipher was the fastest. "It's listed among the ciphers, so it is probably good enough, otherwise, those smart programmers wouldn't have put it in there." It's only a story, don't know if it is true or not but this is exactly what should be prevented. Lesson: Don't give people knobs to tweak if they don't know the effects. Guido. ------enig2PBTXPSTALLRGOQBGODVE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTWt6oAAoJEHPd8GglaNRmlNsP/jvVLaWRB/OfKC6tH+RW7sSk 2IxcxMrJK7jTnVhLnrM0RtYubB8pdN5w98Yng6y39EZVLzMlkiOwN3Ohxqk1/H6t dK4rJ/F3vCDlBu18prjAHpSIy99jeQ6/+vqWm109khCsHhi/HTynrxMm3VTrsgY4 70cD7enBMd7j5VxmH0vhQBenoDh/dgOEf48ViETgXwQbdtVTPhkOmw9AvocPuKOm 1zfGrbjazTcUiJoXWbVQwoXhO1tkZW4MoK6fRT3Gj/weT/UrGFwXae76SefJ0wrk +FZE6KYbCkfJeWxEhV2+tQb2fnFEXLKFMtewdC0v+evE+Hvs9ra+3+r8YrIFtlKC SjtBCmlEY9DqbGBZYS3tlyvMMBzS64eWL7/8eWEHUW0uMa4qldyOVITHMB1uW3hC 7aWj2SKajwfFait6IRxSzcp4g41GLKjmr+cg42++V7ePue5hLbBKZgRoXxbKRMZT 1fUXLbb3m4qlST3bsFzpxkiHM/oRI95+v5JMrdo0QUo6FKtde0PTyrQAYU+NX88h F4PYIR7UrpPSK9vvmjnTSBuFXJnlk0nAw96rlMlSTkNleMao5sTZwOvAUs5im97i IimPs3XIqy57SxpTpEC5ps4cvi5NgciuTiuU9n/L0E8tdZSXuzNbyWE6mX0lYXk4 DyXQKU4LKfs+NDt5BOaq =D5C/ -----END PGP SIGNATURE----- ------enig2PBTXPSTALLRGOQBGODVE-- From nobody Fri Apr 25 15:17:05 2014 Return-Path: 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 442E81A06D0 for ; Fri, 25 Apr 2014 15:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 QrafKYMTZXBP for ; Fri, 25 Apr 2014 15:16:57 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0921A03F2 for ; Fri, 25 Apr 2014 15:16:57 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so5525846vcb.35 for ; Fri, 25 Apr 2014 15:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2shJK6DZpQgaDdk2y4KAxcfQktC89b5Ja85KIRoqdL4=; b=Ny7XDpToEGSkkynxNEFdUIsp+w0rxV4ilBG+YQGBozWkh5P6fV6clHoQ+rWt8+YkDt mkj2xpcHLvGygcsDyQX9KelLnMfCwxzJNobO7XSVMbc6Rg9L3hMJ03meQM9+Cl/Cam0d DhX2GjdGlEuM38CzxCOk+XvqfKoPLI0yeslH5nlgWys57/ht56gJAgwksdBdR844JYKX VVYyLOSCXNDwaVj6HyERJL7Zpd+wc52KF5U6l2wrF1BM4somyALgS1RffR+s8boWUaGC UPec5IKJN6S1vvGf56C3cXFPXZxT78RqasQdf47TchwfHGJ2hBxeXJtOCjXAVLiIVuqA lOkA== X-Received: by 10.52.191.100 with SMTP id gx4mr7397277vdc.4.1398464210869; Fri, 25 Apr 2014 15:16:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 15:16:30 -0700 (PDT) In-Reply-To: <535ADC57.7000403@cs.tcd.ie> References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <535ADC57.7000403@cs.tcd.ie> From: Tony Arcieri Date: Fri, 25 Apr 2014 15:16:30 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e013a1fcc8523f404f7e552e6 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/d7FW00B_jl2BBSdZzmPhojvx1ok Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:16:59 -0000 --089e013a1fcc8523f404f7e552e6 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 3:06 PM, Stephen Farrell wrote: > So again - I'd ask that you drop the conspiracy stuff at > least on this list If you're not willing to address these problems internally, I am quite happy to leave this list and take them public. -- Tony Arcieri --089e013a1fcc8523f404f7e552e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 25, 2014 at 3:06 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
So again - I'd ask that you drop the con= spiracy stuff at
least on this list

If you're not willin= g to address these problems internally, I am quite happy to leave this list= and take them public.=C2=A0

--
Tony Arcieri<= br>
--089e013a1fcc8523f404f7e552e6-- From nobody Fri Apr 25 15:18:34 2014 Return-Path: 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 5E0691A068E for ; Fri, 25 Apr 2014 15:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 f5NJuhjEEjHF for ; Fri, 25 Apr 2014 15:18:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0A1A03F2 for ; Fri, 25 Apr 2014 15:18:30 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3PMH6rk027956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Apr 2014 15:17:06 -0700 (PDT) Message-ID: <535ADEE2.300@isi.edu> Date: Fri, 25 Apr 2014 15:17:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri , Stephen Farrell References: <533C33D2.4060004@it.uc3m.es> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> <5359A54F.7060201@isi.edu> <535AD28D.30701@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/z4YL2yr1hoFRZ5d6XvHPDr_OJz0 Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:18:32 -0000 So there are only two groups of people: - those who disclose NSA funding or employment (e.g., mine is on my CV as past funding support) - those who don't If you don't trust the former, why do you trust the latter? How can you *ever* distinguish the second set from the first that you haven't exposed yet? So basically nobody is to be trusted. I certainly don't trust you, but that's because I think you're lacking in technical judgement, not because of whom you (claim to) associate with. But isn't that how we should all always approach every security problem, including designing protocols anyway? Joe From nobody Fri Apr 25 15:18:49 2014 Return-Path: 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 4881D1A06D6 for ; Fri, 25 Apr 2014 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 jkn372kiFy7a for ; Fri, 25 Apr 2014 15:18:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85F761A06D2 for ; Fri, 25 Apr 2014 15:18:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A40DDBE74; Fri, 25 Apr 2014 23:18:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvEiFQaZrigP; Fri, 25 Apr 2014 23:18:33 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.68.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 93782BE59; Fri, 25 Apr 2014 23:18:33 +0100 (IST) Message-ID: <535ADF39.5030509@cs.tcd.ie> Date: Fri, 25 Apr 2014 23:18:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Guido Witmond , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <535ADEA8.4070609@witmond.nl> In-Reply-To: <535ADEA8.4070609@witmond.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Zh1tEHVm27opcvOOT1OqyAHc_PE Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:18:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/25/2014 11:16 PM, Guido Witmond wrote: > It's only a story, don't know if it is true or not but this is > exactly what should be prevented. I've heard similar myself, but always 3rd hand. If there were real evidence of that I'd expect the ssl observatory or others to have turned it up for TLS at least. If someone does have real info. on such, that'd be really good to know. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTWt82AAoJEC88hzaAX42ijRcH/3s+Zt6FF3/i5op71yag1WFe igzXQ0zKPpDjNSuyoMNOT45xNts1fCyCVKlZW8xQQmPbwEvoi7SjfA4w7PipjkQo ar7FaR1AnfJbS+z4bJ6hpdxfLAepWONdfMsSh8KubSJ+KraWuC0XAyD15obPW+8u /YznfM1+Xgzh8MJuyGQsMi02gPz5ReFRx+6vy076QHbdyYNtcntgDO0d9AeFiFqy 0QvrQHJyE4IjbVbQiW5spuQsUGtF9gmNlH/P0g2ZQHjhgHEy6fAhMuyBDSG5DCAn w8nZ4EfHhrrhLq01lrA72l38zcUiKZlmD9gu/Ly4IqW9Ny7bZbutWpK9w/RwS0M= =uOuC -----END PGP SIGNATURE----- From nobody Fri Apr 25 15:21:00 2014 Return-Path: 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 1D4071A06D2 for ; Fri, 25 Apr 2014 15:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 EH4slcaYjfON for ; Fri, 25 Apr 2014 15:20:54 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7004E1A068E for ; Fri, 25 Apr 2014 15:20:54 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so5534722vcb.15 for ; Fri, 25 Apr 2014 15:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z5nM98IfDSydFUk1LICMDU7hyIYBrdDqCDLOkCxXD08=; b=N4omXajTRDeL8dr8BP6sAhVgWw/UCyYbZtZ3sk/hYZoLpHdrZ/ruhw9xjoBQBw9pmk z4ERSQCL/FxjinfLHif4J2POEnbfqRdVtLf7lTHZrAXueXUIPNiQPZXXaR2skXSFOb18 E60etKswVG+e4FzKt2TB6BoJHsF1Zvj6qbZb+zXrJ1XUsRcChv/hZcQfB13NJXdF+4YK mSQK5BwGz4FaXzAw5YHwTUrClsrmBnGvxHWLaSxBs6BdflVT5yx9TZbqrjEDHcf3oaRb m9N1aRw8/D0STnbU3v6fOzUT7oaT0ypHeM3K2v5nE3ebKq/jnhIh2ph4HGyzVVkxhBsY mgxA== X-Received: by 10.220.92.135 with SMTP id r7mr8836097vcm.11.1398464447776; Fri, 25 Apr 2014 15:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Fri, 25 Apr 2014 15:20:27 -0700 (PDT) In-Reply-To: <535ADEE2.300@isi.edu> References: <533C33D2.4060004@it.uc3m.es> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <53599E85.7010902@isi.edu> <5359A54F.7060201@isi.edu> <535AD28D.30701@cs.tcd.ie> <535ADEE2.300@isi.edu> From: Tony Arcieri Date: Fri, 25 Apr 2014 15:20:27 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b66f5fba4105804f7e56009 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/--tuZqEpqHNHrJ40Iojashfn4-A Cc: "tcpcrypt@ietf.org" , Stephen Farrell Subject: Re: [Tcpcrypt] Asking for proof, but not reading the papers cited X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:20:56 -0000 --047d7b66f5fba4105804f7e56009 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 3:17 PM, Joe Touch wrote: > So there are only two groups of people: > - those who disclose NSA funding or employment When confronted about your NSA involvement, you said: On Wed, Apr 23, 2014 at 8:58 PM, Joe Touch wrote: > On 4/23/2014 8:49 PM, Tony Arcieri wrote: > >> This is also the point in the conversation I seriously have to ask: are >> you working for the NSA to undermine this effort? >> > > You've asked yourself; only you can answer. > > I work for USC, and (as a consultant) myself on occasion, and no one else. > -- Tony Arcieri --047d7b66f5fba4105804f7e56009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 25, 2014 at 3:17 PM, Joe Touch <touch@isi.edu> wrote:
So there are only two groups of people:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - those who disclose NSA funding or employment<= /blockquote>

When confronted about your NSA involvement,= you said:

=C2=A0On Wed, Apr 23, 2014 at 8:58 = PM, Joe Touch=C2=A0<touch@isi.edu>=C2=A0wrote:
On 4/23/2014 8:49 PM, Tony Arcieri wrote:
This is also the point in the conversation I seriously have to ask: are
= you working for the NSA to undermine this effort?

You&#= 39;ve asked yourself; only you can answer.

I work for USC, and (as a= consultant) myself on occasion, and no one else.
=C2=A0
--
Tony Arcieri
--047d7b66f5fba4105804f7e56009-- From nobody Fri Apr 25 15:29:13 2014 Return-Path: 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 5283B1A03F2 for ; Fri, 25 Apr 2014 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no 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 3Q59jUkCtUY3 for ; Fri, 25 Apr 2014 15:29:06 -0700 (PDT) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id EC18E1A06D4 for ; Fri, 25 Apr 2014 15:28:54 -0700 (PDT) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTP id C3E21C021F for ; Fri, 25 Apr 2014 22:28:47 +0000 (UTC) Message-ID: <535AE19B.4090709@witmond.nl> Date: Sat, 26 Apr 2014 00:28:43 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <535ADEA8.4070609@witmond.nl> <535ADF39.5030509@cs.tcd.ie> In-Reply-To: <535ADF39.5030509@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MDIMRLRLCBWBLPRDJSIR" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/-cHFTjhpfCef9DRCP4wdAElDAx0 Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:29:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MDIMRLRLCBWBLPRDJSIR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/26/14 00:18, Stephen Farrell wrote: >=20 >=20 > On 04/25/2014 11:16 PM, Guido Witmond wrote: >> It's only a story, don't know if it is true or not but this is >> exactly what should be prevented. >=20 > I've heard similar myself, but always 3rd hand. If there were > real evidence of that I'd expect the ssl observatory or others > to have turned it up for TLS at least. > If someone does have real info. on such, that'd be really good > to know. Whether true or not is irrelevant, the fact that is might be very possible that someone lacks knowledge but has to act on something. Then mistakes are made. Taking the possibility of error away is the way forward. It also stops this round of 'spot the feds'. Heck, after 150 years of automobiles, people still put diesel in petrol engines and the other way around. >=20 > S. >=20 > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt >=20 ------enig2MDIMRLRLCBWBLPRDJSIR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTWuGbAAoJEHPd8GglaNRmrfgP/3rdl7koVjrSCOSL3BmYpBZH WX333j/G54l5yztIYdFHolvODYvHdIYs/s4TjVMX+o4iw7guuFB/34rjgElfq009 SQJyVzGOomW0SYhejWwH85bG6kMs1DVfFcrt16JtJL7Nn8szcd2SfOz9vzuEyJB2 Fee7Ql8AM8V1BOoUQPDiQOBrbAbgckLlt2Af1zTJD5Hz4eeHrFPBqyGTJLQi1KOq VkGmYRmjqhirI3TF03m2UeWqACAO/97XtTF4HPrWz9Hcsc598owqKMAjrTrnHlwn YqFb+A1oqTNaXdvgrIh/6sZ26JA8CfY//2DZsy6vIAstLCxKNlvYNAaAqTMr2Qor qH4dgeq/tphvJtPc+dHC2UQ+X1aRM6Tt/qymbTSme37TZ1Iwk/j16MDonSnmLcsU qPoR7OvDlo6Ov8BcKI1NxlzCxHIhn1PS4UBDSliS+iCcIhwMrj46uPUlSeKe8kb1 MXZBiV7L1e9FFEhCus3GT/Z7adOB/9VWiXUbsWEkYV+RPa1Bi+pPa8r5F0UwPnJ7 rZO/pQBbdHROis1a7nS8TIydoWMm69H44t1/76T/EyIu4ydQOSNil4gqHRhE/1u7 6VP/eW2qm3nxo7adg+/kgmkWQrBW7MzmcLyfJQUPN50bD3uAeQQdQ8lq8FbuLlhP BsQcMs87WvYjt5K4vQiN =Nheg -----END PGP SIGNATURE----- ------enig2MDIMRLRLCBWBLPRDJSIR-- From nobody Fri Apr 25 15:29:58 2014 Return-Path: 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 4A0961A03F2 for ; Fri, 25 Apr 2014 15:29:56 -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 QI0cuUL__kdi for ; Fri, 25 Apr 2014 15:29:53 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6061A068E for ; Fri, 25 Apr 2014 15:29:52 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 724B18B8E92 for ; Sat, 26 Apr 2014 00:29:45 +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 45E9676C892 for ; Sat, 26 Apr 2014 00:29:45 +0200 (CEST) Message-ID: <535AE1D8.60107@it.uc3m.es> Date: Sat, 26 Apr 2014 00:29:44 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> In-Reply-To: <535AD44A.2000603@cs.tcd.ie> 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-20656.002 X-TM-AS-Result: No--11.044-7.0-31-1 X-imss-scan-details: No--11.044-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ph0pvueBoHV3ppRRUoH8K0LgHd4 Subject: [Tcpcrypt] Getting back to the charter, maybe? Re: NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:29:56 -0000 El 25/04/14 23:31, Stephen Farrell escribió: > > All that said, I don't think this needs to be decided right now > and nor do I think we're in a position where we could make a > sensible yes/no decision on this topic now, before we have more > detail of TCP Inc. (great name btw:-) figured out. > Right. For amusing this discussion may be, i think we need to keep in mind what we need to achieve at this stage i.e. come up with a charter so we can get a WG and then we continue with all the fun of these discussions. So, for me, whether we allow NULL encryption of disabling encryption in the middle of the TCP connection, should not be decided in the charter, but shold be left for the WG to decide. We have received some useful input on this second version of the charter, i will work on a revision of it in the next week. Please if you do have comments that impact the charter, please bring them up. Regards, marcelo From nobody Fri Apr 25 15:33:43 2014 Return-Path: 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 059181A06C5 for ; Fri, 25 Apr 2014 15:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 fiMolA8aQyxK for ; Fri, 25 Apr 2014 15:33:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3D1A040C for ; Fri, 25 Apr 2014 15:33:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99AF7BE74; Fri, 25 Apr 2014 23:33:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw1A1y43eVfN; Fri, 25 Apr 2014 23:33:29 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.68.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 839D3BE62; Fri, 25 Apr 2014 23:33:29 +0100 (IST) Message-ID: <535AE2B9.2040002@cs.tcd.ie> Date: Fri, 25 Apr 2014 23:33:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Guido Witmond , tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <535ADEA8.4070609@witmond.nl> <535ADF39.5030509@cs.tcd.ie> <535AE19B.4090709@witmond.nl> In-Reply-To: <535AE19B.4090709@witmond.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xbw5D5Vb8qTk-Mr0CdF43BY3i6c Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:33:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/25/2014 11:28 PM, Guido Witmond wrote: > Whether true or not is irrelevant, the fact that is might be very > possible that someone lacks knowledge but has to act on something. > Then mistakes are made. Well not quite. I agree its not that relevant for the current discussion (apologies Marcelo;-) since as I said I figure we're not yet in a position to argue about that properly. But knowing vs. wondering makes a big difference - e.g. a 2012 tin foil hat vs. snowdonia makes a real difference in terms of whether or not people are willing to do work to make stuff better. So it'd be generally useful to know for sure I think. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTWuK5AAoJEC88hzaAX42i4DkH/Rx2R1W0t40T/dQlHQdlG3vP kGnjH41f/VCYcUoIk7uR91cX3MAcrdlbJxUk30HHv3ekDeDuwKLncGInnRlOJKXU dzOdYO+B5QQkZic1FSGu8LezgdutkOdnWIWxKkPnqRaHeWdZV4tHi7rwDP8CngjM iUdOiuA+kaHbIZbG5EBixC7MIiy0HTFbP/4Aa1J2R2LWEf+MSeHd/+h5RS/iFg94 3Ff4nJN/Jn2Q9zK6YA8/1UlcJcBcOuPuk6BmSWFGfQ27iblIu6NEF2WMQiGzH1Bl 8h0HetyQnA3tf1f8sMXJ/D7uAIbCb5AF1edrdleYwzNaDfiDhHFrF10POeo/940= =Bv3w -----END PGP SIGNATURE----- From nobody Fri Apr 25 15:34:54 2014 Return-Path: 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 453F21A06C5 for ; Fri, 25 Apr 2014 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 I7egEzsYaHiR for ; Fri, 25 Apr 2014 15:34:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 191621A040C for ; Fri, 25 Apr 2014 15:34:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3PMWuZV000624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Apr 2014 15:32:56 -0700 (PDT) Message-ID: <535AE298.1000409@isi.edu> Date: Fri, 25 Apr 2014 15:32:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri , Mark Handley References: <533C33D2.4060004@it.uc3m.es> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398463495.23831.110504821.6A80D6D3@webmail.messagingengine.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/cXpSrlFeFG0Zhg6oucUtMuFQdA8 Cc: "tcpcrypt@ietf.org" , Stephen Farrell Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:34:50 -0000 On 4/25/2014 3:14 PM, Tony Arcieri wrote: > I'm talking about Joe Touch, who is probably the main impetus for this > thread. Check the thread; I wasn't the one who raised the issue of NULL-mode. For the benefit of others, here's a link to my NSA-sponsored work: http://www.isi.edu/touch/atp.html It's so linked on my web pages, and my CV. That's exactly how well I've been hiding it. If anyone wants to hear a talk on it, and is willing to pay for the travel, I'll be glad to do so ;-) My view of network security is public and well documented. It's basically that people like you make security so difficult that nobody uses it - so if you're looking for a reason YOU shouldn't be trusted, that's a fine one. Easier-to-use security was the basis of BTNS (which has nothing to do with ATP), and a number of projects I've been involved with since 1995. It includes a keynote I gave at the Computer Communications Workshop last year as well. Joe From nobody Sun Apr 27 13:07:20 2014 Return-Path: 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 0ACD71A07A2 for ; Sun, 27 Apr 2014 13:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 6iDUnSTZMKEH for ; Sun, 27 Apr 2014 13:07:14 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC81A066A for ; Sun, 27 Apr 2014 13:07:13 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 911CB6D4A7; Sun, 27 Apr 2014 16:07:09 -0400 (EDT) Message-ID: <535D636D.8050108@iang.org> Date: Sun, 27 Apr 2014 21:07:09 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> In-Reply-To: <53576572.5030805@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/hiV5osBhH0vBe4MBoocK0lBHHYg 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 20:07:18 -0000 Hi Marcelo On 23/04/2014 08:02 am, marcelo bagnulo braun wrote: > Hi, > > Thanks for the lively discussion on the charter text. > I attach a new version of the charter trying to include the received > comments. > I have tried to be carefull using the should and the must, so please > look into those. As this is a charter, I'm not sure MUST is appropriate with every thing we want. > I tried to reflect the different levels of requirements for the > resulting protocol. > As usual comments are welcome. > > > > TCP Increased Security (TCP Inc.) > > The TCP Inc. WG will develop the TCP extensions to provide unauthenticated > encryption and integrity protection of TCP streams. The WG will define the > TCP extensions to perform an unauthenticated key exchange resulting in > encryption > without authentication. This is better than plain-text because it thwarts > passive eavesdropping, but is weaker than using authenticated keys, > because it > is vulnerable to man-in-the-middle attacks. This work is part of the IETF > effort to harness the Internet architecture given the latest events of > pervasive > monitoring (see draft-farrell-perpass-attack). > > The working group is looking to produce experimental documents > specifying the > required TCP extensions and any additional informational documents needed. It would be nice to have something about goals here. Something like: We are looking for the designs that find the sweet spot between conflicting requirements: to provide reasonable security for the majority of connections. Because we are dealing with unprotected connections, we are more focussed on improving from baseline of no security than achieving the high standard of security that is already available to users of TLS. > The high-level requirements for the protocol for providing TCP > unauthenticated > encryption and integrity protection are: > > - Deployable and usable without significant changes to existing Internet > infrastructure, in particular it must be compatible with NATs (at the > very minimum with the NATs that comply with BEHAVE requirements as > documented > in RFC4787, RFC5382 and RFC5508); > > - The protocol must be usable by unmodified applications. This effort > is complementary > to other security protocols developed in the IETF (such as TLS) as it > protects > those applications and protocols that are difficult to change or may > even not > be changed in a backward compatible way. It also provides some > protection in > scenarios where people are unwilling to do any change just for the > sake of > security (e.g., like configure encryption in an application). > > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, So, in the above, we see the "When encryption is enabled," which is repeated through out. I would suggest this immediate above para be swapped with the below para, as then the flowchart is more clear. Then, that phrase be dropped because it is an implementation detail. Like this: - If encryption cannot be achieved, must gracefully fall-back to TCP. - Elsewise, must at least provide protection against passive eavesdropping by default, - must ... > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > - When encryption is enabled, it must always provide forward secrecy. > > - When encryption is enabled, it must always provide integrity > protection of the > payload data (it is open for discussion for the WG if the TCP header > should or > not be protected) > > - When encryption is enabled, it must always provide payload encryption. > > - Should attempt to use the least amount of TCP option space. All of those above, and some below, are the sort of thing that any protocol is going to aim for anyway. They could be simply collapsed into something like: - should provide the best mix possible of the following features: - forward and backward secrecy - encryption and integrity protection over the payload - most efficient use of the TCP option space - efficient performance, including restart using previously exchanged keys - minimise scope for linkability and fingerprinting - synergies with other aspects such as multipath and fast open. Otherwise you're sort of teaching grandma to suck eggs, which is right to do in a WG but not in the charter... ;) > - Must not require any authentication or configuration from > applications or users. However, hooks for external authentication > must be > made available. The WG will not work on new authentication mechanisms. > > - The protocol must have acceptable performance. For example, the > protocol may > try to re-use existing cryptographic material for future communication > between the > same endpoints to avoid expensive public key operations on connection > set up. > > - Hooks for allowing upper layers to disable encryption must be made > available. > The protocol may try to avoid redundant encryption when it is possible > e.g. > by detecting encryption performed by upper layers (notably, when TLS > is used). Disagree. The protocol may have it in there (sad!), and devs will have this in their code for development phase, but mandating it is just opening a can of worms. Especially in the charter. > - No extra linkability: when encryption is enabled the TCP traffic > should not > give a third party observer any extra way to associate those packets > with the > specific peers beyond information that would have been present in a > cleartext session. > > - Client fingerprinting: some clients may want to avoid appearing as the > same > client when connecting to a remote peer on subsequent occasions. This > should either > be the default (clients cannot be "fingerprinted" by the server based > on shared state) > or some mechanism should be available for clients to drop or ignore > shared state to avoid > being fingerprintable. > > Security features at the TCP-level can benefit other TCP extensions. For > example, both Multipath TCP and TCP Fast Open require proof that some > connections are > related. Session resumption and Message Authentication Codes (MACs) can > provide > this evidence. The working group should identify synergies and design the > security protocol in such a way that other TCP efforts can benefit from > it. Of > course, TCP extensions that break must be identified too, and kept to a > minimum. > > The working group will produce the following documents: > > - A framework for unauthenticated encryption and integrity protection of > TCP connections. > This document will describe basic design considerations, including the > motivation and the > applicability of the proposed mechanism, the interaction with other > security mechanisms in > different layers of the stack, the interaction with external > authentication mechanisms, the > expected protection, privacy considerations and residual threats. > > - Extensions to current TCP to support unauthenticated key exchange and > encryption and > integrity protection. This covers all the protocol changes required. > This will be a > experimental document. > > - An extended API describing how applications can obtain further > benefits of the > proposed extensions. In particular, the hooks for supporting external > authentication > will be defined in this document and the hooks for disabling encryption. > This will be an informational document. some thoughts. iang From nobody Sun Apr 27 13:43:36 2014 Return-Path: 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 1349C1A07A7 for ; Sun, 27 Apr 2014 13:43:35 -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 KnztrSlwJJFF for ; Sun, 27 Apr 2014 13:43:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id D25351A07A2 for ; Sun, 27 Apr 2014 13:43:30 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AB7699D71BC for ; Sun, 27 Apr 2014 22:43:29 +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 6316B9C49F8 for ; Sun, 27 Apr 2014 22:43:29 +0200 (CEST) Message-ID: <535D6BF2.6040304@it.uc3m.es> Date: Sun, 27 Apr 2014 22:43:30 +0200 From: marcelo bagnulo braun 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> <535D636D.8050108@iang.org> In-Reply-To: <535D636D.8050108@iang.org> 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-20660.002 X-TM-AS-Result: No--25.901-7.0-31-1 X-imss-scan-details: No--25.901-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1dRxPRMbJHy2QN8hZtbvDHdYhLk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 20:43:35 -0000 thanks for the comments, replies below... El 27/04/14 22:07, ianG escribió: > Hi Marcelo > > On 23/04/2014 08:02 am, marcelo bagnulo braun wrote: >> Hi, >> >> Thanks for the lively discussion on the charter text. >> I attach a new version of the charter trying to include the received >> comments. >> I have tried to be carefull using the should and the must, so please >> look into those. > > As this is a charter, I'm not sure MUST is appropriate with every thing > we want. > I dont follow. It is perfectly appropriate to have musts in the charter. >> I tried to reflect the different levels of requirements for the >> resulting protocol. >> As usual comments are welcome. >> >> >> >> TCP Increased Security (TCP Inc.) >> >> The TCP Inc. WG will develop the TCP extensions to provide unauthenticated >> encryption and integrity protection of TCP streams. The WG will define the >> TCP extensions to perform an unauthenticated key exchange resulting in >> encryption >> without authentication. This is better than plain-text because it thwarts >> passive eavesdropping, but is weaker than using authenticated keys, >> because it >> is vulnerable to man-in-the-middle attacks. This work is part of the IETF >> effort to harness the Internet architecture given the latest events of >> pervasive >> monitoring (see draft-farrell-perpass-attack). >> >> The working group is looking to produce experimental documents >> specifying the >> required TCP extensions and any additional informational documents needed. > > It would be nice to have something about goals here. Something like: > > We are looking for the designs that find the sweet spot between > conflicting requirements: to provide reasonable security for the > majority of connections. Because we are dealing with unprotected > connections, we are more focussed on improving from baseline of no > security than achieving the high standard of security that is already > available to users of TLS. > sounds good to me >> The high-level requirements for the protocol for providing TCP >> unauthenticated >> encryption and integrity protection are: >> >> - Deployable and usable without significant changes to existing Internet >> infrastructure, in particular it must be compatible with NATs (at the >> very minimum with the NATs that comply with BEHAVE requirements as >> documented >> in RFC4787, RFC5382 and RFC5508); >> >> - The protocol must be usable by unmodified applications. This effort >> is complementary >> to other security protocols developed in the IETF (such as TLS) as it >> protects >> those applications and protocols that are difficult to change or may >> even not >> be changed in a backward compatible way. It also provides some >> protection in >> scenarios where people are unwilling to do any change just for the >> sake of >> security (e.g., like configure encryption in an application). >> >> - When encryption is enabled, it must at least provide protection against >> passive eavesdropping by default, > > So, in the above, we see the "When encryption is enabled," which is > repeated through out. I would suggest this immediate above para be > swapped with the below para, as then the flowchart is more clear. Then, > that phrase be dropped because it is an implementation detail. > > Like this: > > > - If encryption cannot be achieved, must gracefully fall-back to TCP. > > - Elsewise, must at least provide protection against passive > eavesdropping by default, > > - must ... > In the first version of the charter it was not explict that these things were required when encryption is enabled, and i received several comments about it, so i made it explicit. I think it is more imprtnat for the charter to be clear than to read nicely, so i think we should keep it. >> - Must gracefully fall-back to TCP if the remote peer does not support the >> proposed extensions >> >> - When encryption is enabled, it must always provide forward secrecy. >> >> - When encryption is enabled, it must always provide integrity >> protection of the >> payload data (it is open for discussion for the WG if the TCP header >> should or >> not be protected) >> >> - When encryption is enabled, it must always provide payload encryption. >> >> - Should attempt to use the least amount of TCP option space. > > All of those above, and some below, are the sort of thing that any > protocol is going to aim for anyway. They could be simply collapsed > into something like: > > - should provide the best mix possible of the following features: > - forward and backward secrecy > - encryption and integrity protection over the payload > - most efficient use of the TCP option space > - efficient performance, including restart using previously exchanged > keys > - minimise scope for linkability and fingerprinting > - synergies with other aspects such as multipath and fast open. mmm, but the problem si that you are not making distinctions between thing we want to be mandatory (encryption) and other things that we would like but it is not clear how much we will achieve (like efficient use of option space ). To make a very silly example, if we dont do encryption, we do a very optimal use of the option space, but that is not what we want. > Otherwise you're sort of teaching grandma to suck eggs, which is right > to do in a WG but not in the charter... ;) > > >> - Must not require any authentication or configuration from >> applications or users. However, hooks for external authentication >> must be >> made available. The WG will not work on new authentication mechanisms. >> >> - The protocol must have acceptable performance. For example, the >> protocol may >> try to re-use existing cryptographic material for future communication >> between the >> same endpoints to avoid expensive public key operations on connection >> set up. >> >> - Hooks for allowing upper layers to disable encryption must be made >> available. >> The protocol may try to avoid redundant encryption when it is possible >> e.g. >> by detecting encryption performed by upper layers (notably, when TLS >> is used). > > Disagree. The protocol may have it in there (sad!), and devs will have > this in their code for development phase, but mandating it is just > opening a can of worms. Especially in the charter. You think this should be a should? Regards, marcelo >> - No extra linkability: when encryption is enabled the TCP traffic >> should not >> give a third party observer any extra way to associate those packets >> with the >> specific peers beyond information that would have been present in a >> cleartext session. >> >> - Client fingerprinting: some clients may want to avoid appearing as the >> same >> client when connecting to a remote peer on subsequent occasions. This >> should either >> be the default (clients cannot be "fingerprinted" by the server based >> on shared state) >> or some mechanism should be available for clients to drop or ignore >> shared state to avoid >> being fingerprintable. >> >> Security features at the TCP-level can benefit other TCP extensions. For >> example, both Multipath TCP and TCP Fast Open require proof that some >> connections are >> related. Session resumption and Message Authentication Codes (MACs) can >> provide >> this evidence. The working group should identify synergies and design the >> security protocol in such a way that other TCP efforts can benefit from >> it. Of >> course, TCP extensions that break must be identified too, and kept to a >> minimum. >> >> The working group will produce the following documents: >> >> - A framework for unauthenticated encryption and integrity protection of >> TCP connections. >> This document will describe basic design considerations, including the >> motivation and the >> applicability of the proposed mechanism, the interaction with other >> security mechanisms in >> different layers of the stack, the interaction with external >> authentication mechanisms, the >> expected protection, privacy considerations and residual threats. >> >> - Extensions to current TCP to support unauthenticated key exchange and >> encryption and >> integrity protection. This covers all the protocol changes required. >> This will be a >> experimental document. >> >> - An extended API describing how applications can obtain further >> benefits of the >> proposed extensions. In particular, the hooks for supporting external >> authentication >> will be defined in this document and the hooks for disabling encryption. >> This will be an informational document. > > > some thoughts. > > iang > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Sun Apr 27 14:01:32 2014 Return-Path: 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 884091A06B7 for ; Sun, 27 Apr 2014 14:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4G9bFb-feOwv for ; Sun, 27 Apr 2014 14:01:20 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 3643F1A07CB for ; Sun, 27 Apr 2014 14:01:20 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 12C806D48F; Sun, 27 Apr 2014 17:01:18 -0400 (EDT) Message-ID: <535D701E.6030004@iang.org> Date: Sun, 27 Apr 2014 22:01:18 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> In-Reply-To: <535D6BF2.6040304@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5P1rbNBQjluD0oGuZ1tDjRJiGyo 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 21:01:28 -0000 On 27/04/2014 21:43 pm, marcelo bagnulo braun wrote: >>> The high-level requirements for the protocol for providing TCP >>> unauthenticated >>> encryption and integrity protection are: >>> >>> - Deployable and usable without significant changes to existing Internet >>> infrastructure, in particular it must be compatible with NATs (at the >>> very minimum with the NATs that comply with BEHAVE requirements as >>> documented >>> in RFC4787, RFC5382 and RFC5508); >>> >>> - The protocol must be usable by unmodified applications. This effort >>> is complementary >>> to other security protocols developed in the IETF (such as TLS) as it >>> protects >>> those applications and protocols that are difficult to change or may >>> even not >>> be changed in a backward compatible way. It also provides some >>> protection in >>> scenarios where people are unwilling to do any change just for the >>> sake of >>> security (e.g., like configure encryption in an application). >>> >>> - When encryption is enabled, it must at least provide protection >>> against >>> passive eavesdropping by default, >> >> So, in the above, we see the "When encryption is enabled," which is >> repeated through out. I would suggest this immediate above para be >> swapped with the below para, as then the flowchart is more clear. Then, >> that phrase be dropped because it is an implementation detail. >> >> Like this: >> >> >> - If encryption cannot be achieved, must gracefully fall-back to TCP. >> >> - Elsewise, Perhaps here, insert: Elsewise, all the following apply: >> must at least provide protection against passive >> eavesdropping by default, >> >> - must ... >> > > In the first version of the charter it was not explict that these things > were required when encryption is enabled, and i received several > comments about it, so i made it explicit. I think it is more imprtnat > for the charter to be clear than to read nicely, so i think we should > keep it. Well, the point of putting the fall-back first is that there are two modes of operation: passthru and ENCRYPTED. On starting up, the protocol can enter either of these two states, but not transition between them. This choice dominates all to follow [0]. Then, for ENCRYPTED mode, all of the additional points apply. For passthru mode, none of the additional points apply. So it's easier to have the passthru mode listed first, then disposed of as far as further writing is concerned. >>> - Must gracefully fall-back to TCP if the remote peer does not >>> support the >>> proposed extensions >>> >>> - When encryption is enabled, it must always provide forward secrecy. >>> >>> - When encryption is enabled, it must always provide integrity >>> protection of the >>> payload data (it is open for discussion for the WG if the TCP header >>> should or >>> not be protected) >>> >>> - When encryption is enabled, it must always provide payload encryption. >>> >>> - Should attempt to use the least amount of TCP option space. >> >> All of those above, and some below, are the sort of thing that any >> protocol is going to aim for anyway. They could be simply collapsed >> into something like: >> >> - should provide the best mix possible of the following features: >> - forward and backward secrecy >> - encryption and integrity protection over the payload >> - most efficient use of the TCP option space >> - efficient performance, including restart using previously exchanged >> keys >> - minimise scope for linkability and fingerprinting >> - synergies with other aspects such as multipath and fast open. > > mmm, but the problem si that you are not making distinctions between > thing we want to be mandatory (encryption) and other things that we > would like but it is not clear how much we will achieve (like efficient > use of option space ). To make a very silly example, if we dont do > encryption, we do a very optimal use of the option space, but that is > not what we want. > >> Otherwise you're sort of teaching grandma to suck eggs, which is right >> to do in a WG but not in the charter... ;) This bit above! If we need to remind someone doing a mandatory encryption in a security protocol, then we've got another problem and we shouldn't be in the job :) Hence the early objections to the kill switch. ... >>> - Hooks for allowing upper layers to disable encryption must be made >>> available. >>> The protocol may try to avoid redundant encryption when it is >>> possible >>> e.g. >>> by detecting encryption performed by upper layers (notably, when TLS >>> is used). >> >> Disagree. The protocol may have it in there (sad!), and devs will have >> this in their code for development phase, but mandating it is just >> opening a can of worms. Especially in the charter. > > You think this should be a should? Well. I think the RFC should list it as a MAY so that people who read it can be alerted to the fact that they had better figure out how this happens and make sure it never happens on their watch. I don't think it should be a SHOULD because I've yet to see a valid reason for it. All of the reasons so far presented have been handwavy, very edge-case or development only. And I don't see its place in the Charter. It seems like cursing the baby before its been born. iang [0] I am assuming these two exlusive modes. This could be challenged. From nobody Sun Apr 27 14:08:51 2014 Return-Path: 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 381981A07C8 for ; Sun, 27 Apr 2014 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 6fUTm2J2s4H0 for ; Sun, 27 Apr 2014 14:08:23 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 514201A07C0 for ; Sun, 27 Apr 2014 14:07:51 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so6986371veb.39 for ; Sun, 27 Apr 2014 14:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JiopLpW8qKJB8T1oeuJi2q0Z4OivHOoPU+uLu2gfJJ8=; b=K6uRaEpXsV8zgfeZ15toPmREGHaurpyifcpEMdXJOy7zX9ksZLCVoVl8Ch6o7m4F/E WymN0Y9CZ2crKcMvRl5KgXRObXnRyPh1xbckdrM5Kp0IUgE8FwNqPOd1Lfeco+03lc2m lGlij+ccc51mx7j9mK/LD59Wv8ONJg2HfjkhUtGk3KJnvMxKKoSPk8Dh1WV2gNnRHiWh 8eZgHCqebkJ1Hre0w93fSiHivptO2zr39WDTdYaRT7hruAUAac9T2GhxlDF91f9I7Ojk Ur4dDULB4k7p9XIrRsdmR2RDLW1Gp5I646BFMV3gfVb9YJXxtRkBh6IcsykEKrCPS4OD QlbA== X-Received: by 10.220.59.65 with SMTP id k1mr19780042vch.22.1398632870603; Sun, 27 Apr 2014 14:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Sun, 27 Apr 2014 14:07:30 -0700 (PDT) In-Reply-To: <535D701E.6030004@iang.org> References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D701E.6030004@iang.org> From: Tony Arcieri Date: Sun, 27 Apr 2014 14:07:30 -0700 Message-ID: To: ianG Content-Type: multipart/alternative; boundary=001a11c295026c716e04f80c978e Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5ZfjXMieV8HpdOXYevdt5jBDQrU Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 21:08:28 -0000 --001a11c295026c716e04f80c978e Content-Type: text/plain; charset=UTF-8 On Sun, Apr 27, 2014 at 2:01 PM, ianG wrote: > Well. I think the RFC should list it as a MAY so that people who read > it can be alerted to the fact that they had better figure out how this > happens and make sure it never happens on their watch. > > I don't think it should be a SHOULD because I've yet to see a valid > reason for it. All of the reasons so far presented have been handwavy, > very edge-case or development only. > > And I don't see its place in the Charter. It seems like cursing the > baby before its been born. I'm not even sure why it's being considered for the charter. This is not a feature offered by, say, full disk encryption software, even though people may wind up double encrypting files. It's also proven not to be a problem in practice, even though the need to decrypt bypasses things like DMA. It seems even less important for ubiquitous network encryption, where the network is far more likely to be the bottleneck. -- Tony Arcieri --001a11c295026c716e04f80c978e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 27, 2014 at 2:01 PM, ianG <iang@iang.= org> wrote:
Well. =C2=A0I think the RFC should list it = as a MAY so that people who read
it can be alerted to the fact that they had better figure out how this
happens and make sure it never happens on their watch.

I don't think it should be a SHOULD because I've yet to see a valid=
reason for it. =C2=A0All of the reasons so far presented have been handwavy= ,
very edge-case or development only.

And I don't see its place in the Charter. =C2=A0It seems like cursing t= he
baby before its been born.

I'm not even= sure why it's being considered for the charter. This is not a feature = offered by, say, full disk encryption software, even though people may wind= up double encrypting files. It's also proven not to be a problem in pr= actice, even though the need to decrypt bypasses things like DMA.

It seems even less important for ubiquitous network enc= ryption, where the network is far more likely to be the bottleneck.=C2=A0

--
Tony Arcieri
--001a11c295026c716e04f80c978e-- From nobody Sun Apr 27 14:29:40 2014 Return-Path: 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 645221A06B7 for ; Sun, 27 Apr 2014 14:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 S7w2CIS2o4Qj for ; Sun, 27 Apr 2014 14:29:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFFE1A03C9 for ; Sun, 27 Apr 2014 14:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 435F9BE5C; Sun, 27 Apr 2014 22:29:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeJcN6USId1A; Sun, 27 Apr 2014 22:29:33 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.23.102]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2177FBE58; Sun, 27 Apr 2014 22:29:33 +0100 (IST) Message-ID: <535D76BC.4060007@cs.tcd.ie> Date: Sun, 27 Apr 2014 22:29:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: marcelo bagnulo braun , tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> In-Reply-To: <535D6BF2.6040304@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/SPnJul28PWtNIjmxnGmIsOtSGN4 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 21:29:38 -0000 Hi Marcelo, On 27/04/14 21:43, marcelo bagnulo braun wrote: > > - Hooks for allowing upper layers to disable encryption must be made > available. > The protocol may try to avoid redundant encryption when it is possible > e.g. > by detecting encryption performed by upper layers (notably, when TLS > is used). Based on all the discussion on this so far, I'd also suggest deleting this bit. I agree with Ian that the reasons for including this stated so far are arm-wavy. And "detecting" that higher layers are encrypting vs. compressing seems unlikely in the general case too. If something is using TLS then the TLS code (which normally calls the socket API I think) can presumably determine if TCP Inc. would be on by default and do the right thing so there's no need for TCP Inc. to do anything for that case even if someone concludes that double wrapping isn't what they want. So count me as another -1 on inclusion of the above. That said, I think that the argument for null ciphers could still be made later (which might be one way to deal with the wish expressed above), and I'm sure someone will inevitably make the argument for that for debugging purposes so since we know it'll happen we don't really need to argue about whether that's ok or not now:-) As I've also said before, I'd need to be convinced that those are worthwhile myself so as of now I'd say not defining 'em is the right thing. S. From nobody Sun Apr 27 14:34:01 2014 Return-Path: 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 D3DC81A03DF for ; Sun, 27 Apr 2014 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wRXYoC3JkPnc for ; Sun, 27 Apr 2014 14:33:59 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 054611A03C9 for ; Sun, 27 Apr 2014 14:33:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4C5CA6D49C; Sun, 27 Apr 2014 17:33:55 -0400 (EDT) Message-ID: <535D77C2.6060609@iang.org> Date: Sun, 27 Apr 2014 22:33:54 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D701E.6030004@iang.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/hlR5M2ii6nV5c9mUCUuNbPsJfVQ 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 21:34:01 -0000 On 27/04/2014 22:07 pm, Tony Arcieri wrote: > On Sun, Apr 27, 2014 at 2:01 PM, ianG > wrote: > > Well. I think the RFC should list it as a MAY so that people who read > it can be alerted to the fact that they had better figure out how this > happens and make sure it never happens on their watch. > > I don't think it should be a SHOULD because I've yet to see a valid > reason for it. All of the reasons so far presented have been handwavy, > very edge-case or development only. > > And I don't see its place in the Charter. It seems like cursing the > baby before its been born. > > > I'm not even sure why it's being considered for the charter. I don't understand it either. But if you look at the tcp-crypt draft, it's firmly in there. http://tcpcrypt.org/draft-bittau-tcp-crypt.txt This may be a cultural thing. Us user folk might just not want it, but in the WG world it might be something they can't conceive of not mandating. I await with interest the reasons... However, what I'm more concerned about is that in the draft, it does the old "cipher suite negotiation" thing. I would have thought that was so obviously unrequired, but apparently not. If we have cipher suite negotiation in there, talking about the universal kill switch is rather moot because someone will slip in some bad ciphers. Interesting debates ahead I suspect. Keep your powder dry. iang > This is not > a feature offered by, say, full disk encryption software, even though > people may wind up double encrypting files. It's also proven not to be a > problem in practice, even though the need to decrypt bypasses things > like DMA. > > It seems even less important for ubiquitous network encryption, where > the network is far more likely to be the bottleneck. > > -- > Tony Arcieri From nobody Sun Apr 27 22:31:57 2014 Return-Path: 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 681231A070F for ; Sun, 27 Apr 2014 22:31:55 -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 jXI5DguGSGpK for ; Sun, 27 Apr 2014 22:31:52 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6221A06F1 for ; Sun, 27 Apr 2014 22:31:52 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C928E9D352E for ; Mon, 28 Apr 2014 07:31:50 +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 973159D2FF6 for ; Mon, 28 Apr 2014 07:31:50 +0200 (CEST) Message-ID: <535DE7C6.80902@it.uc3m.es> Date: Mon, 28 Apr 2014 07:31:50 +0200 From: marcelo bagnulo braun 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> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D76BC.4060007@cs.tcd.ie> In-Reply-To: <535D76BC.4060007@cs.tcd.ie> 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-20660.005 X-TM-AS-Result: No--22.627-7.0-31-1 X-imss-scan-details: No--22.627-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zpmZKDlMS32cijiIuwWI_rCcQ20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 05:31:55 -0000 El 27/04/14 23:29, Stephen Farrell escribió: > Hi Marcelo, > > On 27/04/14 21:43, marcelo bagnulo braun wrote: >> - Hooks for allowing upper layers to disable encryption must be made >> available. >> The protocol may try to avoid redundant encryption when it is possible >> e.g. >> by detecting encryption performed by upper layers (notably, when TLS >> is used). > Based on all the discussion on this so far, I'd also suggest > deleting this bit. I agree with Ian that the reasons for > including this stated so far are arm-wavy. And "detecting" > that higher layers are encrypting vs. compressing seems unlikely > in the general case too. If something is using TLS then the > TLS code (which normally calls the socket API I think) can > presumably determine if TCP Inc. would be on by default and > do the right thing so there's no need for TCP Inc. to do > anything for that case even if someone concludes that double > wrapping isn't what they want. > > So count me as another -1 on inclusion of the above. mmm, I guess i misread the previous discussion or i didnt managed to explain what i had in mind. Let me try to explain myself (not trying to push for this, just want to clarify). What i had in mind was _not_ about allowing the upper layer to disable the encryption in the middle of a connection. What i had in mind was to allow the upper layer to say: "please for this connection, dont use TCP-INC, just use plain old TCP". This is because the upperlayer may knwo better, for instance, it is building its onw security. If we dont provide this hook, then it is always encrypted if both ends support and there is nothing the upper layer can do in order to avoid it. Please also note that this does not allow for the peer to downgrade the connection or terminate encryption, as this has no impact in the wire, it is only at the begining of the connection. Does this clarify things? What do you think? That being said, I am perfectly fine with removing it from the charter. Regards, marcelo > > That said, I think that the argument for null ciphers could > still be made later (which might be one way to deal with the > wish expressed above), and I'm sure someone will inevitably > make the argument for that for debugging purposes so since > we know it'll happen we don't really need to argue about > whether that's ok or not now:-) As I've also said before, > I'd need to be convinced that those are worthwhile myself > so as of now I'd say not defining 'em is the right thing. > > S. > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Mon Apr 28 03:42:28 2014 Return-Path: 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 B55C81A096E for ; Mon, 28 Apr 2014 03:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 d_r3AeOWxSc2 for ; Mon, 28 Apr 2014 03:42:25 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 050661A08EA for ; Mon, 28 Apr 2014 03:42:24 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id B2D856D555; Mon, 28 Apr 2014 06:42:22 -0400 (EDT) Message-ID: <535E308D.2090609@iang.org> Date: Mon, 28 Apr 2014 11:42:21 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D76BC.4060007@cs.tcd.ie> <535DE7C6.80902@it.uc3m.es> In-Reply-To: <535DE7C6.80902@it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/86xoK4JD1lJzvybJYSoxk0rgtro 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 10:42:26 -0000 On 28/04/2014 06:31 am, marcelo bagnulo braun wrote: > El 27/04/14 23:29, Stephen Farrell escribió: >> Hi Marcelo, >> >> On 27/04/14 21:43, marcelo bagnulo braun wrote: >>> - Hooks for allowing upper layers to disable encryption must be made >>> available. >>> The protocol may try to avoid redundant encryption when it is >>> possible >>> e.g. >>> by detecting encryption performed by upper layers (notably, when TLS >>> is used). >> Based on all the discussion on this so far, I'd also suggest >> deleting this bit. I agree with Ian that the reasons for >> including this stated so far are arm-wavy. And "detecting" >> that higher layers are encrypting vs. compressing seems unlikely >> in the general case too. If something is using TLS then the >> TLS code (which normally calls the socket API I think) can >> presumably determine if TCP Inc. would be on by default and >> do the right thing so there's no need for TCP Inc. to do >> anything for that case even if someone concludes that double >> wrapping isn't what they want. >> >> So count me as another -1 on inclusion of the above. > > mmm, I guess i misread the previous discussion or i didnt managed to > explain what i had in mind. > > Let me try to explain myself (not trying to push for this, just want to > clarify). > > What i had in mind was _not_ about allowing the upper layer to disable > the encryption in the middle of a connection. Well, yes, I don't think anyone had that in mind. > What i had in mind was to allow the upper layer to say: "please for this > connection, dont use TCP-INC, just use plain old TCP". This is understood. I believe this will exist in implementations, regardless, for development purposes. I also believe the smart implementors will realise they don't need it, and nor do their users, and that they will solve some problems by getting rid of it (which realisation will also infect thinking about ciphersuites). > This is because > the upperlayer may knwo better, for instance, it is building its onw > security. If the upper layer truly knew better, it wouldn't be using TCP. Or, you might be saying, the upper layer is TLS. In which case the developers are going to be really annoyed by the dual layers basically duplicating the same thing (if tcp-crypt is any guide) and is thus shear waste. But the users won't know any different? And why can't the developers spend that time turning it off (with uncertain knowledge of whether the implementation is even there) by instead working with the TCP-crypt layer instead of against it? > If we dont provide this hook, then it is always encrypted if both ends > support and there is nothing the upper layer can do in order to avoid it. Yes. But what is the problem with that? Obviously performance spring to mind, but many claim that is no longer an issue. Without getting dragged into mindless academic foodfights about citations, the point is here that performance isn't the reason it was in 1994, when they broke HTTPS and put half the website in the clear. I can't recall the last time I had to tweak SSH to use a faster cipher for huge backups, it was probably late 1990s. Latency could be an issue with say TLS over TCP-crypt over TCP-startup. Secondly, you bring up dual security. Now, the nature of security is that a security layer cannot interfere with the data being transported, and indeed that's reflected in the charter. So it is not as if there are going to be artifacts of interference in a proper implementation. Finally, it might be worth noting that it is a general NSA recommendation that systems should be dual-encrypted where the systems are sufficiently independent of each other. e.g., IPSec at the point-to-point and PGP or SSH above that. FWIW. Point being, there is no clear MUST nor SHOULD here, this again is a property that can and will emerge from the experimentation. > Please also note that this does not allow for the peer to downgrade the > connection or terminate encryption, as this has no impact in the wire, > it is only at the begining of the connection. > > Does this clarify things? What do you think? > > That being said, I am perfectly fine with removing it from the charter. That's what is being asked. iang From nobody Mon Apr 28 05:17:02 2014 Return-Path: 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 4F5DF1A073E for ; Mon, 28 Apr 2014 05:17:00 -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 TlFASxTpHGGy for ; Mon, 28 Apr 2014 05:16:57 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id EB7FD1A070F for ; Mon, 28 Apr 2014 05:16:56 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3D05DCC808E for ; Mon, 28 Apr 2014 14:16:55 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.85.124] (unknown [163.117.85.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 2E666B47E1D for ; Mon, 28 Apr 2014 14:16:55 +0200 (CEST) Message-ID: <535E46B6.60508@it.uc3m.es> Date: Mon, 28 Apr 2014 14:16:54 +0200 From: marcelo bagnulo braun 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> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D76BC.4060007@cs.tcd.ie> <535DE7C6.80902@it.uc3m.es> <535E308D.2090609@iang.org> In-Reply-To: <535E308D.2090609@iang.org> 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-20660.007 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/a_sLkL8ms1UYYygVwzFvilZu1U0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:17:00 -0000 ok, given that we are talking about the same thing, i guess it is clear that there is no clear consensus to keep this in, so i will remove it from the charter and leave it for WG discussion El 28/04/14 12:42, ianG escribió: > On 28/04/2014 06:31 am, marcelo bagnulo braun wrote: >> El 27/04/14 23:29, Stephen Farrell escribió: >>> Hi Marcelo, >>> >>> On 27/04/14 21:43, marcelo bagnulo braun wrote: >>>> - Hooks for allowing upper layers to disable encryption must be made >>>> available. >>>> The protocol may try to avoid redundant encryption when it is >>>> possible >>>> e.g. >>>> by detecting encryption performed by upper layers (notably, when TLS >>>> is used). >>> Based on all the discussion on this so far, I'd also suggest >>> deleting this bit. I agree with Ian that the reasons for >>> including this stated so far are arm-wavy. And "detecting" >>> that higher layers are encrypting vs. compressing seems unlikely >>> in the general case too. If something is using TLS then the >>> TLS code (which normally calls the socket API I think) can >>> presumably determine if TCP Inc. would be on by default and >>> do the right thing so there's no need for TCP Inc. to do >>> anything for that case even if someone concludes that double >>> wrapping isn't what they want. >>> >>> So count me as another -1 on inclusion of the above. >> mmm, I guess i misread the previous discussion or i didnt managed to >> explain what i had in mind. >> >> Let me try to explain myself (not trying to push for this, just want to >> clarify). >> >> What i had in mind was _not_ about allowing the upper layer to disable >> the encryption in the middle of a connection. > Well, yes, I don't think anyone had that in mind. > >> What i had in mind was to allow the upper layer to say: "please for this >> connection, dont use TCP-INC, just use plain old TCP". > This is understood. I believe this will exist in implementations, > regardless, for development purposes. I also believe the smart > implementors will realise they don't need it, and nor do their users, > and that they will solve some problems by getting rid of it (which > realisation will also infect thinking about ciphersuites). > >> This is because >> the upperlayer may knwo better, for instance, it is building its onw >> security. > > If the upper layer truly knew better, it wouldn't be using TCP. > > Or, you might be saying, the upper layer is TLS. In which case the > developers are going to be really annoyed by the dual layers basically > duplicating the same thing (if tcp-crypt is any guide) and is thus shear > waste. But the users won't know any different? > > And why can't the developers spend that time turning it off (with > uncertain knowledge of whether the implementation is even there) by > instead working with the TCP-crypt layer instead of against it? > > >> If we dont provide this hook, then it is always encrypted if both ends >> support and there is nothing the upper layer can do in order to avoid it. > > Yes. But what is the problem with that? > > Obviously performance spring to mind, but many claim that is no longer > an issue. Without getting dragged into mindless academic foodfights > about citations, the point is here that performance isn't the reason it > was in 1994, when they broke HTTPS and put half the website in the > clear. I can't recall the last time I had to tweak SSH to use a faster > cipher for huge backups, it was probably late 1990s. > > Latency could be an issue with say TLS over TCP-crypt over TCP-startup. > > Secondly, you bring up dual security. Now, the nature of security is > that a security layer cannot interfere with the data being transported, > and indeed that's reflected in the charter. So it is not as if there > are going to be artifacts of interference in a proper implementation. > > Finally, it might be worth noting that it is a general NSA > recommendation that systems should be dual-encrypted where the systems > are sufficiently independent of each other. e.g., IPSec at the > point-to-point and PGP or SSH above that. FWIW. > > Point being, there is no clear MUST nor SHOULD here, this again is a > property that can and will emerge from the experimentation. > > >> Please also note that this does not allow for the peer to downgrade the >> connection or terminate encryption, as this has no impact in the wire, >> it is only at the begining of the connection. >> >> Does this clarify things? What do you think? >> >> That being said, I am perfectly fine with removing it from the charter. > > That's what is being asked. > > > > iang > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Mon Apr 28 05:30:30 2014 Return-Path: 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 C3D211A09A9 for ; Mon, 28 Apr 2014 05:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 gC5KJBKUr84V for ; Mon, 28 Apr 2014 05:30:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 369EE1A0710 for ; Mon, 28 Apr 2014 05:30:25 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3SCUCQa026664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Apr 2014 15:30:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3SCUBpA019151; Mon, 28 Apr 2014 15:30:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21342.18899.736731.804370@fireball.kivinen.iki.fi> Date: Mon, 28 Apr 2014 15:30:11 +0300 From: Tero Kivinen To: John-Mark Gurney In-Reply-To: <20140424155532.GR43976@funkthat.com> References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/v2T2nFsv3VpeGT7Y6S7n7m8aE2Q Cc: Wesley Eddy , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:30:29 -0000 John-Mark Gurney writes: > The goal is to make it very easy for everyone to deploy... Configuring > IPSEC is a pain, and as Joe mentions, most implementations don't handle > key roll over properly (even though apparently, you're allowed to keep > both the old key and the new key around for the transition period to > handle this case)... Of course there can be buggy IPsec implementations which do not follow the rules set in the RFCs and which loose some packets when doing rekeying, but same applies to any protocol. The current IPsec specifications (IKEv2, RFC5996) do specify how rekey happens and it is specified so that no packets are lost: i.e. first create new Child SA proactively, i.e. before the old Child SA expires; then wait for traffic to move to this new SA (i.e. when you see packets on new Child SA, you know that other end has installed it); and only then remove old Child SA. See section 2.8 of RFC 5996. In the IKEv1 (from 1998, obsoleted in 2005) the rekeying was not specified properly and there quite often was problems with implementations which caused them to loose some packets while rekeying. Usually those old implementations did work properly against themselves, but when talking to someone else which implemented things differently they might have lost few packets. -- kivinen@iki.fi From nobody Mon Apr 28 08:21:45 2014 Return-Path: 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 876B51A04C5 for ; Mon, 28 Apr 2014 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 tCY3eNiD1Pny for ; Mon, 28 Apr 2014 08:21:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 661E01A01DF for ; Mon, 28 Apr 2014 08:21:41 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3SFL5Yw025554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Apr 2014 08:21:15 -0700 (PDT) Message-ID: <535E71E8.6020001@isi.edu> Date: Mon, 28 Apr 2014 08:21:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tero Kivinen , John-Mark Gurney References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> <21342.18899.736731.804370@fireball.kivinen.iki.fi> In-Reply-To: <21342.18899.736731.804370@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/no7pXT3TwROHQJzyfhZZMw7QCI4 Cc: Wesley Eddy , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:21:42 -0000 On 4/28/2014 5:30 AM, Tero Kivinen wrote: > John-Mark Gurney writes: >> The goal is to make it very easy for everyone to deploy... Configuring >> IPSEC is a pain, and as Joe mentions, most implementations don't handle >> key roll over properly (even though apparently, you're allowed to keep >> both the old key and the new key around for the transition period to >> handle this case)... > > Of course there can be buggy IPsec implementations which do not follow > the rules set in the RFCs and which loose some packets when doing > rekeying, but same applies to any protocol. > > The current IPsec specifications (IKEv2, RFC5996) do specify how rekey > happens and it is specified so that no packets are lost: i.e. first > create new Child SA proactively, i.e. before the old Child SA expires; > then wait for traffic to move to this new SA (i.e. when you see > packets on new Child SA, you know that other end has installed it); > and only then remove old Child SA. You can't ensure that no packets are lost that way. Once you transition to a new SA - even if you coordinate that handoff - there may be out-of-order packets that arrive after that coordination. Those packets would be dropped, and presumably TCP would retransmit them using the new SA, but the receiver would still see a gap in received packets that might affect its congestion control. TCP is the only one who can know when there is no outstanding gap after a key change, and thus when it can remove an old key without impact to its congestion control. Joe From nobody Mon Apr 28 11:35:03 2014 Return-Path: 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 767411A0792 for ; Mon, 28 Apr 2014 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 ZzggFmjbTv_o for ; Mon, 28 Apr 2014 11:34:58 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id B00E71A04F1 for ; Mon, 28 Apr 2014 11:34:58 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s3SIYgW6031822; Mon, 28 Apr 2014 11:34:47 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1khmr89wf6-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Apr 2014 11:34:46 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 28 Apr 2014 11:34:46 -0700 From: Paul Lambert To: Stephen Farrell , Chris Palmer , ianG Date: Mon, 28 Apr 2014 11:35:48 -0700 Thread-Topic: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) Thread-Index: Ac9jEIdXMO5iHfi7RKOvTOIypnfZjw== Message-ID: References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> In-Reply-To: <535AD44A.2000603@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-28_03:2014-04-28,2014-04-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404280289 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/WvIkzzEL9x_zbHvE_jkNgormCOY Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:35:01 -0000 On 4/25/14, 2:31 PM, "Stephen Farrell" wrote: > > >On 04/25/2014 01:59 AM, Chris Palmer wrote: >> On Thu, Apr 24, 2014 at 5:15 PM, ianG wrote: >>=20 >>>> You are the one claiming that this compromises the security of the >>>> protocol. >>> >>> Count me in ;) >>=20 >> I'm pretty sure every practicing security engineer worth her cybers >> knows from experience that (a) complexity is bad; (b) we already have >> unencrypted TCP; and (c) the performance argument is either a red >> herring or better answered with "Well, you can always use... TCP." > >I agree about the complexity argument and that's why I'd lean >against NULL cipher features myself. Not the strongest argument >because its fairly abstract but simpler really is much better >and is also something where we (the IETF and IETF security folk) >need to do better IMO. A NULL cipher is a bad idea. At the top level of our requirements we should be considering the service interface we are providing. When connected - Tcpcrypt should be encrypting. The service Interface should also provide clarity on the nature of the peer system.=20 NULL cipher breaks this simple model of a security layer. It prevents the creation of clear cryptographic/trust boundaries in a protocol architecture. Paul=20 > >Apart from that, I don't think there's real history of accidental >use of such or real downgrade attacks to such. At least afaik. If >there were that'd be a very strong argument against. > >All that said, I don't think this needs to be decided right now >and nor do I think we're in a position where we could make a >sensible yes/no decision on this topic now, before we have more >detail of TCP Inc. (great name btw:-) figured out. > >>> Sixthly, people are pissed. They don't want another kitchen sink. >>>This >>> might be the last chance IETF WGs have to make a showing in this field, >>> there are already serious competitors looking to sweep the whole lot >>> away, and they know the IETF isn't the right forum for security >>> protocols. Fixing TCP to go opportunistic isn't going to hold them >>>back >>> for long, but if it presents an alphabet soup of options, it'll just >>> make the job soooo much easier [0]. >>=20 >> I'm sorry, Joe, but ianG is 200% right. > >IMO ianG is quite wrong there but it doesn't matter since that's >commentary that has no direct impact on what we're trying to do >here. There are plenty of other lists for such discussion. > >S. > >>=20 >> _______________________________________________ >> Tcpcrypt mailing list >> Tcpcrypt@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpcrypt >>=20 > >_______________________________________________ >Tcpcrypt mailing list >Tcpcrypt@ietf.org >https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Mon Apr 28 14:00:23 2014 Return-Path: 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 4E4F61A6FBB for ; Mon, 28 Apr 2014 14:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 2NChwBZJfKVv for ; Mon, 28 Apr 2014 14:00:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 56F1A1A6FB9 for ; Mon, 28 Apr 2014 14:00:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 748BC21198 for ; Mon, 28 Apr 2014 17:00:19 -0400 (EDT) Received: from betaweb1 ([10.202.2.10]) by compute6.internal (MEProxy); Mon, 28 Apr 2014 17:00:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:reply-to:date:in-reply-to:references; s= mesmtp; bh=fEjJ5vFejttaUHBTMcTqCD3aQsY=; b=GorA1SYZMYcwRHcBKgFu6 QkVVeIXJWe+53ngs2TQzXTJmyfEb1yHcZo5z+CkAEiITBODsDJJ43dwD2LTc+r2Y L0AQOWJXyJctMw1KOl11t/zupJEx9VPk25rjmPg9/L29hqCuvohO3iE9WHkCSU6Q zKPI94cE/u0akXHCWlJK8Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=fEjJ5vFejttaUHBTMcTqCD3aQ sY=; b=lP5+v06Lee1EpEV3VpLQ3rQvW9+vT7zJZ1LzDCYMDrDmp0pndr5lzGuz9 eJhKcfQbzdzlud/quGjSgHayWbX6ROVkqIskUOLR/09oqsW69uyO/pv1UfxgScW2 MIME8k6ajIBA6vzUiz30l67hOBRBzcIopQS5BNp2AGIViKiyIc= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 47BF7740065; Mon, 28 Apr 2014 17:00:19 -0400 (EDT) Message-Id: <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> X-Sasl-Enc: OLzfEszyImJxoo5Xru/BNHW/JNhosCAWS7n0y1a0Tfz0 1398718819 From: Alfie John To: tcpcrypt@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Tue, 29 Apr 2014 07:00:19 +1000 In-Reply-To: <535AD44A.2000603@cs.tcd.ie> References: <533C33D2.4060004@it.uc3m.es> <53583CB2.3050604@isi.edu> <1398295705.19297.109724297.0F21007A@webmail.messagingengine.com> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/BV68A2qlQbedGCl6YLKEWRNhFI4 Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:00:22 -0000 On Sat, Apr 26, 2014, at 07:31 AM, Stephen Farrell wrote: > I agree about the complexity argument and that's why I'd lean > against NULL cipher features myself. Not the strongest argument > because its fairly abstract but simpler really is much better > and is also something where we (the IETF and IETF security folk) > need to do better IMO. > > Apart from that, I don't think there's real history of accidental > use of such or real downgrade attacks to such. At least afaik. If > there were that'd be a very strong argument against. Here is an example of a NULL cipher option downgrade attack that many people around the world are vulnerable to everyday - STARTTLS. All it takes is a MITM to not pass through the STARTTLS command, and now the connection is in plaintext and the emperor has no clothes. Remember, unless you can verify every bit that goes down that pipe, it may not be you that turns the cipher flag to NULL! Alfie -- Alfie John alfiej@fastmail.fm From nobody Mon Apr 28 14:35:24 2014 Return-Path: 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 5627C1A882A for ; Mon, 28 Apr 2014 14:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 JVTWeUqwRugq for ; Mon, 28 Apr 2014 14:35:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8A00F1A8034 for ; Mon, 28 Apr 2014 14:35:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D70FBBEB2; Mon, 28 Apr 2014 22:35:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq2Ug38Bf6xK; Mon, 28 Apr 2014 22:35:17 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.68.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80417BEB0; Mon, 28 Apr 2014 22:35:17 +0100 (IST) Message-ID: <535EC995.9090000@cs.tcd.ie> Date: Mon, 28 Apr 2014 22:35:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: alfiej@fastmail.fm, tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> In-Reply-To: <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/iXmS7FOsi2xKvcBdSGX857AhFvA Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:35:23 -0000 On 28/04/14 22:00, Alfie John wrote: > Here is an example of a NULL cipher option downgrade attack that many > people around the world are vulnerable to everyday - STARTTLS. All it > takes is a MITM to not pass through the STARTTLS command, and now the > connection is in plaintext and the emperor has no clothes. I wouldn't call that a NULL cipher problem TBH. For TLS, the kind of problem I meant would be negotiating e.g. TLS_RSA_WITH_NULL_SHA256 or one of the other similar ciphersuites from [1]. Again - its not really relevant here (yet), but if we knew of a real case that'd be interesting (and a nail in the coffin for adding more such). Cheers, S. [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 From nobody Mon Apr 28 21:55:04 2014 Return-Path: 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 C0B471A08AD for ; Mon, 28 Apr 2014 21:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 eRc4IenCeP6B for ; Mon, 28 Apr 2014 21:55:00 -0700 (PDT) Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) by ietfa.amsl.com (Postfix) with ESMTP id E2BF81A02E3 for ; Mon, 28 Apr 2014 21:54:58 -0700 (PDT) Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id s3SMK7E9027043; Mon, 28 Apr 2014 15:20:07 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3SMK6wT006585; Mon, 28 Apr 2014 15:20:06 -0700 (PDT) X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f From: David Mazieres To: Stephen Farrell , alfiej@fastmail.fm, tcpcrypt@ietf.org In-Reply-To: <535EC995.9090000@cs.tcd.ie> References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> Date: Tue, 29 Apr 2014 00:20:04 +0200 Message-ID: <878uqpqep7.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/kgOyCPrNgBJBQhBqXN963DO4pIw Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Mazieres expires 2014-07-28 CEST List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 04:55:01 -0000 Stephen Farrell writes: > Again - its not really relevant here (yet), but if we knew of a real > case that'd be interesting (and a nail in the coffin for adding > more such). I don't understand why we are having this discussion. Forward secrecy must be an absolute requirement of TCP Inc. A NULL cipher does not provide forward secrecy. So end of story, right? Of course, we have to prepare for the case that some cipher like AES is someday no longer secure. That means kind of ciphersuite negotiation is necessary. But should any cipher suite later be deemed insecure, implementations will have to disable it. David From nobody Tue Apr 29 03:55:09 2014 Return-Path: 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 DC57C1A07CA for ; Tue, 29 Apr 2014 03:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8SsSwNQX1VWD for ; Tue, 29 Apr 2014 03:55:06 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA521A0821 for ; Tue, 29 Apr 2014 03:55:05 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 7B0BD6D566; Tue, 29 Apr 2014 06:55:02 -0400 (EDT) Message-ID: <535F8500.9040505@iang.org> Date: Tue, 29 Apr 2014 11:54:56 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> <878uqpqep7.fsf@ta.scs.stanford.edu> In-Reply-To: <878uqpqep7.fsf@ta.scs.stanford.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1Oc3RIlNMxpEKoIUa0gLbfKbK1I Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 10:55:08 -0000 On 28/04/2014 23:20 pm, David Mazieres wrote: > Stephen Farrell writes: > >> Again - its not really relevant here (yet), but if we knew of a real >> case that'd be interesting (and a nail in the coffin for adding >> more such). > > I don't understand why we are having this discussion. Forward secrecy > must be an absolute requirement of TCP Inc. A NULL cipher does not > provide forward secrecy. So end of story, right? Point. > Of course, we have to prepare for the case that some cipher like AES is > someday no longer secure. You've assumed AES ... not really the place in the charter. (I'd expect to see ChaCha20/Poly1305 at this stage in the experimental protocols aiming at charter, but I'd also expect that suite to be dropped for a CAESAR winner when it goes mainstream.) > That means kind of ciphersuite negotiation is > necessary. But should any cipher suite later be deemed insecure, > implementations will have to disable it. When has that ever happened with a properly designed ciphersuite? In practice, what happens is the complexity opens up weaknesses and this might get fixed by switching to some ciphersuite. Or some old algorithm that should never have been there has finally permeated its anachronism into the dark cobwebs of some committee mind. Have a look at the history of TLS -- agility is a source of problems more than it is a solution to problems. If they'd spent the time on upgrade of the protocol instead of elegantly handling buckets of vanity suites to meet the fashion needs of developers, it would be a whole more secure. iang From nobody Tue Apr 29 05:02:52 2014 Return-Path: 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 367D91A08C3 for ; Tue, 29 Apr 2014 05:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 MWENWaE2FRlu for ; Tue, 29 Apr 2014 05:02:48 -0700 (PDT) Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C31A08C0 for ; Tue, 29 Apr 2014 05:02:48 -0700 (PDT) Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id s3TC2krA032235; Tue, 29 Apr 2014 05:02:46 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3TC2jGd017417; Tue, 29 Apr 2014 05:02:45 -0700 (PDT) X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f From: David Mazieres To: ianG , tcpcrypt@ietf.org In-Reply-To: <535F8500.9040505@iang.org> References: <533C33D2.4060004@it.uc3m.es> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> <878uqpqep7.fsf@ta.scs.stanford.edu> <535F8500.9040505@iang.org> Date: Tue, 29 Apr 2014 05:02:43 -0700 Message-ID: <87ha5cwdgc.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/LWVafoQ5dBTRPzWE2UHeX_qdQDw Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Mazieres expires 2014-07-28 PDT List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:02:50 -0000 ianG writes: >> Of course, we have to prepare for the case that some cipher like AES is >> someday no longer secure. > > > You've assumed AES ... not really the place in the charter. > > (I'd expect to see ChaCha20/Poly1305 at this stage in the experimental > protocols aiming at charter, but I'd also expect that suite to be > dropped for a CAESAR winner when it goes mainstream.) I haven't assumed AES. I said "like AES." But there's a point here, namely that there's a difference between the state of the art in symmetric crypto and what the IETF has standardized. For example, I would love the ability to use Poly1305 with TCP Inc. But there's no RFC for that, which is likely to cause problems. (By contrast, HMAC has RFC2014 and CMAC has RFC4493.) We certainly don't want to put TCP Inc. on hold until better MAC algorithms are standardized, but we also want to leave room for improving the algorithms later on. >> That means kind of ciphersuite negotiation is >> necessary. But should any cipher suite later be deemed insecure, >> implementations will have to disable it. > > When has that ever happened with a properly designed ciphersuite? In > practice, what happens is the complexity opens up weaknesses and this > might get fixed by switching to some ciphersuite. Or some old algorithm > that should never have been there has finally permeated its anachronism > into the dark cobwebs of some committee mind. Well, *improperly* designed ciphersuites have needed to be disabled (DES, RC4, etc.). But the point is that in the long run, all ciphersuites may be improperly designed. Moreover, crypto does get broken, and if that happens, you don't want to have to push new code out. It's much better just to have people disable an option and then remove it in the next implementation. If you don't have the ability to upgrade algorithms, you are arguably more likely to have entrenched anachronistic protocols persist. That said, the charter shouldn't over-specify. There needs to be a way to change crypto algorithms over time. Whether that looks like SSL's crypto agility or something coarser-grained should depend on what proposals look the best. > Have a look at the history of TLS -- agility is a source of problems > more than it is a solution to problems. If they'd spent the time on > upgrade of the protocol instead of elegantly handling buckets of vanity > suites to meet the fashion needs of developers, it would be a whole more > secure. Things have changed a lot about since SSL was invented. We now know a lot more about protocol design. Moreover, we don't have to deal with a lot of stuff SSL had to deal with (remember 40-bit keys?). David From nobody Tue Apr 29 09:26:08 2014 Return-Path: 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 0DFD61A0905 for ; Tue, 29 Apr 2014 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 JVZeRKPF1RZj for ; Tue, 29 Apr 2014 09:26:03 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36E1A08DB for ; Tue, 29 Apr 2014 09:26:03 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3TGPw43027378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 09:25:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3TGPw0M027377; Tue, 29 Apr 2014 09:25:58 -0700 (PDT) (envelope-from jmg) Date: Tue, 29 Apr 2014 09:25:58 -0700 From: John-Mark Gurney To: Alfie John Message-ID: <20140429162557.GD43976@funkthat.com> References: <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 29 Apr 2014 09:25:59 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/il3jLvsYL8VqWQ6_ctCu-ztOqBc Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:26:05 -0000 Alfie John wrote this message on Tue, Apr 29, 2014 at 07:00 +1000: > On Sat, Apr 26, 2014, at 07:31 AM, Stephen Farrell wrote: > > I agree about the complexity argument and that's why I'd lean > > against NULL cipher features myself. Not the strongest argument > > because its fairly abstract but simpler really is much better > > and is also something where we (the IETF and IETF security folk) > > need to do better IMO. > > > > Apart from that, I don't think there's real history of accidental > > use of such or real downgrade attacks to such. At least afaik. If > > there were that'd be a very strong argument against. > > Here is an example of a NULL cipher option downgrade attack that many > people around the world are vulnerable to everyday - STARTTLS. All it > takes is a MITM to not pass through the STARTTLS command, and now the > connection is in plaintext and the emperor has no clothes. > > Remember, unless you can verify every bit that goes down that pipe, it > may not be you that turns the cipher flag to NULL! Sadly, until all packets must be signed, they can just strip the TCP-Inc bit from the TCP packet, and the same thing will be achieved... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Apr 29 14:46:59 2014 Return-Path: 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 702201A0959 for ; Tue, 29 Apr 2014 14:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 fGLUiQBiHkOU for ; Tue, 29 Apr 2014 14:46:56 -0700 (PDT) Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) by ietfa.amsl.com (Postfix) with ESMTP id 340771A0953 for ; Tue, 29 Apr 2014 14:46:55 -0700 (PDT) Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id s3TLkoZ6020231; Tue, 29 Apr 2014 14:46:50 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3TLkmnQ019100; Tue, 29 Apr 2014 14:46:48 -0700 (PDT) X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f From: David Mazieres To: John-Mark Gurney , Alfie John In-Reply-To: <20140429162557.GD43976@funkthat.com> References: <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <20140429162557.GD43976@funkthat.com> Date: Tue, 29 Apr 2014 14:46:48 -0700 Message-ID: <87oazjvmev.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/mbc_wmSEYx9iwviZRtqEz71H3m4 Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] NULL cipher or not (was: Re: Asking for proof, but not reading the papers cited) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Mazieres expires 2014-07-28 PDT List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:46:57 -0000 John-Mark Gurney writes: > Sadly, until all packets must be signed, they can just strip the TCP-Inc > bit from the TCP packet, and the same thing will be achieved... This is why TCP Inc. needs simple hooks for authentication. As long as the hooks are there, down the line if the protocol becomes ubiquitous people can start requiring TCP Inc. for authenticated connections. So while we can't solve this problem over night, any TCP Inc. proposal should be compatible with solving the problem long-term after ubiquitous deployment. David From nobody Tue Apr 29 16:21:23 2014 Return-Path: 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 327DE1A0A02 for ; Tue, 29 Apr 2014 16:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 XPhsxa4fgzn3 for ; Tue, 29 Apr 2014 16:21:20 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5B1A09F9 for ; Tue, 29 Apr 2014 16:21:20 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s3TNLCXe012049; Tue, 29 Apr 2014 16:21:12 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1kjkkq8da3-10 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2014 16:21:12 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 29 Apr 2014 16:21:09 -0700 From: Paul Lambert To: David Mazieres expires 2014-07-28 CEST , Stephen Farrell , "alfiej@fastmail.fm" , "tcpcrypt@ietf.org" Date: Tue, 29 Apr 2014 16:22:14 -0700 Thread-Topic: [Tcpcrypt] NULL cipher or not Thread-Index: Ac9kAbO6P2OFx/kgTsGTw+Vvdu/zHQ== Message-ID: References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> <878uqpqep7.fsf@ta.scs.stanford.edu> In-Reply-To: <878uqpqep7.fsf@ta.scs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-29_06:2014-04-30,2014-04-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404290320 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/p_xF-YFc3ZwIMrLbBPXUZp3Z8Io Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:21:22 -0000 On 4/28/14, 3:20 PM, "David Mazieres" wrote: >Stephen Farrell writes: > >> Again - its not really relevant here (yet), but if we knew of a real >> case that'd be interesting (and a nail in the coffin for adding >> more such). > >I don't understand why we are having this discussion. Forward secrecy >must be an absolute requirement of TCP Inc. A NULL cipher does not >provide forward secrecy. So end of story, right? > >Of course, we have to prepare for the case that some cipher like AES is >someday no longer secure. That means kind of ciphersuite negotiation is >necessary. But should any cipher suite later be deemed insecure, >implementations will have to disable it. This is unlikely. RC4 persists in implementations. Perhaps we should consider improvements in ciphers and protocol as the same class of upgrade. The default mandatory cipher suite could be tied to the protocol version. If for some reason the mandatory cipher needs to change, the version changes. If there is something broken in the protocol design, we fix it and increment the version. The version is somewhat visible to users and IT Departments and provides a more robust indicator of the capabilities than manually disabling specific features. Paul > >David > >_______________________________________________ >Tcpcrypt mailing list >Tcpcrypt@ietf.org >https://www.ietf.org/mailman/listinfo/tcpcrypt From nobody Tue Apr 29 16:48:07 2014 Return-Path: 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 07CB81A0953 for ; Tue, 29 Apr 2014 16:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6SGR50cWagfT for ; Tue, 29 Apr 2014 16:48:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id C43601A0948 for ; Tue, 29 Apr 2014 16:48:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 8CAA56D5F9; Tue, 29 Apr 2014 19:47:59 -0400 (EDT) Message-ID: <53603A2C.4050709@iang.org> Date: Wed, 30 Apr 2014 00:47:56 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <533C33D2.4060004@it.uc3m.es> <535888EC.2040608@isi.edu> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> <878uqpqep7.fsf@ta.scs.stanford.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/v3Py2rrXAr9l_3ruqOMNy0vAn-I Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:48:06 -0000 On 30/04/2014 00:22 am, Paul Lambert wrote: > > > On 4/28/14, 3:20 PM, "David Mazieres" > wrote: > >> Stephen Farrell writes: ... >> Of course, we have to prepare for the case that some cipher like AES is >> someday no longer secure. That means kind of ciphersuite negotiation is >> necessary. But should any cipher suite later be deemed insecure, >> implementations will have to disable it. > > This is unlikely. RC4 persists in implementations. Amazing, isn't it. > Perhaps we should consider improvements in ciphers and protocol as > the same class of upgrade. The default mandatory cipher suite > could be tied to the protocol version. If for some reason the > mandatory cipher needs to change, the version changes. If there > is something broken in the protocol design, we fix it and increment > the version. The version is somewhat visible to users and IT > Departments and provides a more robust indicator of the capabilities > than manually disabling specific features. Thank you! iang From nobody Tue Apr 29 22:55:44 2014 Return-Path: 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 80D751A09DF for ; Tue, 29 Apr 2014 22:55:36 -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 N0FSHFXqlgU0 for ; Tue, 29 Apr 2014 22:55:32 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id D14CB1A09C5 for ; Tue, 29 Apr 2014 22:55:31 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 37D01894792 for ; Wed, 30 Apr 2014 07:55:29 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from dummyhost11.it.uc3m.es (dummyhost11.it.uc3m.es [163.117.139.231]) (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 2B19F767DA6 for ; Wed, 30 Apr 2014 07:55:29 +0200 (CEST) Message-ID: <53609051.3030904@it.uc3m.es> Date: Wed, 30 Apr 2014 07:55:29 +0200 From: marcelo bagnulo braun 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: <533C33D2.4060004@it.uc3m.es> <53588ACA.3060406@isi.edu> <53588CAA.7000101@isi.edu> <5358A053.3050606@isi.edu> <5358AAAF.2040502@isi.edu> <53596556.1070009@isi.edu> <53598F9C.9020501@isi.edu> <535999A3.1090808@isi.edu> <5359A92E.4060606@iang.org> <535AD44A.2000603@cs.tcd.ie> <1398718819.27010.111404609.67CEC668@webmail.messagingengine.com> <535EC995.9090000@cs.tcd.ie> <878uqpqep7.fsf@ta.scs.stanford.edu> <535F8500.9040505@iang.org> <87ha5cwdgc.fsf@ta.scs.stanford.edu> In-Reply-To: <87ha5cwdgc.fsf@ta.scs.stanford.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-20664.005 X-TM-AS-Result: No--7.200-7.0-31-1 X-imss-scan-details: No--7.200-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bboU0HuK0gwRlShh3RdYwgI8gTM Subject: Re: [Tcpcrypt] NULL cipher or not X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 05:55:37 -0000 El 29/04/14 14:02, David Mazieres escribió: > That said, the charter shouldn't over-specify. There needs to be a way > to change crypto algorithms over time. Whether that looks like SSL's > crypto agility or something coarser-grained should depend on what > proposals look the best. Right, crypto agility must be required, i will add it to the charter >> Have a look at the history of TLS -- agility is a source of problems >> more than it is a solution to problems. If they'd spent the time on >> upgrade of the protocol instead of elegantly handling buckets of vanity >> suites to meet the fashion needs of developers, it would be a whole more >> secure. > Things have changed a lot about since SSL was invented. We now know a > lot more about protocol design. Moreover, we don't have to deal with a > lot of stuff SSL had to deal with (remember 40-bit keys?). > > David > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Tue Apr 29 23:35:21 2014 Return-Path: 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 A336D1A6EE2 for ; Tue, 29 Apr 2014 23:35:18 -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 9ah_qPCJoIO6 for ; Tue, 29 Apr 2014 23:35:14 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B68BF1A6EE0 for ; Tue, 29 Apr 2014 23:35:13 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7395CCD3DE6 for ; Wed, 30 Apr 2014 08:35:11 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from dummyhost11.it.uc3m.es (unknown [163.117.139.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 687A1CC5E82 for ; Wed, 30 Apr 2014 08:35:11 +0200 (CEST) Message-ID: <536099A0.30900@it.uc3m.es> Date: Wed, 30 Apr 2014 08:35:12 +0200 From: marcelo bagnulo braun 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20664.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/C3MLGRTk1SVfaWrX4s8SloD05AE Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 06:35:19 -0000 Hi, I have tried to incorporate the comments received. This resulted in quite a bit of changes, so, i would appreciate feedback (for example, feedback like "the charter looks great and is ready to go" would be nice, but if you have other feedback it will be welcome as well). TCP Increased Security (TCP Inc.) The TCP Inc. WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define an unauthenticated key exchange mechanism. In addition, the WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man-in-the-middle attacks. This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring (see draft-farrell-perpass-attack). The goal of this WG is to provide an additional security tool that complements existing protocols at other layers in the stack. The WG will be looking for the designs that find the right tradeoff spot between conflicting requirements: to provide reasonable security for the majority of connections. Because we are dealing with unprotected connections, we are more focussed on improving from baseline of no security than achieving the high standard of security that is already available to users of TLS. Providing unauthenticated encryption and integrity protection at the TCP layer will provide a set of features that cannot be achieved with existing tools, namely, encryption and integrity protection without modifications to the upper ayers (no API changes), encryption and integrity protection with forward secrecy with a per-connection granularity, simple NAT and firewall traversal capabilities, key rollover without significant impact to the TCP connection, lower overhead compared to solutions relying in stacking multiple protocols to achieve different features, no manual configuration required. A more detailed description of the motivations for TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925. The working group is looking to produce experimental documents specifying the required TCP extensions and any additional documents needed. The high-level requirements for the protocol for providing TCP unauthenticated encryption and integrity protection are: - Deployable and usable without significant changes to existing Internet infrastructure, in particular it must be compatible with NATs (at the very minimum with the NATs that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508); - The protocol must be usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be changed in a backward compatible way. It also provides some protection in scenarios where people are unwilling to do any change just for the sake of security (e.g., like configure encryption in an application). - The protocol must provide cryptographic algorithm agility. - Must gracefully fall-back to TCP if the remote peer does not support the proposed extensions - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Should attempt to use the least amount of TCP option space, especially in SYN segments. - Must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance. For example, the protocol may try to re-use existing cryptographic material for future communication between the same endpoints to avoid expensive public key operations on connection set up. When encryption is enabled, then the protocol: - must always provide forward secrecy. - must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or not be protected) - must always provide payload encryption. - must not provide extra linkability. When encryption is enabled the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same client when connecting to a remote peer on subsequent occasions. This should either be the default (clients cannot be "fingerprinted" by the server based on shared state) or some mechanism should be available for clients to drop or ignore shared state to avoid being fingerprintable any more than would be present for a cleartext session. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for unauthenticated encryption and integrity protection of TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with external authentication mechanisms, the expected protection, privacy considerations and residual threats. - Definition of the unauthenticated key exchange mechanism and the extensions to current TCP to utilize unauthenticated key to provide encryption and integrity protection. This covers all the protocol changes required. This will be an experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting external authentication will be defined in this document. This will be an informational document. From nobody Wed Apr 30 01:20:49 2014 Return-Path: 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 AB1051A6F14 for ; Wed, 30 Apr 2014 01:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 M_HFrpvr9V3o for ; Wed, 30 Apr 2014 01:20:12 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0D1A6F11 for ; Wed, 30 Apr 2014 01:20:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,956,1389772800"; d="asc'?scan'208";a="161229411" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 30 Apr 2014 01:20:11 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 01:20:11 -0700 From: "Eggert, Lars" To: Marcelo Bagnulo Thread-Topic: [Tcpcrypt] v3 of the charter Thread-Index: AQHPZD5fGlguXnvFmU2xabuFLE2C2ZsqRtmA Date: Wed, 30 Apr 2014 08:20:10 +0000 Message-ID: <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> References: <536099A0.30900@it.uc3m.es> In-Reply-To: <536099A0.30900@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.27] Content-Type: multipart/signed; boundary="Apple-Mail=_03F8A87B-82F2-4DB0-BC95-3CEC311C2D58"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/UDLjOF-Tul9PbbQoOwAt-eXK-1k Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:20:18 -0000 --Apple-Mail=_03F8A87B-82F2-4DB0-BC95-3CEC311C2D58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, a few comments. This is looking good overall. On 2014-4-30, at 8:35, marcelo bagnulo braun wrote: > TCP Increased Security (TCP Inc.) am not in love with the name, but don't want to start a bikeshed. > This is better than plain-text > because it thwarts passive eavesdropping, but is weaker than using > authenticated keys, because it is vulnerable to man-in-the-middle = attacks. Is it desirable to have a model where you're vulnerable to MiM the first = time you connect to a server, but not afterwards? (Like what SSH = provides in terms of warning when the server key has changed?) > - Deployable and usable without significant changes to existing = Internet > infrastructure, in particular it must be compatible with NATs (at the > very minimum with the NATs that comply with BEHAVE requirements as = documented > in RFC4787, RFC5382 and RFC5508); What does "insignificant" mean here? I don't think we can require any = changes to the current infrastructure. > - The protocol must have acceptable performance. For example, the = protocol may > try to re-use existing cryptographic material for future = communication between the > same endpoints to avoid expensive public key operations on connection = set up. There are two aspects to performance that this paragraph mixes together. = One is latency, the other processing overhead. Reusing crypto material = from previous instances may help with reducing latency overheads. But = processing overhead matters, too. Servers wont be able to offload TCP = Inc. (at least initially), and clients w/o crypto hardware acceleration = of some sort will need to burn cycles (=3D battery). I don't want to = compromise security (or latency) for reducing processing overheads, but = we should be mindful of it. > - must allow client to avoid fingerprinting: some clients may want to = avoid appearing as the same > client when connecting to a remote peer on subsequent occasions. = This should either > be the default (clients cannot be "fingerprinted" by the server based = on shared state) > or some mechanism should be available for clients to drop or ignore = shared state to avoid > being fingerprintable any more than would be present for a cleartext = session. Not sure if this achievable if you can already fingerprint clients based = on existing IP and TCP header fields. As I said, none of these are major. Lars --Apple-Mail=_03F8A87B-82F2-4DB0-BC95-3CEC311C2D58 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU2CyONZcnpRveo1xAQKhMwP8CC8ojMzQFM3qjdEjqXMeeJyezlO/5s54 ezOieHHPNr+GJb3h3iRSZhnOqXu38LBkpNPqi7RgsW5MqaI6oAyhkPsPQ4gFf310 vJQ4K2lUv8d0unJNRppayJcu1+1c5Gd4UkXkgQWPQAbx0zRyhOnEQTFk2J5YBEvH ol8/6GM0Un4= =Xf6F -----END PGP SIGNATURE----- --Apple-Mail=_03F8A87B-82F2-4DB0-BC95-3CEC311C2D58-- From nobody Wed Apr 30 01:28:22 2014 Return-Path: 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 3D7881A6F1F for ; Wed, 30 Apr 2014 01:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 sIrTGPPdQfYg for ; Wed, 30 Apr 2014 01:27:56 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B9B671A6F14 for ; Wed, 30 Apr 2014 01:27:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,956,1389772800"; d="asc'?scan'208";a="161230398" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 30 Apr 2014 01:27:55 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 01:27:55 -0700 From: "Eggert, Lars" To: Marcelo Bagnulo Thread-Topic: [Tcpcrypt] v3 of the charter Thread-Index: AQHPZD5fGlguXnvFmU2xabuFLE2C2ZsqRtmAgAACKYA= Date: Wed, 30 Apr 2014 08:27:54 +0000 Message-ID: <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> In-Reply-To: <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.11] Content-Type: multipart/signed; boundary="Apple-Mail=_E6EE952E-96A5-4007-B907-7589A4EEDCAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/NyxiKgZod8vllNxkRnJboYLakoY Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:28:00 -0000 --Apple-Mail=_E6EE952E-96A5-4007-B907-7589A4EEDCAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Oh, forgot one more overall issue: The charter talks about clients and = servers a lot. While that's convenient, because it matches the = communication flow of the app layer protocols on top of TCP, and NATs = now demand a directionality of connection establishment, those terms = don't actually have a lot of meaning for TCP, which is a bidirectional = protocol. Suggest to rephrase. Lars --Apple-Mail=_E6EE952E-96A5-4007-B907-7589A4EEDCAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU2C0B9ZcnpRveo1xAQJPmQP+MWEA7tza3ML6ZAA3KXRoDW9wlkaV+srE g6sQ+lWAM226Pv//TBdTobMt4n72wGfrt8pirQA+2mNCRZzwB6eDu3rVAwaAXkLv GaoeApIwbRzmFhSczS9mdZCq/zXdNDvL2jyZ3oEtQd4Aj9KuWFFvYg48JNk7NzcY XspT8fcCNu8= =EaVq -----END PGP SIGNATURE----- --Apple-Mail=_E6EE952E-96A5-4007-B907-7589A4EEDCAA-- From nobody Wed Apr 30 01:31:04 2014 Return-Path: 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 438B51A6F1A for ; Wed, 30 Apr 2014 01:30:53 -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 JzR8tX0-DIEK for ; Wed, 30 Apr 2014 01:30:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id DA6B61A0774 for ; Wed, 30 Apr 2014 01:30:42 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B8EDDCD6A18; Wed, 30 Apr 2014 10:30:40 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from dummyhost11.it.uc3m.es (unknown [163.117.139.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id AC407C32C7E; Wed, 30 Apr 2014 10:30:40 +0200 (CEST) Message-ID: <5360B4B1.90106@it.uc3m.es> Date: Wed, 30 Apr 2014 10:30:41 +0200 From: marcelo bagnulo braun 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: "Eggert, Lars" References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> In-Reply-To: <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> 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-20664.005 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/9YoNWZt6y5Xr2w38s1LtZBSOXok Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:30:53 -0000 El 30/04/14 10:20, Eggert, Lars escribió: > Hi, > > a few comments. This is looking good overall. > > On 2014-4-30, at 8:35, marcelo bagnulo braun wrote: >> TCP Increased Security (TCP Inc.) > am not in love with the name, but don't want to start a bikeshed. > >> This is better than plain-text >> because it thwarts passive eavesdropping, but is weaker than using >> authenticated keys, because it is vulnerable to man-in-the-middle attacks. > Is it desirable to have a model where you're vulnerable to MiM the first time you connect to a server, but not afterwards? (Like what SSH provides in terms of warning when the server key has changed?) right, i will rephrase it as "vulnerable to mitm attacks during the initial unathenticated key exchange" >> - Deployable and usable without significant changes to existing Internet >> infrastructure, in particular it must be compatible with NATs (at the >> very minimum with the NATs that comply with BEHAVE requirements as documented >> in RFC4787, RFC5382 and RFC5508); > What does "insignificant" mean here? I don't think we can require any changes to the current infrastructure. well, there are lost of different boxes out there that do very wierd things. I dont want people saying "there is a box that does foo and it is imcopatible with the proposed solution" and that being a blocking argument as per the charter, hence the significant, makes sense? >> - The protocol must have acceptable performance. For example, the protocol may >> try to re-use existing cryptographic material for future communication between the >> same endpoints to avoid expensive public key operations on connection set up. > There are two aspects to performance that this paragraph mixes together. One is latency, the other processing overhead. Reusing crypto material from previous instances may help with reducing latency overheads. But processing overhead matters, too. Servers wont be able to offload TCP Inc. (at least initially), and clients w/o crypto hardware acceleration of some sort will need to burn cycles (= battery). I don't want to compromise security (or latency) for reducing processing overheads, but we should be mindful of it. i agree, i am not sure if you want to relfect any of this in the charter and how >> - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same >> client when connecting to a remote peer on subsequent occasions. This should either >> be the default (clients cannot be "fingerprinted" by the server based on shared state) >> or some mechanism should be available for clients to drop or ignore shared state to avoid >> being fingerprintable any more than would be present for a cleartext session. > Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields. right, but see the last part of the last sentence (added by joe) This protocol must not do things worse, makes sense? Regards, marcelo > As I said, none of these are major. > > Lars From nobody Wed Apr 30 01:42:16 2014 Return-Path: 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 3455A1A6F1F for ; Wed, 30 Apr 2014 01:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 XkcJhBbMS8yy for ; Wed, 30 Apr 2014 01:41:29 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 196831A6F1A for ; Wed, 30 Apr 2014 01:41:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,957,1389772800"; d="asc'?scan'208";a="120084806" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 30 Apr 2014 01:41:27 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 01:41:28 -0700 From: "Eggert, Lars" To: Marcelo Bagnulo Thread-Topic: [Tcpcrypt] v3 of the charter Thread-Index: AQHPZD5fGlguXnvFmU2xabuFLE2C2ZsqRtmAgAAC9ICAAAL9gA== Date: Wed, 30 Apr 2014 08:41:26 +0000 Message-ID: <22212FB9-B128-4EE9-8549-54685A33E461@netapp.com> References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <5360B4B1.90106@it.uc3m.es> In-Reply-To: <5360B4B1.90106@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_B15DCA54-6928-4C89-9399-CC104A72F374"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zQXdr2Zw_0oZrtJmRX5gR5AfzEk Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:41:32 -0000 --Apple-Mail=_B15DCA54-6928-4C89-9399-CC104A72F374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2014-4-30, at 10:30, marcelo bagnulo braun = wrote: > well, there are lost of different boxes out there that do very wierd = things. > I dont want people saying "there is a box that does foo and it is = imcopatible with the proposed solution" and that being a blocking = argument as per the charter, hence the significant, makes sense? Understood. Then maybe rephrase as something like "TCP Inc. should work = over the vast majority of paths that unmodified TCP works over?" I.e., = just talk about the expected outcome. >>> - The protocol must have acceptable performance. For example, the = protocol may >>> try to re-use existing cryptographic material for future = communication between the >>> same endpoints to avoid expensive public key operations on = connection set up. >> There are two aspects to performance that this paragraph mixes = together. One is latency, the other processing overhead. Reusing crypto = material from previous instances may help with reducing latency = overheads. But processing overhead matters, too. Servers wont be able to = offload TCP Inc. (at least initially), and clients w/o crypto hardware = acceleration of some sort will need to burn cycles (=3D battery). I = don't want to compromise security (or latency) for reducing processing = overheads, but we should be mindful of it. >=20 > i agree, i am not sure if you want to relfect any of this in the = charter and how I just picked up on it, because latency is specifically called out but = processing overhead isn't. You could rephrase the first sentence as "The = protocol extension must have acceptable latency and processing = overheads." > - must allow client to avoid fingerprinting: some clients may want to = avoid appearing as the same >>> client when connecting to a remote peer on subsequent occasions. = This should either >>> be the default (clients cannot be "fingerprinted" by the server = based on shared state) >>> or some mechanism should be available for clients to drop or ignore = shared state to avoid >>> being fingerprintable any more than would be present for a = cleartext session. >> Not sure if this achievable if you can already fingerprint clients = based on existing IP and TCP header fields. >=20 > right, but see the last part of the last sentence (added by joe) This = protocol must not do things worse, makes sense? Makes sense. Suggest to express it this way, e.g., "the protocol = extension must not increase the possibility for endpoint fingerprinting = compared to what is possible already". Lars --Apple-Mail=_B15DCA54-6928-4C89-9399-CC104A72F374 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU2C3M9ZcnpRveo1xAQItGwP/TJhb3i2DdLpjKk9W5prKQzhfI0dAwSKs MdIWdnLwkl0xxtHEnax5nvj1tfZQT2YuMML0nj+PlsXqrZypYq0M5mfM5jRnOwkU jh2huqlJQSaqHkWumEg1aCEXRGaSJuE3Z4SfiQOvGBd+eEuSWIdj0IiTAPrOGLje VpbKv/hihKY= =P6Qs -----END PGP SIGNATURE----- --Apple-Mail=_B15DCA54-6928-4C89-9399-CC104A72F374-- From nobody Wed Apr 30 02:02:25 2014 Return-Path: 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 D3A601A08B0 for ; Wed, 30 Apr 2014 02:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 p6SXTV0TcftY for ; Wed, 30 Apr 2014 02:02:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2838B1A076B for ; Wed, 30 Apr 2014 02:02:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7F005BE68; Wed, 30 Apr 2014 10:02:05 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adfgfoEVD6eO; Wed, 30 Apr 2014 10:02:05 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 58A12BE58; Wed, 30 Apr 2014 10:02:05 +0100 (IST) Message-ID: <5360BC0C.3020303@cs.tcd.ie> Date: Wed, 30 Apr 2014 10:02:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Eggert, Lars" , Marcelo Bagnulo References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <5360B4B1.90106@it.uc3m.es> <22212FB9-B128-4EE9-8549-54685A33E461@netapp.com> In-Reply-To: <22212FB9-B128-4EE9-8549-54685A33E461@netapp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1spKi-f81CHQJcK52GUxZd1Y-E0 Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:02:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Overall I think this charter (modulo wordsmithing such as suggested by Lars) is good enough. My own nit, but not suggesting a change... On 30/04/14 09:41, Eggert, Lars wrote: > Makes sense. Suggest to express it this way, e.g., "the protocol > extension must not increase the possibility for endpoint > fingerprinting compared to what is possible already". I generally dislike when a security goal is set to be "no worse than today" since I think that's how we got e.g. WEP. But in this case (fingerprinting), I don't think we yet understand it well enough to do much better. It'd be good if we did though. So the text Lars suggests is ok. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTYLwGAAoJEC88hzaAX42iNwgIAL12XxhpMHfTiYM6Q3R7MFRA MYqFvEPqwwQe4dJNjjVrkNHYImFKAVtTrV2AB3+vGbr1eUJsC8sGOMsL2m7bgI1e nUzYUVz93gdQLiUcUP5fwtdfNyXdBIEK6RspfCghi0kSBO+wBZhz2wo669Mj0J5O 6YEx+iorX4Fcyz1PutNchOFCiMabWtd1devZb2QpK5lYzuEzixE/vPWqkwJisD0A TB5b7vAwxvSJtTxGKK//HASpVCORGsXOAOe8HcSm/UrRKvpqzIT+10vCeslwR//f I6V+Jdswo0t0okJK4SuxVjV56eT3Dc8pRAgoS4ptR1z+djtyD/veHz6O2s8pRm0= =Mw5p -----END PGP SIGNATURE----- From nobody Wed Apr 30 02:33:28 2014 Return-Path: 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 C30181A6F25 for ; Wed, 30 Apr 2014 02:33:25 -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 jiBn-ii8hcNa for ; Wed, 30 Apr 2014 02:33:22 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B42821A6F1F for ; Wed, 30 Apr 2014 02:33:22 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D65BCCD69EE; Wed, 30 Apr 2014 11:33:20 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from dummyhost11.it.uc3m.es (unknown [163.117.139.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id B5E49CD665C; Wed, 30 Apr 2014 11:33:20 +0200 (CEST) Message-ID: <5360C361.9060606@it.uc3m.es> Date: Wed, 30 Apr 2014 11:33:21 +0200 From: marcelo bagnulo braun 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: "Eggert, Lars" References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <5360B4B1.90106@it.uc3m.es> <22212FB9-B128-4EE9-8549-54685A33E461@netapp.com> In-Reply-To: <22212FB9-B128-4EE9-8549-54685A33E461@netapp.com> 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-20664.006 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/oLJfasAq7r34_Y3bbiP-rQqNiS4 Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:33:26 -0000 will do all these thanks El 30/04/14 10:41, Eggert, Lars escribió: > On 2014-4-30, at 10:30, marcelo bagnulo braun wrote: >> well, there are lost of different boxes out there that do very wierd things. >> I dont want people saying "there is a box that does foo and it is imcopatible with the proposed solution" and that being a blocking argument as per the charter, hence the significant, makes sense? > Understood. Then maybe rephrase as something like "TCP Inc. should work over the vast majority of paths that unmodified TCP works over?" I.e., just talk about the expected outcome. > >>>> - The protocol must have acceptable performance. For example, the protocol may >>>> try to re-use existing cryptographic material for future communication between the >>>> same endpoints to avoid expensive public key operations on connection set up. >>> There are two aspects to performance that this paragraph mixes together. One is latency, the other processing overhead. Reusing crypto material from previous instances may help with reducing latency overheads. But processing overhead matters, too. Servers wont be able to offload TCP Inc. (at least initially), and clients w/o crypto hardware acceleration of some sort will need to burn cycles (= battery). I don't want to compromise security (or latency) for reducing processing overheads, but we should be mindful of it. >> i agree, i am not sure if you want to relfect any of this in the charter and how > I just picked up on it, because latency is specifically called out but processing overhead isn't. You could rephrase the first sentence as "The protocol extension must have acceptable latency and processing overheads." > >> - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same >>>> client when connecting to a remote peer on subsequent occasions. This should either >>>> be the default (clients cannot be "fingerprinted" by the server based on shared state) >>>> or some mechanism should be available for clients to drop or ignore shared state to avoid >>>> being fingerprintable any more than would be present for a cleartext session. >>> Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields. >> right, but see the last part of the last sentence (added by joe) This protocol must not do things worse, makes sense? > Makes sense. Suggest to express it this way, e.g., "the protocol extension must not increase the possibility for endpoint fingerprinting compared to what is possible already". > > Lars From nobody Wed Apr 30 03:02:13 2014 Return-Path: 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 2A2271A08B6 for ; Wed, 30 Apr 2014 03:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 KnXTw9fhiSon for ; Wed, 30 Apr 2014 03:01:53 -0700 (PDT) Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD6D1A08B5 for ; Wed, 30 Apr 2014 03:01:43 -0700 (PDT) Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id s3UA1gNZ022253; Wed, 30 Apr 2014 03:01:42 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3UA1f8P023227; Wed, 30 Apr 2014 03:01:41 -0700 (PDT) X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f From: David Mazieres To: marcelo bagnulo braun , tcpcrypt@ietf.org In-Reply-To: <536099A0.30900@it.uc3m.es> References: <536099A0.30900@it.uc3m.es> Date: Wed, 30 Apr 2014 12:01:36 +0200 Message-ID: <8738gv5e67.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Ksa3-NCI_DexaSKGivr_fGVovbc Subject: Re: [Tcpcrypt] v3 of the charter X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Mazieres expires 2014-07-29 CEST List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 10:02:05 -0000 marcelo bagnulo braun writes: > I have tried to incorporate the comments received. This resulted in > quite a bit of changes, so, i would appreciate feedback (for example, > feedback like "the charter looks great and is ready to go" would be > nice, but if you have other feedback it will be welcome as well). At a high level, this is looking pretty good (modulo weird line breaks that make it hard to read). There are just a couple of places where I think the charter is over-specifying things that might not be problems or that we might not understand, and this could potentially cause problems down the line. > - The protocol must have acceptable performance. For example, the > protocol may try to re-use existing cryptographic material for future > communication between the same endpoints to avoid expensive public key > operations on connection set up. Saying "The protocol must have acceptable performance" is superfluous. By definition performance must be acceptable or we won't accept it, unless you want to invite a debate on what is and is not acceptable performance, which would then bifurcate into setup cost/latency and per-byte/packet overhead. How about, "In order to minimize connection latency, the protocol may amortize the cost of public key operations over multiple connections between the same pair of hosts." > - must allow client to avoid fingerprinting: some clients may want to > avoid appearing as the same client when connecting to a remote peer on > subsequent occasions. This should either be the default (clients > cannot be "fingerprinted" by the server based on shared state) or some > mechanism should be available for clients to drop or ignore shared > state to avoid being fingerprintable any more than would be present > for a cleartext session. Both your text above, and the following suggestion by Lars: > Makes sense. Suggest to express it this way, e.g., "the protocol extension > must not increase the possibility for endpoint fingerprinting compared to what > is possible already". seem problematic to me. The very fact that you are enabling a new TCP extension is going to increase the ability to fingerprint (vs. hosts that have not deployed TCP Inc. yet). I think the right thing to do is for the informational RFC to suggest APIs allowing hosts to be "virtualized" in some way, so that a single physical host actively opening TCP connections through a NAT can appear the same as an arbitrary number of hosts, subject to existing TCP fingerprinting techniques and the fact that TCP Inc. is installed. But I'm wary of trying to specify that in the charter. Would it be possible to drop the requirement in favor of something more open-ended to the effect that consideration should be given to the anonymity of hosts that change IP addresses or reside behind NATs? David From nobody Wed Apr 30 06:51:58 2014 Return-Path: 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 1DC241A0684 for ; Wed, 30 Apr 2014 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 fmwfDT1Gw0aP for ; Wed, 30 Apr 2014 06:51:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E101B1A6F2F for ; Wed, 30 Apr 2014 06:51:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.7) with ESMTP id s3UDpctV001171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Apr 2014 16:51:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s3UDpa2k001042; Wed, 30 Apr 2014 16:51:36 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21344.65512.465866.311361@fireball.kivinen.iki.fi> Date: Wed, 30 Apr 2014 16:51:36 +0300 From: Tero Kivinen To: Joe Touch In-Reply-To: <535E71E8.6020001@isi.edu> References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> <21342.18899.736731.804370@fireball.kivinen.iki.fi> <535E71E8.6020001@isi.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/4cMC0Aziya91mQY1viW2sRXCEhc Cc: Wesley Eddy , John-Mark Gurney , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:51:57 -0000 Joe Touch writes: > > The current IPsec specifications (IKEv2, RFC5996) do specify how rekey > > happens and it is specified so that no packets are lost: i.e. first > > create new Child SA proactively, i.e. before the old Child SA expires; > > then wait for traffic to move to this new SA (i.e. when you see > > packets on new Child SA, you know that other end has installed it); > > and only then remove old Child SA. > > You can't ensure that no packets are lost that way. Once you transition > to a new SA - even if you coordinate that handoff - there may be > out-of-order packets that arrive after that coordination. The timer to delete the old SA after the new is up (and we are seeing traffic on the new SA) are usually in order of 5-10 seconds or something like that, just to take care of the old packets. If the out-of-order packet is delayed by more than 5-10 seconds before it finally arrive to the other peer, it might already be dropped by the replay window checks (depending how big window you are using), and it would most likely already been considered as being lost by the upper layers. Note, also that after the rekey has been finished, and we have see packets on the new SA, and when we start deleting the old SA, we still accept packets on the old SA, because the delete is two way. I.e. we send delete notification saying we are not going to send data our outgoing old SA, and only when we get response back from the other where it tells he will not be sending data on his old outgoing SA (i.e our incoming SA), we actually delete the inbound SA. I.e. in normal case there is no lost packets. -- kivinen@iki.fi From nobody Wed Apr 30 08:09:56 2014 Return-Path: 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 F2D341A6FD7 for ; Wed, 30 Apr 2014 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 W6zcksukhrJd for ; Wed, 30 Apr 2014 08:09:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 375481A6FBB for ; Wed, 30 Apr 2014 08:09:53 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UF9D2r013184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 08:09:16 -0700 (PDT) Message-ID: <53611219.2030106@isi.edu> Date: Wed, 30 Apr 2014 08:09:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tero Kivinen References: <53576572.5030805@it.uc3m.es> <53589161.4090700@mti-systems.com> <20140424155532.GR43976@funkthat.com> <21342.18899.736731.804370@fireball.kivinen.iki.fi> <535E71E8.6020001@isi.edu> <21344.65512.465866.311361@fireball.kivinen.iki.fi> In-Reply-To: <21344.65512.465866.311361@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/-QgOlQzqclx6323dK3NX1Nm5VNg Cc: Wesley Eddy , John-Mark Gurney , tcpcrypt@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:09:55 -0000 On 4/30/2014 6:51 AM, Tero Kivinen wrote: > Joe Touch writes: >>> The current IPsec specifications (IKEv2, RFC5996) do specify how rekey >>> happens and it is specified so that no packets are lost: i.e. first >>> create new Child SA proactively, i.e. before the old Child SA expires; >>> then wait for traffic to move to this new SA (i.e. when you see >>> packets on new Child SA, you know that other end has installed it); >>> and only then remove old Child SA. >> >> You can't ensure that no packets are lost that way. Once you transition >> to a new SA - even if you coordinate that handoff - there may be >> out-of-order packets that arrive after that coordination. > > The timer to delete the old SA after the new is up (and we are seeing > traffic on the new SA) are usually in order of 5-10 seconds or > something like that, just to take care of the old packets. > > If the out-of-order packet is delayed by more than 5-10 seconds before > it finally arrive to the other peer, it might already be dropped by > the replay window checks (depending how big window you are using), and > it would most likely already been considered as being lost by the > upper layers. But in that case the replay prevention would be dropping packets that could be valid (i.e., they're only replayed if the particular byte range overlaps, but merely if it's "earlier than expected". ... > I.e. in normal case there is no lost packets. You just said that replay would drop them - that's a drop TCP would see too. Joe From nobody Wed Apr 30 08:24:20 2014 Return-Path: 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 ABDE21A6FEE for ; Wed, 30 Apr 2014 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 DHr9eEsqnGuk for ; Wed, 30 Apr 2014 08:24:12 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB9D1A6F88 for ; Wed, 30 Apr 2014 08:24:12 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UFNcFc017565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 08:23:41 -0700 (PDT) Message-ID: <5361157B.9060501@isi.edu> Date: Wed, 30 Apr 2014 08:23:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Eggert, Lars" , Marcelo Bagnulo References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> In-Reply-To: <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aQ1wt29vaVYhFLxKMUIVhVLgESk Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:24:18 -0000 On 4/30/2014 1:20 AM, Eggert, Lars wrote: > Hi, > > a few comments. This is looking good overall. > > On 2014-4-30, at 8:35, marcelo bagnulo braun wrote: >> TCP Increased Security (TCP Inc.) > > am not in love with the name, but don't want to start a bikeshed. > >> This is better than plain-text >> because it thwarts passive eavesdropping, but is weaker than using >> authenticated keys, because it is vulnerable to man-in-the-middle attacks. > > Is it desirable to have a model where you're vulnerable to MiM the > first time you connect to a server, but not afterwards? (Like what SSH > provides in terms of warning when the server key has changed?) It might be, but this might require configuration coordination between hosts that share ID info - whether at a load-server or behind a NAT. ... >> - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same >> client when connecting to a remote peer on subsequent occasions. This should either >> be the default (clients cannot be "fingerprinted" by the server based on shared state) >> or some mechanism should be available for clients to drop or ignore shared state to avoid >> being fingerprintable any more than would be present for a cleartext session. > > Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields. It already says "any more than would be present for a cleartext session". Sure, you get the info that TCP-Inc is supported, but shouldn't need to expose more about the client than that. Joe From nobody Wed Apr 30 08:28:52 2014 Return-Path: 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 788FF1A6FC8 for ; Wed, 30 Apr 2014 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Y6WQP4gz7zVr for ; Wed, 30 Apr 2014 08:28:46 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D853C1A091F for ; Wed, 30 Apr 2014 08:28:46 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UFSGG3018873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 08:28:19 -0700 (PDT) Message-ID: <53611690.4040008@isi.edu> Date: Wed, 30 Apr 2014 08:28:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Mazieres expires 2014-07-29 CEST , marcelo bagnulo braun , tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <8738gv5e67.fsf@ta.scs.stanford.edu> In-Reply-To: <8738gv5e67.fsf@ta.scs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/CRBExdrlTxzuK5bKXcCmV6zczJk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:28:51 -0000 On 4/30/2014 3:01 AM, David Mazieres wrote: > marcelo bagnulo braun writes: ... > Saying "The protocol must have acceptable performance" is superfluous. > By definition performance must be acceptable or we won't accept it, > unless you want to invite a debate on what is and is not acceptable > performance, which would then bifurcate into setup cost/latency and > per-byte/packet overhead. > > How about, "In order to minimize connection latency, the protocol may > amortize the cost of public key operations over multiple connections > between the same pair of hosts." The protocol may do a lot of things; I don't think we should require this, necessarily - for the reason I already posted (configuration coordination complexity). The text Marcelo proposed, IMO, left it open as to whether amortization was needed vs. the cost. ... >> Makes sense. Suggest to express it this way, e.g., "the protocol extension >> must not increase the possibility for endpoint fingerprinting compared to what >> is possible already". > > seem problematic to me. The very fact that you are enabling a new TCP > extension is going to increase the ability to fingerprint (vs. hosts > that have not deployed TCP Inc. yet). > > I think the right thing to do is for the informational RFC to suggest > APIs allowing hosts to be "virtualized" in some way, so that a single > physical host actively opening TCP connections through a NAT can appear > the same as an arbitrary number of hosts, subject to existing TCP > fingerprinting techniques and the fact that TCP Inc. is installed. But > I'm wary of trying to specify that in the charter. Me too, esp. because that's a completely new capability that hasn't been demonstrated for non-secure TCP. > Would it be possible to drop the requirement in favor of something more > open-ended to the effect that consideration should be given to the > anonymity of hosts that change IP addresses or reside behind NATs? Again, IMO, that's getting too specific. I think the charter as-is is enough to proceed with a few possible approaches. Joe From nobody Wed Apr 30 13:07:17 2014 Return-Path: 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 D6D051A097D for ; Wed, 30 Apr 2014 13:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mPQ-C-aumMtI for ; Wed, 30 Apr 2014 13:07:13 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 67AC41A0972 for ; Wed, 30 Apr 2014 13:07:13 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id BFADDF984; Wed, 30 Apr 2014 16:07:09 -0400 (EDT) Message-ID: <536157E1.2060202@fifthhorseman.net> Date: Wed, 30 Apr 2014 16:06:57 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: "Eggert, Lars" , Marcelo Bagnulo References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> In-Reply-To: <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6fs9jWn7rE1NxIT0hlMKO2j6D8IEMRXJ3" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/_iQTZS8m4XF0epw8PWfcZbQMtdE Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:07:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6fs9jWn7rE1NxIT0hlMKO2j6D8IEMRXJ3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 04:27 AM, Eggert, Lars wrote: > Oh, forgot one more overall issue: The charter talks about clients and = servers a lot. While that's convenient, because it matches the communicat= ion flow of the app layer protocols on top of TCP, and NATs now demand a = directionality of connection establishment, those terms don't actually ha= ve a lot of meaning for TCP, which is a bidirectional protocol. Suggest t= o rephrase. TCP is bidirectional, but the handshake is asymmetric: one party listen()s and accept()s, and the other party connect()s. These parties are widely known as the "server" and "client", respectively. I think that's what the draft charter refers to. What other names do you recommend using for these roles? --dkg --6fs9jWn7rE1NxIT0hlMKO2j6D8IEMRXJ3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYVfhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc3uEQAMZEBUDeD6uAlomJ7RVZJ6dI Rmwt2Xj2jwhGPamqJ1u0+lloXwwCxVjuk2eunFbH7W5mg7VRISX3YbcOz/EIo8HW 2GDzGsu4JXjGYmUvHDOOcnoyRQyIlMZ0O+ucmfq410cIhxiTfyjCn0lxd7oLp2vx /bnhdxQy8t5cvcqAM/FNLPu1w2b9XHVeLTgJa/iCsCqd7uyg3NsJ4P4e0QmkcMfS Es6sYA9/Po/M+KClY0sx3uVJJcovEsAdr0wJcq2c0FuxF0ND225/bd7AbpcXwlmd yPdrQwNcQ2zYvfsJwFHDhQIgipLG6JfTuObKS9msQh8IBQdRF0RomZm5FtwatyUw A9NjThc6oo80p9YjxLHeECbwAmDSDW6fsI0iGgz8G7C+lSwPcZVF+1a00oRVG1t+ 5iiB4CrznXminFeeB14uvhykj8Y9UMnhN2vO7pYCjZsqux5CJzd9wevv7Hvl/Rp+ EaEydC/OsOEM4TT+NS8qQ1q1OJun2VGxfQI4Hj/xJmofIzxg+PnQbhlBr5adCmi+ 7M5E9ZdS+m6l8pUz/MXk+vS8p4JsV1Z7gGsW35J2Wjs9TJ8oTipDmjs2sx+HZpck qJzAbEE1OR2fWt/4Ak0IKttAMIFtJ0ujHUl6Vh4J6ywTvURmOqeSy1PFcMofg+U5 ZyVrOs2kCWxzl3e47GyN =xaGh -----END PGP SIGNATURE----- --6fs9jWn7rE1NxIT0hlMKO2j6D8IEMRXJ3-- From nobody Wed Apr 30 13:17:31 2014 Return-Path: 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 C53B41A884D for ; Wed, 30 Apr 2014 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 5dQEQs2J05Eo for ; Wed, 30 Apr 2014 13:17:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E9D5A1A097D for ; Wed, 30 Apr 2014 13:17:28 -0700 (PDT) Received: from [128.9.184.196] ([128.9.184.196]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UKH4R3023871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 13:17:05 -0700 (PDT) Message-ID: <53615A40.9050903@isi.edu> Date: Wed, 30 Apr 2014 13:17:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , "Eggert, Lars" , Marcelo Bagnulo References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> In-Reply-To: <536157E1.2060202@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/F1QSpRPkhuRxy99VS6LiRILTMAs Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:17:29 -0000 On 4/30/2014 1:06 PM, Daniel Kahn Gillmor wrote: > On 04/30/2014 04:27 AM, Eggert, Lars wrote: >> Oh, forgot one more overall issue: The charter talks about clients and servers a lot. While that's convenient, because it matches the communication flow of the app layer protocols on top of TCP, and NATs now demand a directionality of connection establishment, those terms don't actually have a lot of meaning for TCP, which is a bidirectional protocol. Suggest to rephrase. > > TCP is bidirectional, but the handshake is asymmetric: one party > listen()s and accept()s, and the other party connect()s. TCP supports simultaneous open too. In which case, who's the client and who's the server? Joe From nobody Wed Apr 30 14:03:21 2014 Return-Path: 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 6178B1A0852 for ; Wed, 30 Apr 2014 14:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jWc0PUvpDFII for ; Wed, 30 Apr 2014 14:03:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A71A81A063B for ; Wed, 30 Apr 2014 14:03:10 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9374CF984; Wed, 30 Apr 2014 17:03:07 -0400 (EDT) Message-ID: <536164FF.6000908@fifthhorseman.net> Date: Wed, 30 Apr 2014 17:02:55 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: "Eggert, Lars" , Marcelo Bagnulo References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> In-Reply-To: <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SMPsPEkAQ60mrSjltSnjgBK97lU1gBGB1" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/I87zpuDkWS5egtAabfDF3UYnhRY Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:03:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SMPsPEkAQ60mrSjltSnjgBK97lU1gBGB1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 04:20 AM, Eggert, Lars wrote: > Is it desirable to have a model where you're vulnerable to MiM the firs= t time you connect to a server, but not afterwards? (Like what SSH provid= es in terms of warning when the server key has changed?) I'd call this trust-on-first-use (TOFU) or leap-of-faith (LoF). I'm not sure it's appropriate for TCP Inc as currently designed, because these models have serious problems with re-keying events. In particular, what do we expect a TCP Inc client to do if a host's key changes? If it aborts the connection, then we've violated the "don't display state to the normual user" approach. If it falls back to cleartext, then we're back to plain TCP, unprotected even against passive attackers. Keys get compromised; hosts fail and need to be rebuilt; there are legitimate reasons to re-key. If TOFU or LoF deals poorly with those circumstances, and we include TOFU/LoF in TCP Inc, it would make thoughtful sysadmins wary of rolling out TCP Inc, out of fear of what it would do for their reachability. this isn't to say that a layer above TCP Inc couldn't do TOFU or LoF, based on the authentication hooks provided by TCP Inc, of course, assuming that the authentication hooks are built in a way to support that behavior. But i don't think it belongs in TCP Inc itself as currently framed. --dkg --SMPsPEkAQ60mrSjltSnjgBK97lU1gBGB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYWT/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcN9oP/A+re0y/XDhspyEBvgn2JMWR 2f5jA2acSJmZ+jvyD3uLR12kszx1ZHl0zSO5BzTZKLnFTvO8jpS3ojGcHPOMhrja 9N0NL/Rqf4fi5jnXOi8wEb5vo4h6dtEoL65r0W5+/hiD9plwHAysRQelK1+3Ijqb GXPXTySgUVBm312BsMEdHqzaM5wtkptcgrLERQ3hMKaLIgA/ZduuNlZl0tTxVz3V ROumSgGoyTl4ZipHaf4GNh6bMqMAxuSRyUi5NLODsw7Q3gHaMjMU8lx84g6Cbkyu A3uIEI+JSAQmkQsyuuwCduRdhXSA2ROR3nVOynxZ38fzwGBeAHy7oAh7f0JBA18q J/CP1Wqkl6lNOf9Qriq2xL3UiYao6hAcDSvhpjzukZrd1koaSO6NSMBek6z6OpIZ admYrECE45B8kstq7OFlrhFrAPnH+cUEkcq2iHw3dDi9TcBAeVSfKRnQemhgkB9I PmWeB4GcavixyfxQX2koEsklhhK8dkpFO5FCz57M9bil3e0t/gzJ8K3tX1KTW8gi orq4w0dhKQovwRVCpi3JYPdh3z9rGQpAa6vss6RpOP+rczO/mAvvx2BDcBvopZfi RFZK2NERaZV4aXSYtVsJep8CLCbi3sVI02R9NJRn/zXYEYogU84PprxMfbWLFe+g xqz5HOIoMC0Py7nZTLRY =0pw6 -----END PGP SIGNATURE----- --SMPsPEkAQ60mrSjltSnjgBK97lU1gBGB1-- From nobody Wed Apr 30 14:06:22 2014 Return-Path: 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 9E8D01A09BC for ; Wed, 30 Apr 2014 14:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uR7C89BsyS1w for ; Wed, 30 Apr 2014 14:06:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 43A341A0958 for ; Wed, 30 Apr 2014 14:06:16 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 97841F984; Wed, 30 Apr 2014 17:06:13 -0400 (EDT) Message-ID: <536165C6.20909@fifthhorseman.net> Date: Wed, 30 Apr 2014 17:06:14 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Joe Touch , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <53615A40.9050903@isi.edu> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nMHHdFVnPjJ9MAxrvmTjuuJSfgPxGJ6Cg" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/p24ak1D_GpXr6JGFYsF8itEBHkU Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:06:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nMHHdFVnPjJ9MAxrvmTjuuJSfgPxGJ6Cg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 04:17 PM, Joe Touch wrote: > On 4/30/2014 1:06 PM, Daniel Kahn Gillmor wrote: >> TCP is bidirectional, but the handshake is asymmetric: one party >> listen()s and accept()s, and the other party connect()s. >=20 > TCP supports simultaneous open too. In which case, who's the client and= > who's the server? In the simultaneous open case (does anyone actually use that in practice?), both parties already know something about their peers (at least, they know who they want to connect to). From the perspective of fingerprinting concerns, that suggests that they should both be treated as servers, not as clients. --dkg --nMHHdFVnPjJ9MAxrvmTjuuJSfgPxGJ6Cg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYWXGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+r0QAIuJMTBVG7GDx/qFo5uHH4YF y4ClyQ4kUIlmR6Vn7O/XyEs0GMey6M+0wpPY1w1Md0eLRLTGHH6tt3adDTySmt6u SmrfHhybcYBhmx3YOX3vWqc+rbaAfnoicVHo0ja5DDQ61C1IsJzojmWH+7En7ta3 JUqTNRG+YuQqi6JOj/JNRRDDpD9jjQ2EYaq1WA3ZKqEX/BxNyc09Vnr5a7VZhJGM 09lcFnVxzjs/dFoyzvUiDjCrNWhe2cFe7W5slvxv6AO3GQcrXOUBE+mdWGLrOWzi 7vZjBcRHRvrf45vFUt1YZGoIs+NMDjUBvsQefhK7RiMuU+wtwDd7xmUZ3uOIYo+V M2yd8/9zQEAvCYEcb9sFh89ngXpCF8t6MN+E0174bjwrmaEdeAFn3MRG1omMSYOh S0qtsg3DuGNthvQWVFOClDKPNLHH1Cdup0l8lGJY+4Vcw2/qCE9/Se+U/gx9kBit dvX6zbl7M+th6o28Fdtsyrh/gXj3PYoZQoxm8gmxo1NvQcocwVsOvWsssYvQ+nvZ Pof/xov27JqefZepUfSe4D7w/ILbJiaXMZiBftYINMPDdVhY2bg4VIvqGwLMQrLN NuZMW4aaBnmJPB2YfwnNsSYcgVWzXnkY77TP33o5DYXCJgdJZ8LuLamoq+MFd/++ Sng9rtJ38J6zAvDAlnVw =OFog -----END PGP SIGNATURE----- --nMHHdFVnPjJ9MAxrvmTjuuJSfgPxGJ6Cg-- From nobody Wed Apr 30 14:15:28 2014 Return-Path: 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 D8A371A08B5 for ; Wed, 30 Apr 2014 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xFRQ-0fALAMD for ; Wed, 30 Apr 2014 14:15:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AE1A0639 for ; Wed, 30 Apr 2014 14:15:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3ULEq51024582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 14:14:52 -0700 (PDT) Message-ID: <536167CC.8010703@isi.edu> Date: Wed, 30 Apr 2014 14:14:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <536165C6.20909@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/N0dzeWDzP4yvVXyYlKtwOuzzIXY Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:15:28 -0000 On 4/30/2014 2:06 PM, Daniel Kahn Gillmor wrote: > On 04/30/2014 04:17 PM, Joe Touch wrote: >> On 4/30/2014 1:06 PM, Daniel Kahn Gillmor wrote: >>> TCP is bidirectional, but the handshake is asymmetric: one party >>> listen()s and accept()s, and the other party connect()s. >> >> TCP supports simultaneous open too. In which case, who's the client and >> who's the server? > > In the simultaneous open case (does anyone actually use that in > practice?), both parties already know something about their peers (at > least, they know who they want to connect to). From the perspective of > fingerprinting concerns, that suggests that they should both be treated > as servers, not as clients. They're also both clients because they issue the initial (non-ACK) SYN. So they're both - which is why most TCP protocol specification docs tend not to use the term client/server. Joe From nobody Wed Apr 30 14:20:11 2014 Return-Path: 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 156411A0957 for ; Wed, 30 Apr 2014 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 v4oimyh4MEt7 for ; Wed, 30 Apr 2014 14:20:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 878A81A08B5 for ; Wed, 30 Apr 2014 14:20:06 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 681A7F984; Wed, 30 Apr 2014 17:20:03 -0400 (EDT) Message-ID: <536168FA.2010800@fifthhorseman.net> Date: Wed, 30 Apr 2014 17:19:54 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Joe Touch , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <536167CC.8010703@isi.edu> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3wj8ECB3MhKEdTno8D14Gk6PNcWuDS6hF" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/89cHK13sLAwW85yeY8Nljw5QYJA Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:20:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3wj8ECB3MhKEdTno8D14Gk6PNcWuDS6hF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 05:14 PM, Joe Touch wrote: > On 4/30/2014 2:06 PM, Daniel Kahn Gillmor wrote: >> In the simultaneous open case (does anyone actually use that in >> practice?), both parties already know something about their peers (at >> least, they know who they want to connect to). From the perspective o= f >> fingerprinting concerns, that suggests that they should both be treate= d >> as servers, not as clients. >=20 > They're also both clients because they issue the initial (non-ACK) SYN.= > So they're both - which is why most TCP protocol specification docs ten= d > not to use the term client/server. I know they're both clients in this sense; we're discussing fingerprinting. the charter text makes it clear that we want to be able to avoid fingerprinting for the client, but not the server, since the server presumably has some form of persistent identity, or else the client wouldn't be able to connect to it in the first place. That's the context in which i think we need to see TCP simultaneous open as a server -- i don't think we need to worry about protecting fingerprinting by the peer for either simultaneous open peer, since each peer already has some information about the other. --dkg (that said, i'm not sure how simultaneous open will work in whatever spec we work out; maybe it turns out we have to be willing to sacrifice simultaneous open in order to use tcp inc?) --3wj8ECB3MhKEdTno8D14Gk6PNcWuDS6hF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYWj6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcxv0P/1GfSCm1pFQG30kSK/f+4QVx ZxEaE3sDXGM4u0znuRbKFMKyi2RKmnOZCIH1Fvz3Vw53ggiPYIKwWcfZBcm/wlBY pMdhXJ+TOpF0d5ozoGFDY33T92S4N9UoKLtbHfCddISF0qbro+oRm4NRvRMA4BHd TMV2WsAWwrfzXXqa23O0eSUyEOxTjEVWhu7NoL94h1GwbwLGHdaHskKHfYrvbxqU ilMmVnu9ItAvC5Cu3uQY/uljBzwOFHFHBKV8yyuBoaH1Re7N3GUCSyNRpPbQAW+I BrHMzQOoWhXJiSXKKdj1qNxr1KYzZ6G4vDi+em6s48m3aahECHaGhLmdMkWmvkFZ G332oQ75yRhsGFBISmgGL1B0lGQC/1JUX4b97OLgFEXcWEeKBuj9nB73uMogJPUL f/7UmplgGMNjRnFaW1uue5evg2C5X4WZAZon0zDLQDOYe0kXBLAnZeWMNQEPIxn2 d3ptuUm6kPSxU3SWo6oGNjRJ6LKaUauUf1kI2T+M3zdIlFfU5Sq6XG4/vC+a37b4 6YoxtOWW5XctnrKNN7hMxYT4vzFAlaAAwo0yAUm5XuXgx6bm+Qm2EfeFq6rj8VrV wLxBIhrTob49w3MTeEBdQ2sUPmNr0suJLFnaBLiz9Fy0/88COdFQVFLVAsQmixPE 6ccg6UCNQd3ig1wiX/OO =FJ8r -----END PGP SIGNATURE----- --3wj8ECB3MhKEdTno8D14Gk6PNcWuDS6hF-- From nobody Wed Apr 30 14:28:31 2014 Return-Path: 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 021C31A0948 for ; Wed, 30 Apr 2014 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 yu-UOOc3URNv for ; Wed, 30 Apr 2014 14:28:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 28C301A09BC for ; Wed, 30 Apr 2014 14:28:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3ULRmsQ027403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 14:27:49 -0700 (PDT) Message-ID: <53616AD4.6010309@isi.edu> Date: Wed, 30 Apr 2014 14:27:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <536168FA.2010800@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ypzsC40KWn0fProumqg34l0LVls Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:28:27 -0000 On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote: ... >> They're also both clients because they issue the initial (non-ACK) SYN. >> So they're both - which is why most TCP protocol specification docs tend >> not to use the term client/server. > > I know they're both clients in this sense; we're discussing > fingerprinting. the charter text makes it clear that we want to be able > to avoid fingerprinting for the client, but not the server, since the > server presumably has some form of persistent identity, or else the > client wouldn't be able to connect to it in the first place. > > That's the context in which i think we need to see TCP simultaneous open > as a server -- i don't think we need to worry about protecting > fingerprinting by the peer for either simultaneous open peer, since each > peer already has some information about the other. It'd be optimal if this wasn't useful for fingerprinting either client or server. Even if you know the server's IP and port, that's all you ought to know, and all that needs to persist during the lifetime of a particular connection. So why not just require anti-fingerprinting in general, and not focus on who initiated the connection? > > --dkg > > (that said, i'm not sure how simultaneous open will work in whatever > spec we work out; maybe it turns out we have to be willing to sacrifice > simultaneous open in order to use tcp inc?) It should revert to conventional TCP and thus support simultaneous open in that case. Joe From nobody Wed Apr 30 14:29:21 2014 Return-Path: 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 7CC681A0958 for ; Wed, 30 Apr 2014 14:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KRiGp3X6VJUH for ; Wed, 30 Apr 2014 14:29:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B711A1A0953 for ; Wed, 30 Apr 2014 14:29:10 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 61AF9F984; Wed, 30 Apr 2014 17:29:07 -0400 (EDT) Message-ID: <53616B23.501@fifthhorseman.net> Date: Wed, 30 Apr 2014 17:29:07 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: David Mazieres expires 2014-07-29 CEST , marcelo bagnulo braun , tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <8738gv5e67.fsf@ta.scs.stanford.edu> In-Reply-To: <8738gv5e67.fsf@ta.scs.stanford.edu> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="scLRc3EXSgCB621VgLjejWQF5a6du2KO9" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/kLRBbDlJj5jY3yYVeVtg2rchQUM 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:29:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --scLRc3EXSgCB621VgLjejWQF5a6du2KO9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 06:01 AM, David Mazieres wrote: > marcelo bagnulo braun writes: >> - must allow client to avoid fingerprinting: some clients may want to >> avoid appearing as the same client when connecting to a remote peer on= >> subsequent occasions. This should either be the default (clients >> cannot be "fingerprinted" by the server based on shared state) or some= >> mechanism should be available for clients to drop or ignore shared >> state to avoid being fingerprintable any more than would be present >> for a cleartext session. >=20 > Both your text above, and the following suggestion by Lars: >=20 >> Makes sense. Suggest to express it this way, e.g., "the protocol exten= sion >> must not increase the possibility for endpoint fingerprinting compared= to what >> is possible already". >=20 > seem problematic to me. The very fact that you are enabling a new TCP > extension is going to increase the ability to fingerprint (vs. hosts > that have not deployed TCP Inc. yet). decreasing the size of the client's anonymity set by a single bit (derived from whether or not the client uses TCP Inc) is obviously unavoidable. But by the same token, if TCP Inc was widely deployed, plain TCP sessions would also in an anonymity set of their own (just with that bit set differently), so TCP Inc itself doesn't come out worse than TCP. But we want to avoid TCP Inc decreasing the client's anonymity set further than that (e.g. we want a client using TCP Inc to be able to appear as a different client (based on TCP Inc parameters) to a given server on subsequent connections if it wants to). For the charter, i think Marcelo's text is reasonable. Lars' suggestion of "what is possible already" seems equivalent to "would be present for a cleartext session" -- maybe what they both mean is best described as "no more fingerprintable than a session without TCP Inc" > I think the right thing to do is for the informational RFC to suggest > APIs allowing hosts to be "virtualized" in some way, so that a single > physical host actively opening TCP connections through a NAT can appear= > the same as an arbitrary number of hosts, subject to existing TCP > fingerprinting techniques and the fact that TCP Inc. is installed. But= > I'm wary of trying to specify that in the charter. I agree that this level of technical detail belongs in the RFC, but not the charter. > Would it be possible to drop the requirement in favor of something more= > open-ended to the effect that consideration should be given to the > anonymity of hosts that change IP addresses or reside behind NATs? This text sounds less open-ended to me than the text you're proposing to replace. In particular, i also care about machines that have a single (non-changing) IP address and are not behind a NAT. Those machines should also be able to avoid fingerprinting from TCP Inc. While it's true they can be fingerprinted by their IP address, it's entirely possible for multiple people to share a single IP address by time slices (consider roommates with a cable modem who each plug their computers in to the same plug at different times). I think we should keep the language in the charter about enabling clients to avoid any extra fingerprinting, since it identifies the goal we want. --dkg --scLRc3EXSgCB621VgLjejWQF5a6du2KO9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYWsjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcLiQQALerR9PTNc0KqU6gLWHNbXnz noDWwy4ioX/mVwNqMAm37WJJi04sxkQj5rPbBgQZWG0tnqWxNuk7D8abvw9MJsSU pYD4rsBPtEIA0kXwAScejV+PffD9kkUCxIRmp58nwPzDLyPteQ7/0M1SuswRDQQK emod28LxH7mnfDmT+ZZiO+ZaMH6jTorkUK7VrCuBGmkoZWSiWQLOzYdI/TxlijGa nmXDhKNemtBIqGIYGGwcoKT+YwC+7BfzpTfqDapKoX9LtNKvNcsF8WNDvH0VZEmR Zj6OWwdw5VzS1wyZvcXT/fONeaKtUYT/cJVRO+NeR6J6HVkwzLxUEQ8rv76v3HAJ E90avMVm5loeNHDVl8PxvPoIiA4T2nfHcze46CzWrSr5THtOdEVHHXNSAongWqr8 RbLBp4ON2/rU9pUfOjMVTL4460cuAkX2PiBKG7agmvsU9Wg6NLT4becFVb0CLAPA GKxqiCrLIGrXXxr7UXnL/raK51pGJb0QthSgWKHtkwWU+IR+M8EbMUyLzxKgS7bb OoPZTYbAktHnNnKSdarBMopmfdv+YNL05tTLQSZfD6RukxYw4cI0Bi01nGF+o6EP xnirDvjgDhiOxZec1fW6lpSY4UbmTjhdKLVYhaV8wQLvqyXUrNzdlGwhqlygKKAV WCECT2xYF1b5Kz5oy4lU =KwXj -----END PGP SIGNATURE----- --scLRc3EXSgCB621VgLjejWQF5a6du2KO9-- From nobody Wed Apr 30 14:38:41 2014 Return-Path: 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 2AE701A0948 for ; Wed, 30 Apr 2014 14:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=no 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 C5-cy2jRN2Jd for ; Wed, 30 Apr 2014 14:38:39 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 284C21A08B5 for ; Wed, 30 Apr 2014 14:38:39 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0D1D0F984; Wed, 30 Apr 2014 17:38:36 -0400 (EDT) Message-ID: <53616D52.3090504@fifthhorseman.net> Date: Wed, 30 Apr 2014 17:38:26 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Joe Touch , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <53616AD4.6010309@isi.edu> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1QkFGLVSebOnR0PMMf3o564r3Go71efQC" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/l4VycID6k8K2aY-ZJloJOnh7jR0 Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1QkFGLVSebOnR0PMMf3o564r3Go71efQC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/2014 05:27 PM, Joe Touch wrote: > On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote: >> I know they're both clients in this sense; we're discussing >> fingerprinting. the charter text makes it clear that we want to be ab= le >> to avoid fingerprinting for the client, but not the server, since the >> server presumably has some form of persistent identity, or else the >> client wouldn't be able to connect to it in the first place. >> >> That's the context in which i think we need to see TCP simultaneous op= en >> as a server -- i don't think we need to worry about protecting >> fingerprinting by the peer for either simultaneous open peer, since ea= ch >> peer already has some information about the other. >=20 > It'd be optimal if this wasn't useful for fingerprinting either client > or server. Even if you know the server's IP and port, that's all you > ought to know, and all that needs to persist during the lifetime of a > particular connection. >=20 > So why not just require anti-fingerprinting in general, and not focus o= n > who initiated the connection? If i connect to the same server and port multiple times (or multiple IP/port pairs, based on e.g. an SRV round-robin), i'm presumably doing so because i know something about the service i'm trying to contact already. This persistence of identity is already in place, simply because i'm making the same attempted connection; i'm not sure that non-fingerprintability of services in this way is particularly meaningful= =2E It sounds like you might also be concerned about the case where a client opens two connections to , and , which both happen to be operated by the same server; and we want the server to be able to avoid leaking the information that it is the same machine operating both services; is that right? I'd be happy to see that case covered by TCP Inc. If you think we can simplify the charter by making it talk about non-fingerprintability of peers in general and get it to cover this case, and avoid client/server wording that people find objectionable, that'd be fine with me. >> (that said, i'm not sure how simultaneous open will work in whatever >> spec we work out; maybe it turns out we have to be willing to sacrific= e >> simultaneous open in order to use tcp inc?) >=20 > It should revert to conventional TCP and thus support simultaneous open= > in that case. I think we might be saying the same thing here -- if it turns out that TCP Inc can't be done with simultaneous open, then you have to sacrifice one feature or the other. --dkg --1QkFGLVSebOnR0PMMf3o564r3Go71efQC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYW1SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpctYYP/2WNDnEd8HagyOAPDYXldwFN M0wfbeQuaXehNG5A/B8XC+9JZlDSvQvmp6aSQbgUbD3N3wTrnmVy3amc031EWah0 ZdkdM6kC7nr7M3m1WDIbE1bcTvWU3exTFXycZrd4h+eVpJQ9uNJALMeeUEMjcNKS 9fSuJCALTQLulQUJbB1irKKH32NE2KUkpnvBtuymRX80BIawAH3v9+ij3SDT+PQV PLwZa5JpAGXHCdRi7Ka2sBWgQBgiA8WgyoVTbTjuyD6VgM5W6YRxq5quuZ531fLm JjzNpMPpQolfDWRP2s6IHY4Zti3xO4lwlBIRiUWQ1k1uch+s2fSi+wcAfYvQjPQ1 xwXM7WkY+Hwr/OBSC0z3+Gz5dsyteD5xQh8pj/lLhlNtotsY1VpoDs+/CNf9JJcJ 2vdjN8f9iOOqx7F9tFuvnRgIQiGyYzw8/8+uYCuP4YF9uUv2/QpKp4PTfJo/YOmj uQeMlc0o8ugIScB8PbE3q4zttpORJ78Cy+Y9kC6ITcoVd978v+z+opJJ6MC1O1yW i5AGtRSQp6ReYwnyVCZqsMMuboOLvpbO1JklvHTrNS799BJ/n5tqbUY600Ry5anD uTdwb3SzkLZ0AnwxwAWgzAJRjoRA/eM/8TL0vbrXNBItAquenUVSCUGxb4JwXlcc 2+zVBmLabzAzoFp/bdfk =NGe4 -----END PGP SIGNATURE----- --1QkFGLVSebOnR0PMMf3o564r3Go71efQC-- From nobody Wed Apr 30 14:55:09 2014 Return-Path: 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 2AA441A09A3 for ; Wed, 30 Apr 2014 14:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 BKT3pTMw7cBf for ; Wed, 30 Apr 2014 14:55:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C61A0852 for ; Wed, 30 Apr 2014 14:55:02 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3ULsPJR003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 14:54:25 -0700 (PDT) Message-ID: <53617111.2060702@isi.edu> Date: Wed, 30 Apr 2014 14:54:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , "Eggert, Lars" , Marcelo Bagnulo 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> In-Reply-To: <53616D52.3090504@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/SqetW2-F8ibO2cY2xARtkJJcYzM Cc: "tcpcrypt@ietf.org" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:55:07 -0000 On 4/30/2014 2:38 PM, Daniel Kahn Gillmor wrote: > On 04/30/2014 05:27 PM, Joe Touch wrote: >> On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote: >>> I know they're both clients in this sense; we're discussing >>> fingerprinting. the charter text makes it clear that we want to be able >>> to avoid fingerprinting for the client, but not the server, since the >>> server presumably has some form of persistent identity, or else the >>> client wouldn't be able to connect to it in the first place. >>> >>> That's the context in which i think we need to see TCP simultaneous open >>> as a server -- i don't think we need to worry about protecting >>> fingerprinting by the peer for either simultaneous open peer, since each >>> peer already has some information about the other. >> >> It'd be optimal if this wasn't useful for fingerprinting either client >> or server. Even if you know the server's IP and port, that's all you >> ought to know, and all that needs to persist during the lifetime of a >> particular connection. >> >> So why not just require anti-fingerprinting in general, and not focus on >> who initiated the connection? > > If i connect to the same server and port multiple times (or multiple > IP/port pairs, based on e.g. an SRV round-robin), i'm presumably doing > so because i know something about the service i'm trying to contact > already. Maybe. However, what you think of as a single host might be implemented as a set, e.g., for performance reasons. > This persistence of identity is already in place, simply > because i'm making the same attempted connection; i'm not sure that > non-fingerprintability of services in this way is particularly meaningful. I think of a fingerprint as providing more information than an address and port - something that persists even when multiple hosts share the same address and port. > It sounds like you might also be concerned about the case where a client > opens two connections to , and Q>, which both happen to be operated by the same server; and we want the > server to be able to avoid leaking the information that it is the same > machine operating both services; is that right? I don't know what everyone else is thinking of here. IMO, fingerprinting is: a) identifying a host e.g., in ways that let me differentiate different hosts used for load-balancing, even when they share the same addr and port b) providing more info about a host e.g., when you can tell me that it's running Linux vs Windows, or which version, etc. IMO, we should avoid both deliberate and accidental fingerprinting. > I'd be happy to see that case covered by TCP Inc. If you think we can > simplify the charter by making it talk about non-fingerprintability of > peers in general and get it to cover this case, and avoid client/server > wording that people find objectionable, that'd be fine with me. See above. I don't think fingerprinting has anything to do with addresses or ports. Joe From nobody Wed Apr 30 16:08:23 2014 Return-Path: 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 65E371A09D8 for ; Wed, 30 Apr 2014 16:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wIZTRB7AdDPL for ; Wed, 30 Apr 2014 16:08:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6C17D1A0955 for ; Wed, 30 Apr 2014 16:08:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CF4DA6D5EB; Wed, 30 Apr 2014 19:08:00 -0400 (EDT) Message-ID: <5361824F.8080506@iang.org> Date: Thu, 01 May 2014 00:07:59 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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> In-Reply-To: <53616D52.3090504@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/VITjgfbPBCjyiFCoXEqvBnb54dk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:08:15 -0000 On 30/04/2014 22:38 pm, Daniel Kahn Gillmor wrote: > On 04/30/2014 05:27 PM, Joe Touch wrote: >> On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote: ... >>> (that said, i'm not sure how simultaneous open will work in whatever >>> spec we work out; maybe it turns out we have to be willing to sacrifice >>> simultaneous open in order to use tcp inc?) >> >> It should revert to conventional TCP and thus support simultaneous open >> in that case. > > I think we might be saying the same thing here -- if it turns out that > TCP Inc can't be done with simultaneous open, then you have to sacrifice > one feature or the other. Yes, one or other. My first instinct is to ask where and when is simultaneous open used? Opportunistic protection in TCP would be far more important to me than something that isn't widely used, no matter how elegant and exotic... My second instinct would be to wonder if these discussions are arising because the charter is still over-specified, too much detail in isolation from some real contending protocols. But that's possibly because I think in terms of competition and unexpected benefits. iang From nobody Wed Apr 30 16:32:14 2014 Return-Path: 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 DD4971A6F2C for ; Wed, 30 Apr 2014 16:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 zWzl0FVtEAql for ; Wed, 30 Apr 2014 16:32:11 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B5FCC1A6F28 for ; Wed, 30 Apr 2014 16:32:11 -0700 (PDT) Received: from [128.9.184.196] ([128.9.184.196]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UNVC3v026273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 16:31:16 -0700 (PDT) Message-ID: <536187C1.3060009@isi.edu> Date: Wed, 30 Apr 2014 16:31:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ianG , 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> In-Reply-To: <5361824F.8080506@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/4HtHbBKujG2oRzqAD9kZfJ0vIek 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:32:13 -0000 On 4/30/2014 4:07 PM, ianG wrote: ... > My second instinct would be to wonder if these discussions are arising > because the charter is still over-specified, too much detail in > isolation from some real contending protocols. But that's possibly > because I think in terms of competition and unexpected benefits. FWIW, mine too - IMO, the issue of anti-fingerprinting can be specified without reference to role, in which case whether simultaneous open is supported or not can be determined in a candidate solution. Joe From nobody Wed Apr 30 17:10:47 2014 Return-Path: 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 3DCF21A0984 for ; Wed, 30 Apr 2014 17:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 YcnjkZCoL8gQ for ; Wed, 30 Apr 2014 17:10:36 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CCCE21A0A02 for ; Wed, 30 Apr 2014 17:10:35 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy4so3159728vcb.26 for ; Wed, 30 Apr 2014 17:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FnHaOmdI9ni3Pa7ZyoTn+8U5U81mJmQCyTRqWRa51x0=; b=qZoeEZVQgTrB09/nNXTta1o96N1jgTzrLfib+9irTq1oiOYk1pFYy6xaWuuz9VNFr9 dUOEzEH6h4JDNcOkYwHTGICR77JtqnNS7WShXCy9yXbaQUPlKL9jDTo54Lui2ulRG2us thLNwp5MVoqCC+U5WxdsyMXMJTCRBmGYxLA7Ba7kcAX5RwlqKfrDsjwfuE/DGnN81CPG 9gFv6kGYb45zTwXMuDQJTDjKJ7whDx+4YjxM9PVJb8Af38zVyDFX4QIzOw5g5JhFty9a x+2kGO6Y913kKxx40/J0tqt2jNNDFKna303KXxAED75pid72hTTxWlFcfc44uit1yovm J7Iw== X-Received: by 10.52.173.165 with SMTP id bl5mr4794399vdc.13.1398903033933; Wed, 30 Apr 2014 17:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 30 Apr 2014 17:10:13 -0700 (PDT) In-Reply-To: <536167CC.8010703@isi.edu> 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> From: Tony Arcieri Date: Wed, 30 Apr 2014 17:10:13 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=bcaec51b9cfd69b5e404f84b7e1b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/-MtXxXGuypM4GeU2JD0weMUzBFE Cc: Marcelo Bagnulo , "tcpcrypt@ietf.org" , "Eggert, Lars" , Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:10:38 -0000 --bcaec51b9cfd69b5e404f84b7e1b Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 2:14 PM, Joe Touch wrote: > They're also both clients because they issue the initial (non-ACK) SYN. So > they're both - which is why most TCP protocol specification docs tend not > to use the term client/server. > Are you attempting to describe TCP hole punching in a NAT firewall? If that's the case, it's a race, and one side will win... -- Tony Arcieri --bcaec51b9cfd69b5e404f84b7e1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 30, 2014 at 2:14 PM, Joe Touch <touch@isi.edu> wrote:
They're also both clients because they issue the initial (non-ACK) SYN= . So they're both - which is why most TCP protocol specification docs t= end not to use the term client/server.

Are you attempting to describe TCP h= ole punching in a NAT firewall? If that's the case, it's a race, an= d one side will win...=C2=A0

--
Tony Arcieri<= br>
--bcaec51b9cfd69b5e404f84b7e1b-- From nobody Wed Apr 30 17:17:06 2014 Return-Path: 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 CD2861A6F22 for ; Wed, 30 Apr 2014 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 VSCEcXd3mKUG for ; Wed, 30 Apr 2014 17:16:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B54171A6F70 for ; Wed, 30 Apr 2014 17:16:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s410Eioo001546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 17:14:44 -0700 (PDT) Message-ID: <536191F4.2020303@isi.edu> Date: Wed, 30 Apr 2014 17:14:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tony Arcieri 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/0u1--6iUXhsFWE1qey5ZsR-Mp98 Cc: Marcelo Bagnulo , "tcpcrypt@ietf.org" , "Eggert, Lars" , Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:16:58 -0000 On 4/30/2014 5:10 PM, Tony Arcieri wrote: > On Wed, Apr 30, 2014 at 2:14 PM, Joe Touch > wrote: > > They're also both clients because they issue the initial (non-ACK) > SYN. So they're both - which is why most TCP protocol specification > docs tend not to use the term client/server. > > Are you attempting to describe TCP hole punching in a NAT firewall? If > that's the case, it's a race, and one side will win... Simultaneous open existed long before NATs. Joe From nobody Wed Apr 30 17:21:02 2014 Return-Path: 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 9BBAF1A6F22 for ; Wed, 30 Apr 2014 17:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 4zGB05h4s6EF for ; Wed, 30 Apr 2014 17:20:59 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 591591A0981 for ; Wed, 30 Apr 2014 17:20:59 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy4so3169701vcb.26 for ; Wed, 30 Apr 2014 17:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xH39Vcy/YWefnmPlMzolHXPbmscyS+iKL5tT8ON/hZA=; b=ms33WSGT/bVbskpHYixfpsxSROKPtwAAfC/n70CO26K68xopjynr3SA4lIZcYVnz8P Zai34TNv4qI0ItzTw0FUYxu+/9fJIBEJNWRicKA392XDnthKcAQHEHePLXNmRPIiKhR3 rcyBHplpoeDkoJGOiJoCkwW7T3vuIyq4NKGk3GBKYkX5vaT8ozsrGfEHgKoCJKIJKmx5 BA99rZ55FrdqBIjrmqNYfmVg595v6ZCi0U2Th8OWH+HYlFlgCHzaikDWtBSJlmbSVfu4 fDzcdiWBXqv8N9GwQ5kNCy5bBx2WhDmUZX+2glFSV7zMtY7KLdDkqeAJu6Fn0w+SQHid H5Bw== X-Received: by 10.220.167.2 with SMTP id o2mr5889451vcy.8.1398903657584; Wed, 30 Apr 2014 17:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.202 with HTTP; Wed, 30 Apr 2014 17:20:37 -0700 (PDT) In-Reply-To: <536191F4.2020303@isi.edu> 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> <536191F4.2020303@isi.edu> From: Tony Arcieri Date: Wed, 30 Apr 2014 17:20:37 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e011618ce95e09404f84ba3df Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/SLVzEoqnePQvSXe6iGY-ifWCnFg Cc: Marcelo Bagnulo , "tcpcrypt@ietf.org" , "Eggert, Lars" , Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:21:00 -0000 --089e011618ce95e09404f84ba3df Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 5:14 PM, Joe Touch wrote: > Simultaneous open existed long before NATs. > It seems like another piece of minutia you are eagerly embracing long before defining the rest of the protocol. How about addressing the 99.9% case first? -- Tony Arcieri --089e011618ce95e09404f84ba3df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 30, 2014 at 5:14 PM, Joe Touch <touch@isi.edu> wrote:
Simultaneous open existed long before NATs.

It seems like another piece of minutia you are eager= ly embracing long before defining the rest of the protocol. How about addre= ssing the 99.9% case first?

--
Tony Arcieri
--089e011618ce95e09404f84ba3df-- From nobody Wed Apr 30 17:38:43 2014 Return-Path: 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 6BC611A0981 for ; Wed, 30 Apr 2014 17:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 bkbOHwPQGcYA for ; Wed, 30 Apr 2014 17:38:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A91781A096A for ; Wed, 30 Apr 2014 17:38:38 -0700 (PDT) Received: from [128.9.184.196] ([128.9.184.196]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s410c8NN015836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 17:38:08 -0700 (PDT) Message-ID: <53619771.3040503@isi.edu> Date: Wed, 30 Apr 2014 17:38:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Arcieri 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> <536191F4.2020303@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/XywYvVHQtY9OdLYb-izapzk8CVw Cc: Marcelo Bagnulo , "tcpcrypt@ietf.org" , "Eggert, Lars" , Daniel Kahn Gillmor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:38:42 -0000 On 4/30/2014 5:20 PM, Tony Arcieri wrote: > On Wed, Apr 30, 2014 at 5:14 PM, Joe Touch > wrote: > > Simultaneous open existed long before NATs. > > > It seems like another piece of minutia you are eagerly embracing long > before defining the rest of the protocol. How about addressing the 99.9% > case first? If by minutia, you mean "supports existing TCP capability", yes. I don't see why any extension to TCP should do otherwise. But yes, let's see what happens first - I don't see this as a non-starter if the corner cases are at least all addressed. Joe