From nobody Thu May 1 00:50: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 9F7A91A00B8 for ; Thu, 1 May 2014 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF6Rnxe4AbgL for ; Thu, 1 May 2014 00:50:28 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 896E31A007C for ; Thu, 1 May 2014 00:50:28 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7700F1228F2C for ; Thu, 1 May 2014 09:50:24 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (151.116.220.87.dynamic.jazztel.es [87.220.116.151]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id CA8D81228F0F for ; Thu, 1 May 2014 09:50:22 +0200 (CEST) Message-ID: <5361FCBD.6010509@it.uc3m.es> Date: Thu, 01 May 2014 09:50: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: tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> In-Reply-To: <536187C1.3060009@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-20666.005 X-TM-AS-Result: No--16.684-7.0-31-1 X-imss-scan-details: No--16.684-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/OtZkEUedgji8UPe3QndZUhoD2TA 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 07:50:31 -0000 El 01/05/14 01:31, Joe Touch escribió: > > > 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. > could you propose text? thanks, marcelo > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu May 1 12:18: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 DE0271A6FF2 for ; Thu, 1 May 2014 12:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RP_MATCHES_RCVD=-0.651, 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 TFwugmUJziKS for ; Thu, 1 May 2014 12:18:45 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3DA1A6FC7 for ; Thu, 1 May 2014 12:18:44 -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 s41F4S7B024649; Thu, 1 May 2014 08:04:28 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s41F4R7S024066; Thu, 1 May 2014 08:04:27 -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: <5361FCBD.6010509@it.uc3m.es> References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> Date: Thu, 01 May 2014 08:04:27 -0700 Message-ID: <87ha59zgjo.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/ZANhlw8VNAy73NJezujg1NxFFxk 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-30 PDT 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 19:18:46 -0000 marcelo bagnulo braun writes: >> 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. >> > > could you propose text? How about eliminating the paragraph about anti-fingerprinting, and instead changing this text: > - 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. To the following: ... In particular, the hooks for supporting external authentication will be defined in this document. In addition, the document shall specify functions that allow control over any session parameters such as accepted ciphers or re-use of cryptographic material from prior sessions (if the protocol supports such re-use) and that help prevent multiple TCP Inc. connections from being linked to the same endpoint. David From nobody Thu May 1 13:03: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 7F4121A6F8C for ; Thu, 1 May 2014 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPTfvG7TgHZ3 for ; Thu, 1 May 2014 13:03:29 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1561A0956 for ; Thu, 1 May 2014 13:03:29 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CE87212AD732; Thu, 1 May 2014 22:03:26 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (151.116.220.87.dynamic.jazztel.es [87.220.116.151]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 3E7B312A9D76; Thu, 1 May 2014 22:03:26 +0200 (CEST) Message-ID: <5362A891.1070300@it.uc3m.es> Date: Thu, 01 May 2014 22:03: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: David Mazieres expires 2014-07-30 PDT , tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> In-Reply-To: <87ha59zgjo.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-20668.001 X-TM-AS-Result: No--19.993-7.0-31-1 X-imss-scan-details: No--19.993-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/74-nDlD93MNW_2fBJuK21DiCVKY 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 20:03:32 -0000 El 01/05/14 17:04, David Mazieres escribió: > marcelo bagnulo braun writes: > >>> 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. >>> >> could you propose text? > How about eliminating the paragraph about anti-fingerprinting, and > instead changing this text: > >> - 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. > To the following: > > ... In particular, the hooks for supporting external > authentication will be defined in this document. In addition, > the document shall specify functions that allow control over any > session parameters such as accepted ciphers or re-use of > cryptographic material from prior sessions (if the protocol > supports such re-use) and that help prevent multiple TCP > Inc. connections from being linked to the same endpoint. Thanks for the text However, i am uncovinced we should link this to the API at this stage. I mean, current charter text basically says avoid additional fingerprinting, doesnt link this to the API, i am dubious we should do this. For instance, i would think legacy apps that dont support the extended API would also want to avoid fingerprinting. What do you think? Regards, marcelo > David > From nobody Thu May 1 13:18: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 B33A41A6F8C for ; Thu, 1 May 2014 13:18:10 -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 KKM8Sz2KZD0K for ; Thu, 1 May 2014 13:18:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9413F1A0974 for ; Thu, 1 May 2014 13:18:09 -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 s41KHVih009407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 13:17:31 -0700 (PDT) Message-ID: <5362ABDA.9040608@isi.edu> Date: Thu, 01 May 2014 13:17:30 -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: David Mazieres expires 2014-07-30 PDT , marcelo bagnulo braun , tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> In-Reply-To: <87ha59zgjo.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/H--QsHhROQLzI3HGL91P7IO2qxE 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 20:18:10 -0000 On 5/1/2014 8:04 AM, David Mazieres wrote: > marcelo bagnulo braun writes: > >>> 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. >>> >> >> could you propose text? > > How about eliminating the paragraph about anti-fingerprinting, and > instead changing this text: > >> - 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. > > To the following: > > ... In particular, the hooks for supporting external > authentication will be defined in this document. In addition, > the document shall specify functions that allow control over any > session parameters such as accepted ciphers or re-use of > cryptographic material from prior sessions (if the protocol > supports such re-use) and that help prevent multiple TCP > Inc. connections from being linked to the same endpoint. But that's not quite all of what fingerprinting implies. I would suggest changing the current fingerprinting requirement: - 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. to: - must not increase information available for fingerprinting: endpoints should be identified by their IP address and port and no additional information should be provided that indicates the persistence of an endpoint or identity other than the IP address and port. Joe From nobody Thu May 1 18:22: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 534FC1A09FA for ; Thu, 1 May 2014 18:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34] 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 abAw3yhRTrqf for ; Thu, 1 May 2014 18:22:00 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id CACC61A09AC for ; Thu, 1 May 2014 18:21:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 354806D581; Thu, 1 May 2014 21:21:52 -0400 (EDT) Message-ID: <5360DC2A.1050100@iang.org> Date: Wed, 30 Apr 2014 12:19:06 +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> <8738gv5e67.fsf@ta.scs.stanford.edu> In-Reply-To: <8738gv5e67.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/xICbicK1EnbeeA17JbhU69Q4SkQ 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: Fri, 02 May 2014 01:22:01 -0000 On 30/04/2014 11:01 am, David Mazieres wrote: > marcelo bagnulo braun writes: ... > 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. I agree with all these points. The goal is to get the designers to come up with different attacks at the compromises possible. It may be that we accept a poorer performance if every other goal is met through a new design; conversely we may accept increased fingerprinting if the design solves everything else... I'd bet most will be happy to accept no algorithm agility if there is a good version upgrade path ;) We won't know until we see. For this reason, I think most of the particular requirements should be SHOULD, and should be rephrased in terms of "consideration be given to..." or words to effect, as pointed out by David. E.g., "Consideration should be given to performance of latency, bandwidth and CPU loading." On the whole however, it's a lot better. Thanks for removing the requirement to turn it off! iang >> - 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 > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Thu May 1 21:29: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 226611A886B for ; Thu, 1 May 2014 21:29: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] 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 f57pfdMjrqCN for ; Thu, 1 May 2014 21:29:48 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 913681A8861 for ; Thu, 1 May 2014 21:29:48 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id D84C8F984 for ; Fri, 2 May 2014 00:29:44 -0400 (EDT) Message-ID: <53631F36.4050700@fifthhorseman.net> Date: Fri, 02 May 2014 00:29:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362ABDA.9040608@isi.edu> In-Reply-To: <5362ABDA.9040608@isi.edu> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x9qNxloEB6v29BPfN4paDQgVNR80Td7MU" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/icR1_yJRo1wQf4UKIqVgZDE94vc 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: Fri, 02 May 2014 04:29:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x9qNxloEB6v29BPfN4paDQgVNR80Td7MU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/01/2014 04:17 PM, Joe Touch wrote: > - must not increase information available for fingerprinting: endpoints= > should be identified by their IP address and port and no additional > information should be provided that indicates the persistence of an > endpoint or identity other than the IP address and port. I know i raised the fingerprinting concern earlier here, but i'm concerned that this statement actually goes too far. "must not increase information available for fingerprinting" implies that peers basically cannot cache state between subsequent connections, which seems like an obvious opportunity for performance improvements. When a client connects to a server a second time, it's entirely reasonable in many cases for the client to presume that the server is the same server it spoke with last time and be able to prove it by doing some sort of abbreviated handshake that presumes the server has some known keying material. Indeed, the "hooks for authentication" angle seems to explicitly require the possibility of some sort of persistent fingerprintability. How about: The repeated use of TCP Inc between two peers may provide information to one peer that could be used to re-identify or "fingerprint" the other peer in subsequent transactions. Peers should be able to use TCP Inc while avoiding leakage of any additional "fingerprinting" information about themselves if configured or built to do so. --dkg --x9qNxloEB6v29BPfN4paDQgVNR80Td7MU 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/ iQJ8BAEBCgBmBQJTYx82XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc4osQAMfoip9EnZp6o2RlZ6ABJiuX YeUMxmC1Suzal8dQkqoGsQmMSyLKY/Bpw60bShHS8x77B/hxheHHoZD+E34pToS6 b7HWb0qXxKeU5eieXxY+xp0qLLteNwuIsXh6tO1YkVXXp7gVGCewLgAhleXXXQXQ IxNmiuYC+r8mTSGuq2rUQNvcRyB1p/iBQHs2gEHCKyBduSfzPolyYvG0cLfFG/gi fVJAlGHYsL0R8UFf4u1a+C4P8QKJgDW1e6V1aHnpiYXCsj4qfdumU3mNF+wCLSfl FPx3tbenovF0GucSw5OGL766z1pctB62TTTu8cFUMXH4uvv1Cob+zpuMvlyIgMOC aawT6vhVCk6SUp4TVnIczzhVlnW5uSJFuVL/jo5foOsSb4so6+Y980X2PcYl5A/x +sBsOLvwqErwetSC3HmicZUa/UkQwmgQGtmxaeO0iROKn3Ri6jN+HyLGezuZYq/s 1GSjWI3ZDT6SgHv8aWNq6S+Ed7a9DTkKaWOcAPA1x6EmpUqTsKBH5ldFMjd+o609 KdIj7ElAZij8JmXJdK3zGqbsMEGe8QsqkiPt5us9r2qrgADhk+sUFp5wZ5TioogF BHrwpGgQib5071J4vr4ggE3FcWiwA/HbebMXefHqdNWlAyMJSBSwgJg8E8EkJl/X novwEufss/rdHlnb9evL =s7W3 -----END PGP SIGNATURE----- --x9qNxloEB6v29BPfN4paDQgVNR80Td7MU-- From nobody Thu May 1 21:35: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 189181A09CA for ; Thu, 1 May 2014 21:35:19 -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, 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 dosMMQViRZZq for ; Thu, 1 May 2014 21:35:17 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) by ietfa.amsl.com (Postfix) with ESMTP id 973F01A09A7 for ; Thu, 1 May 2014 21:35:17 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Wg5Bq-0003Pw-GR for tcpcrypt@ietf.org; Fri, 02 May 2014 00:35:15 -0400 Received: (qmail 10198 invoked from network); 2 May 2014 04:35:13 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 May 2014 04:35:13 -0000 From: "Christian Huitema" To: "'marcelo bagnulo braun'" , "'David Mazieres expires 2014-07-30 PDT'" , References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362A891.1070300@it.uc3m.es> In-Reply-To: <5362A891.1070300@it.uc3m.es> Date: Thu, 1 May 2014 21:35:12 -0700 Message-ID: <046601cf65bf$e95cdd90$bc1698b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ0ag5S167bzmvsnthBxmeiVwB7WwIU97fZAOTvxbIBn8rBEAEI0RH+Afizr6ECdZ7pRgFOYvNeAWB/SekDDs0uMgHwyk6AAVBWelECNwlVkAGlb7CgApegw0WZFoz9wA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/6u8k013Kx6JFzj0wKsJIv1y457w 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: Fri, 02 May 2014 04:35:19 -0000 > However, i am uncovinced we should link this to the API at this stage. > I mean, current charter text basically says avoid additional > fingerprinting, doesnt link this to the API, i am dubious we should do this. > For instance, i would think legacy apps that dont support the extended > API would also want to avoid fingerprinting. The TCP Crypt draft has a powerful feature: the APi can retrieve a session identifier, which can then be used by applications to detect a MITM attack. It would be a shame to preclude that in the charter. -- Christian Huitema From nobody Thu May 1 23:02: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 225041A0776 for ; Thu, 1 May 2014 23:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDO5V-PcXkR4 for ; Thu, 1 May 2014 23:01:58 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 557B61A0684 for ; Thu, 1 May 2014 23:01:58 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F16C6912126 for ; Fri, 2 May 2014 08:01:54 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (151.116.220.87.dynamic.jazztel.es [87.220.116.151]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id CA9F691211A for ; Fri, 2 May 2014 08:01:54 +0200 (CEST) Message-ID: <536334D7.9080706@it.uc3m.es> Date: Fri, 02 May 2014 08:01:59 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362A891.1070300@it.uc3m.es> <046601cf65bf$e95cdd90$bc1698b0$@huitema.net> In-Reply-To: <046601cf65bf$e95cdd90$bc1698b0$@huitema.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20668.005 X-TM-AS-Result: No--17.625-7.0-31-1 X-imss-scan-details: No--17.625-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Mb8WHhnipTm5a5XT1Ngs6J1Jgdc Subject: Re: [Tcpcrypt] v3 of the charter X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 06:02:02 -0000 El 02/05/14 06:35, Christian Huitema escribió: >> However, i am uncovinced we should link this to the API at this stage. >> I mean, current charter text basically says avoid additional >> fingerprinting, doesnt link this to the API, i am dubious we should do > this. >> For instance, i would think legacy apps that dont support the extended >> API would also want to avoid fingerprinting. > The TCP Crypt draft has a powerful feature: the APi can retrieve a session > identifier, which can then be used by applications to detect a MITM attack. > It would be a shame to preclude that in the charter. crypto material reuse and avoiding finger printing are contradictory requirements, i guess. So, i guess it is up to the initiator to decide which one should it get, no? This should be done through the API (which i guess is what David was referring to and i failed to understand) I guess the difficulty is what should be the deafult behaviour i.e. when the upper layer donest support the extended API, but i dont think we need to nail this down in the charter.... > -- Christian Huitema > > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Fri May 2 06: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 37EC91A0829 for ; Fri, 2 May 2014 06:29:39 -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 Xbm__aZpY4OB for ; Fri, 2 May 2014 06:29:38 -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 EF4091A08F7 for ; Fri, 2 May 2014 06:29:37 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so5379456vcb.15 for ; Fri, 02 May 2014 06:29:35 -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=1b0r2rWKMcfuKOFsLBnKJKU+fadeZmqeVjQajGctIEo=; b=zSgzHYEu/may9Jytf3j8/isqjMeXhhuGKlQ9hSYK2cSnZno3bfF5RHNzTc8s1iTsnC CZlqMqbUh6voo2CAMgq1GNj7bDQfJfxNssXyRP/0m3YKvn4TpeFU4BA4xo0Xxd4tV1H8 AD4YGA1jd7yttVs3hJY5tvbHIdpztApjGVj1f6Ae2iWcueHXyxdoDDey8c4gWpd9xsnw 2wc0dahOfi5EEidJANBQLHlUtoI6iJNXxDo7okzC9sHl6XKwmBSBUfX7qgpTNTVm55Ma rxTu9g2hhFbCtloR1+k5BqBd5NUrTUQANT33pacgst+Y65RNrfzx729MOfktuRfT+zaY Czdg== MIME-Version: 1.0 X-Received: by 10.220.105.4 with SMTP id r4mr998821vco.27.1399037375471; Fri, 02 May 2014 06:29:35 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.189.195 with HTTP; Fri, 2 May 2014 06:29:35 -0700 (PDT) In-Reply-To: <536334D7.9080706@it.uc3m.es> References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362A891.1070300@it.uc3m.es> <046601cf65bf$e95cdd90$bc1698b0$@huitema.net> <536334D7.9080706@it.uc3m.es> Date: Fri, 2 May 2014 09:29:35 -0400 X-Google-Sender-Auth: 8b99BHssrGkhZK4y8x36DfloIqI Message-ID: From: Erik Nygren To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=089e0122f332cae7e504f86ac51e Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bkPZax8yzoZPqo9ao2Ad4xZKWi4 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: Fri, 02 May 2014 13:29:39 -0000 --089e0122f332cae7e504f86ac51e Content-Type: text/plain; charset=UTF-8 On Fri, May 2, 2014 at 2:01 AM, marcelo bagnulo braun wrote: > crypto material reuse and avoiding finger printing are contradictory > requirements, i guess. > So, i guess it is up to the initiator to decide which one should it get, > no? > This should be done through the API (which i guess is what David was > referring to and i failed to understand) > The use-cases mentioned in the charter for multi-path TCP and TCP Fast Open are also potentially contradictory, since the whole point of this for those is authenticating a session as relating to another session (from other IP addresses in the MPTCP use-case, even). On 05/01/2014 04:17 PM, Joe Touch wrote: > - must not increase information available for fingerprinting: endpoints > should be identified by their IP address and port and no additional > information should be provided that indicates the persistence of an > endpoint or identity other than the IP address and port. This opens up a server-side naming question: does there need to be a way to name service end-points beyond just IP address? Given the limitations of IPv4 address availability, TLS has found it necessary to introduce a Server Name Indicator. As long as tcpcrypt is doing just anonymous/unauthenticated/etc encryption it may be that this isn't an issue in some cases, but once we start introducing ways to configure keys associated with service end-points, we start needing to have ways to name those keys which starts to be hard without exposing additional naming/routing/identity information. --089e0122f332cae7e504f86ac51e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 2, 2014 at 2:01 AM, marcelo bagnulo braun <m= arcelo@it.uc3m.es> wrote:
crypto material reuse and= avoiding finger printing are contradictory requirements, i guess.
So, i guess it is up to the initiator to decide which one should it get, no= ?
This should be done through the API (which i guess is what David was referr= ing to and i failed to understand)

The = use-cases mentioned in the charter for multi-path TCP and TCP Fast Open are= also potentially contradictory, since the whole point of this for those is= authenticating a session as relating to another session (from other IP add= resses in the MPTCP use-case, even).


On 05/01/2014 04:17 PM, Joe Touch wrote:
> - must not increas= e information available for fingerprinting: endpoints
> should be identified by their IP address and port and no additional > information should be provided that indicates the persistence of an > endpoint or identity other than the IP address and port.

This opens up a server-side naming question:=C2=A0 does ther= e need to be a way to name service end-points beyond just IP address?=C2=A0= Given the limitations of IPv4 address availability, TLS has found it neces= sary to introduce a Server Name Indicator.=C2=A0 As long as tcpcrypt is doi= ng just anonymous/unauthenticated/etc encryption it may be that this isn= 9;t an issue in some cases, but once we start introducing ways to configure= keys associated with service end-points, we start needing to have ways to = name those keys which starts to be hard without exposing additional naming/= routing/identity information.


--089e0122f332cae7e504f86ac51e-- From nobody Fri May 2 06:41: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 641411A6FB4 for ; Fri, 2 May 2014 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_66=0.6, 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 gx8qdB7gY5QL for ; Fri, 2 May 2014 06:41:40 -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 418261A2130 for ; Fri, 2 May 2014 06:41:40 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so5350567vcb.14 for ; Fri, 02 May 2014 06:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=VDyRquDIURvwT3phox/xNj2kTBTGEKKtJoI80K00qeI=; b=NdKy7aY/YhXj+R2sKcGYvdATbVuS2fkVlUXly9zXYiD2u/i0jfyu8WrjBGDApDkdl8 Ap5LiY4sksVwFFESLW8rOfTjuQewp8pYRkaZ1RiZs0UtqMHKXH+DVf0XVCt+KmAdhVZ8 MYb9jGXvSZ+g08KHSYQ1pfV5mcycmPmxgLc8toGaBvQXZvlDyQ7cQ3kLivq8VbCfxGXY NYKhfjSglikG8f2WpZmyU4SlyEFL0fhXRzHHWgxahAws5v5L+PbybzLsuJeoZnvU668a marFPrI3oRR0dYFSjoGY4x1Uky5wkTlng/yUXznJY1txfH1mUkmfNP8rwOZSg+8wZ7rJ 3PXQ== MIME-Version: 1.0 X-Received: by 10.58.31.136 with SMTP id a8mr13938920vei.20.1399038097831; Fri, 02 May 2014 06:41:37 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.189.195 with HTTP; Fri, 2 May 2014 06:41:37 -0700 (PDT) Date: Fri, 2 May 2014 09:41:37 -0400 X-Google-Sender-Auth: T-n6yfaGaa8Yuq15TpmFX9xC3SY Message-ID: From: Erik Nygren To: marcelo bagnulo braun , tcpcrypt@ietf.org Content-Type: multipart/alternative; boundary=047d7b2e49d0d93db804f86af009 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/zKGXX71yR6GU-ARyqf1IVvkSMVg Subject: [Tcpcrypt] attack resilience (was "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: Fri, 02 May 2014 13:41:41 -0000 --047d7b2e49d0d93db804f86af009 Content-Type: text/plain; charset=UTF-8 At what stage should we discuss attack resilience, and in particular the ability of one end-point to launch an asymmetric resource DDoS attack against the other end-point? This has historically been an area where remediations have been critical for both TCP extensions as well as for crypto systems. Just look at SYN flood attack mitigations (eg, SynCookies), the failure of TTCP and the additions to TFO to address those gaps, the need for tokens in the DTLS handshake, and especially the challenges in defending servers exposing TLS to DDoS attacks. Mitigations need to be traded off against added round-trips as well as privacy exposures. Should there be a line-item in the charter on this topic, or should this be covered in post-charter discussions? For example, a client clearly must not be able to force a server to do expensive crypto operations until there has at least been one packet handshake. End-points under duress can also presumably chose to fallback to plaintext TCP (although this could motivate an attacker to try and force end-points into this mode). Optional proof-of-work client puzzles (when under duress) are also an option, but add complexity and potential risks in regimes outside of client:server uses of TCP. Erik --047d7b2e49d0d93db804f86af009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At what stage should we discuss attack resilienc= e, and in particular the ability of one end-point to launch an asymmetric r= esource DDoS attack against the other end-point?=C2=A0 This has historicall= y been an area where remediations have been critical for both TCP extension= s as well as for crypto systems.=C2=A0 Just look at SYN flood attack mitiga= tions (eg, SynCookies), the failure of TTCP and the additions to TFO to add= ress those gaps, the need for tokens in the DTLS handshake, and especially = the challenges in defending servers exposing TLS to DDoS attacks.=C2=A0 Mit= igations need to be traded off against added round-trips as well as privacy= exposures.

Should there be a line-item in the charter on this topic, or shou= ld this be covered in post-charter discussions?

For examp= le, a client clearly must not be able to force a server to do expensive cry= pto operations until there has at least been one packet handshake.=C2=A0 En= d-points under duress can also presumably chose to fallback to plaintext TC= P (although this could motivate an attacker to try and force end-points int= o this mode).=C2=A0 Optional proof-of-work client puzzles (when under dures= s) are also an option, but add complexity and potential risks in regimes ou= tside of client:server uses of TCP.

=C2=A0=C2=A0=C2=A0 Erik

--047d7b2e49d0d93db804f86af009-- From nobody Fri May 2 08:06: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 9D7991A6F64 for ; Fri, 2 May 2014 08:06:08 -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_66=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 TBftNtAqbBzg for ; Fri, 2 May 2014 08:06:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 938BB1A6F27 for ; Fri, 2 May 2014 08:06:07 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s42F4bQm016967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 08:04:46 -0700 (PDT) Message-ID: <5363B407.9080700@isi.edu> Date: Fri, 02 May 2014 08:04:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erik Nygren , marcelo bagnulo braun , tcpcrypt@ietf.org References: 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/2yDvU-HHVDo53-JtbeJ7k0u-HXQ Subject: Re: [Tcpcrypt] attack resilience (was "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: Fri, 02 May 2014 15:06:08 -0000 IMO, the point below is a useful way to compare candidate approaches. These all fall under effectiveness and cost, and we don't need the charter to state such to consider those issues. Joe On 5/2/2014 6:41 AM, Erik Nygren wrote: > At what stage should we discuss attack resilience, and in particular the > ability of one end-point to launch an asymmetric resource DDoS attack > against the other end-point? This has historically been an area where > remediations have been critical for both TCP extensions as well as for > crypto systems. Just look at SYN flood attack mitigations (eg, > SynCookies), the failure of TTCP and the additions to TFO to address > those gaps, the need for tokens in the DTLS handshake, and especially > the challenges in defending servers exposing TLS to DDoS attacks. > Mitigations need to be traded off against added round-trips as well as > privacy exposures. > > Should there be a line-item in the charter on this topic, or should this > be covered in post-charter discussions? > > For example, a client clearly must not be able to force a server to do > expensive crypto operations until there has at least been one packet > handshake. End-points under duress can also presumably chose to > fallback to plaintext TCP (although this could motivate an attacker to > try and force end-points into this mode). Optional proof-of-work client > puzzles (when under duress) are also an option, but add complexity and > potential risks in regimes outside of client:server uses of TCP. > > Erik > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Fri May 2 08:34: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 7AD861A6F1E for ; Fri, 2 May 2014 08:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RP_MATCHES_RCVD=-0.651, 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 q1PY8WKTpRnv for ; Fri, 2 May 2014 08:34:47 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) by ietfa.amsl.com (Postfix) with ESMTP id D173E1A0A0D for ; Fri, 2 May 2014 08:34:47 -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 s42FYhR9003822; Fri, 2 May 2014 08:34:43 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s42FYh3i001849; Fri, 2 May 2014 08:34:43 -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: Daniel Kahn Gillmor , tcpcrypt@ietf.org In-Reply-To: <53631F36.4050700@fifthhorseman.net> References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362ABDA.9040608@isi.edu> <53631F36.4050700@fifthhorseman.net> Date: Fri, 02 May 2014 08:34:43 -0700 Message-ID: <8738gsyz1o.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/AewUbMbYS6ZLJZFOfzTGF4JK_jk 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-31 PDT List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:34:48 -0000 Daniel Kahn Gillmor writes: > I know i raised the fingerprinting concern earlier here, but i'm > concerned that this statement actually goes too far. "must not increase > information available for fingerprinting" implies that peers basically > cannot cache state between subsequent connections, which seems like an > obvious opportunity for performance improvements. Exactly. I'm worried that we are over-specifying stuff before we understand the design space or know the trade-offs. In particular, it turns out that TCP is pretty fingerprintable anyway (e.g., Kohno/Broido/Claffy) and adding a new option is only going to make that worse. (Hey, there's a reason my mail server, mail avenger, puts an abstract of the SMTP connection's SYN segment in a mail header.) So really the charter is too early a place to decide to resolve these trade-offs in favor of privacy. To my mind, the only thing that's really in scope for the charter is to say drafts should discuss their effects on fingerprinting. If different proposals facilitate fingerprinting to different extents, then this is one thing to take into account when weighing one proposal against another. My personal opinion is that we want to optimize for speed in the common case and ensure sufficient APIs are available that if people defeat all the other fingerprinting techniques (from TCP to HTTP-level stuff) TCP Inc. isn't the one thing left by which you can't avoid fingerprinting. But remember, the API document is only going to be informational anyway. So for all these reasons, putting language in the charter to the effect that TCP Inc. must not exacerbate fingerprinting is likely to gunk up the standardization process without necessarily yielding any improvement in privacy. By the way, this principal applies to most other aspects of the protocol. E.g., I see Erik Nygren brought up the issue of DoS resilience. That's a great point. I suspect we will find that DoS resilience is part of a complex four-way trade-off also involving normal-case fingerprint-resistance, minimizing use of option space in SYN segments, and minimizing connection latency. Do we really want the charter to prioritize fingerprint-resistance and option space over DoS resilience and latency? I'd rather line up a bunch of proposals and then decide the trade-offs. That means we should pick the minimum set of requirements. If it were up to me, I'd summarize the requirements in a mere three sentences: - In the absence of an active attacker, must provide forward secrecy between any two hosts that use it, with no configuration required. - For TCP-Inc.-aware applications, must provide endpoint authentication hooks that can guarantee forward secrecy and integrity of the TCP data stream against active attackers. - Must gracefully support incremental deployment over today's Internet. Beyond that, I'd say there are a bunch of desirable properties, and there are issues (like fingerprinting) that each draft must discuss. But we shouldn't place any further *requirements* on the design. David From nobody Mon May 5 06: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 6456D1A0326 for ; Mon, 5 May 2014 06:31:03 -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 oPknnxwXorJK for ; Mon, 5 May 2014 06:31:01 -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 080591A032D for ; Mon, 5 May 2014 06:31:00 -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 s45DUj4J015507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 May 2014 16:30:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s45DUhNB003564; Mon, 5 May 2014 16:30:43 +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: <21351.37507.317352.47211@fireball.kivinen.iki.fi> Date: Mon, 5 May 2014 16:30:43 +0300 From: Tero Kivinen To: Joe Touch In-Reply-To: <53611219.2030106@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> <21344.65512.465866.311361@fireball.kivinen.iki.fi> <53611219.2030106@isi.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 16 min Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/bi5aaisEp_NKRNI3MnpoQkjjt7w 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: Mon, 05 May 2014 13:31:03 -0000 Joe Touch writes: > > 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". That is not related to the rekey. For rekey each SA have separate replay windows, so that is not on issue there. I meant that if you have situation where the network commonly delays packets for 5 seconds and send them all out of order then that will quite often cause IPsec replay window to drop the packets which are too old. The IPsec replay window size is normally something like 32-128 packets so after you the peer has received that many newer packets it will drop the old packet when it arrives. > > 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. The normal case we were talking about is a rekey case, and rekey normally do not loose any packets. Replay window will drop packets in general (i.e. cases not related to rekey) if packets get too much out of order. Thats why IPsec architecture asks you to create separate SAs for cases where packets might get delayed different amounts. I.e. one IPsec SA per traffic class if you are doing class based QoS etc. IPsec rekey does not cause packets to be lost. Also TCP usually will already do actions when it sees that one packet has not been received for 5 seconds and there has been other newer packets coming in all the time (i.e. do SACK and that will cause the other end to retransmit the packet when it receives that information, and if both of the packets do arrive to the other end then later one of them is simply dropped, as TCP has already received the earlier one). Anyways I think we are getting quite far away from the charter text. -- kivinen@iki.fi From nobody Mon May 12 11:47: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 AB0281A077C for ; Mon, 12 May 2014 11:47:48 -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 JW1-PH3pSCzP for ; Mon, 12 May 2014 11:47:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE11A0782 for ; Mon, 12 May 2014 11:47:47 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4CIlIIY013661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 May 2014 11:47:22 -0700 (PDT) Message-ID: <53711737.9070906@isi.edu> Date: Mon, 12 May 2014 11:47:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tcpcrypt@ietf.org" References: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> In-Reply-To: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> 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/70SgOR4nvWeXIuq6CEfXMF35Tnc Subject: [Tcpcrypt] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-01.txt 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, 12 May 2014 18:47:48 -0000 FYI. This version includes in-band unsigned Diffie-Hellman exchange (BTNS-mode). Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcp-ao-encrypt-01.txt Date: Mon, 12 May 2014 11:43:57 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-touch-tcp-ao-encrypt-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcp-ao-encrypt Revision: 01 Title: A TCP Authentication Option Extension for Payload Encryption Document date: 2014-05-12 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt/ Htmlized: http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcp-ao-encrypt-01 Abstract: This document describes an extension to the TCP Authentication Option (TCP-AO) to encrypt the TCP segment payload in addition to providing TCP-AO's authentication of the payload, TCP header, and IP pseudoheader. This extension augments how the packet contents and headers are processed and which keys are derived, and adds a capability for in-band coordination of unauthenticated Diffie- Hellman key exchange at connection establishment. The extension preserves key rollover coordination and protection of long-lived connections. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon May 12 11:56: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 912531A076F for ; Mon, 12 May 2014 11:56:12 -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 I_ejOxo5zUsK for ; Mon, 12 May 2014 11:56:10 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id EE83B1A075C for ; Mon, 12 May 2014 11:56:09 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D0640D1C9F3 for ; Mon, 12 May 2014 20:56:02 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (252.172.78.188.dynamic.jazztel.es [188.78.172.252]) (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 A6B56CC5E3A for ; Mon, 12 May 2014 20:56:02 +0200 (CEST) Message-ID: <53711942.4070604@it.uc3m.es> Date: Mon, 12 May 2014 20:56:02 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.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-20690.001 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/gf-5yz9T11uKv5rcrdp4zhPsY7g Subject: [Tcpcrypt] status update 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, 12 May 2014 18:56:12 -0000 Hi, just to let you know the status. I am planning to produce a new version fo the charter incorporating the last round of discussions early next week. Hopefully we can submit this one to the iesg. Regards, marcelo From nobody Mon May 19 06:29: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 B31241A0319 for ; Mon, 19 May 2014 06:29:03 -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 KoyV5HD6iTHm for ; Mon, 19 May 2014 06:28:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF2A1A00A3 for ; Mon, 19 May 2014 06:28:59 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5F7A411C1FA1 for ; Mon, 19 May 2014 15:28:57 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (252.172.78.188.dynamic.jazztel.es [188.78.172.252]) (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 22CF49D2BB3 for ; Mon, 19 May 2014 15:28:57 +0200 (CEST) Message-ID: <537A0718.7030603@it.uc3m.es> Date: Mon, 19 May 2014 15:28:56 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.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-20702.006 X-TM-AS-Result: No--22.957-7.0-31-1 X-imss-scan-details: No--22.957-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/967zCCe365B72C-Kz2NYei4Oa-0 Subject: [Tcpcrypt] Charter submitted to the IESG 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, 19 May 2014 13:29:03 -0000 Hi, I have just submitted the attached draft to the IESG for consideration. Thank you all very much for the useful discussions. Hope to start soon the more technical discussions. 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 during the initial unathenticated key exchange. 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: - It should work over the vast majority of paths that unmodified TCP works over, 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, including acceptable latency and processing overheads. 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 the initiator of the connection to avoid fingerprinting: some initiators may want to avoid appearing as the same endpoint when connecting to a remote peer on subsequent occasions. This should either be the default or some mechanism should be available for initiators 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.