From nobody Mon Aug 1 03:28:45 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C3D12D53B for ; Mon, 1 Aug 2016 03:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7rrTF7ylnvw for ; Mon, 1 Aug 2016 03:28:43 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0DE12D13F for ; Mon, 1 Aug 2016 03:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2095; q=dns/txt; s=iport; t=1470047323; x=1471256923; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=rmY13vAgslI51glvtCbn04zLy9HTVBsirQGDKMXY3yc=; b=kz/+bDIpCGm7ykW61obZndebdrcZNK7l29QAS+25pQthK4PDGcXMIE5U 41+bzWkDuLRfaEKS+Glcn5AGwv2DdCasZC19aa0LqV0Tm6NLMFN60/BSg XtOUDMKuk6gsqfuWcbv4act2m1qi1fQ7iDgEuZWx6rwE//qktfMde7Nbk o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACFI59X/xbLJq1dhEW7YIYdAoF3A?= =?us-ascii?q?QEBAQEBXieEXwEFI2YLGCoCAlcGAQwIAQGILbEfj1sBAQEBAQEBAwEBAQEBAQE?= =?us-ascii?q?SDogiglWHQYJaAQSZM4M6gXCJVYFVAYd9hWyQJ1SDfDqJAwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,454,1464652800"; d="asc'?scan'208";a="640660352" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 10:28:41 +0000 Received: from [10.61.221.80] ([10.61.221.80]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u71ASemo022088; Mon, 1 Aug 2016 10:28:41 GMT To: Christian Huitema , Brian Trammell , spud , "privsec-program@iab.org" References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Eliot Lear Message-ID: <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> Date: Mon, 1 Aug 2016 12:28:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DH49R9Cmt3t8xrjFWjMdxUMxKN1dtlo7V" Archived-At: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:28:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DH49R9Cmt3t8xrjFWjMdxUMxKN1dtlo7V Content-Type: multipart/mixed; boundary="HlAMCjlfsUtg9puxO00DMC8oqfEw3BwKh" From: Eliot Lear To: Christian Huitema , Brian Trammell , spud , "privsec-program@iab.org" Message-ID: <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> Subject: Re: [Privsec-program] [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> In-Reply-To: --HlAMCjlfsUtg9puxO00DMC8oqfEw3BwKh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, On 7/31/16 10:10 PM, Christian Huitema wrote: > The draft mentions the IPv6 flow-ID, but creative intermediaries might > also manipulate the TOS fields, so maybe there should be a subsection > describing that too. Just so that we're clear, the TOS fields, and in particular DHCP were designed so that they could be overwritten (mostly erased), as required, by intermediaries. Eliot --HlAMCjlfsUtg9puxO00DMC8oqfEw3BwKh-- --DH49R9Cmt3t8xrjFWjMdxUMxKN1dtlo7V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXnyRYAAoJEIe2a0bZ0nozjAQIAJnqmlRB2vrnIdo12ww7Simf sye4tHjxAwRllAPzE9DFHZ9baGVPpaQ959k4E+HP0DnJP8/pSLhWPTHkDB1bo1G7 La23NmMivaTuamlQNoU+fYajUv+6og0oFpFaB9DnZELjjNVPtDo1/GNoMyQRbyHA aYFcxMYiYL/NyWTLQ7A2gGvsM0VL4A7d2Wy6ZBO2xpykrNtEc5njob4MbGAF7E9u dQh1JHp8EwiMOsPV5e6Djpv9/H0jC1kjExmAjKVK6T7Z/aX05zl21dc1Rx25iDj2 WCRKRwSzaAJ7qTAgPBjNxj65TumA4AXYsadWYhG6dBq5Yk8EPKpsCyHtaynLR58= =gqWd -----END PGP SIGNATURE----- --DH49R9Cmt3t8xrjFWjMdxUMxKN1dtlo7V-- From nobody Mon Aug 1 07:01:22 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42CC12DC08 for ; Mon, 1 Aug 2016 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ5HMjz33lwI for ; Mon, 1 Aug 2016 07:00:57 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1CB12DB12 for ; Mon, 1 Aug 2016 06:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2254; q=dns/txt; s=iport; t=1470059795; x=1471269395; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=S/eO0FHZVNPP5ItzUOYXfZFBsBEvMYkWEjhbox2IcuU=; b=jQgwtyVezA69/NvxVrn+VUC/QH78deT4CSaQJ1H6TxsJWgqQgBpRSf1p CD0nm4A9y3/6D82YcuWIT5myG+T2nyYJV7pX0FX73Mt5RObq6MEpFOS3/ WDP+7OTKViUHPeqpKWJQv7omBkfOeQuM6y8IOTHtKZButZ6boojIPyDGE s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACOVJ9X/xbLJq1dhEW7YoYdAoF5A?= =?us-ascii?q?QEBAQEBXieEXwEFI2YLGCoCAlcGAQwIAQGILbBkj2ABAQEBAQEEAQEBAQEBARI?= =?us-ascii?q?OiCKCVYdBgloBBJkzgzqBcIlVgVWHfoVskCdUg3w6iEcBAQE?= X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="asc'?scan'208";a="638871161" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 13:56:33 +0000 Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u71DuWiW009444; Mon, 1 Aug 2016 13:56:32 GMT To: Christian Huitema , Brian Trammell , spud , "privsec-program@iab.org" References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> From: Eliot Lear Message-ID: Date: Mon, 1 Aug 2016 15:56:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X0gD153PIUB7M9jIM8Vqhj7Ft3slO4EKl" Archived-At: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:01:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X0gD153PIUB7M9jIM8Vqhj7Ft3slO4EKl Content-Type: multipart/mixed; boundary="3fkqT0qXtOVToC9aT3vhKn6rjEesHLemQ" From: Eliot Lear To: Christian Huitema , Brian Trammell , spud , "privsec-program@iab.org" Message-ID: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> In-Reply-To: <93554b11-ade5-63fe-7cd9-c0a7582732dd@cisco.com> --3fkqT0qXtOVToC9aT3vhKn6rjEesHLemQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christain points out to me that I have DHCP on the brain: On 8/1/16 12:28 PM, Eliot Lear wrote: > Hi Christian, > > > On 7/31/16 10:10 PM, Christian Huitema wrote: >> The draft mentions the IPv6 flow-ID, but creative intermediaries might= >> also manipulate the TOS fields, so maybe there should be a subsection >> describing that too. > Just so that we're clear, the TOS fields, and in particular DHCP were > designed so that they could be overwritten (mostly erased), as required= , > by intermediaries. > s/DHCP/DSCP/ Eliot --3fkqT0qXtOVToC9aT3vhKn6rjEesHLemQ-- --X0gD153PIUB7M9jIM8Vqhj7Ft3slO4EKl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXn1UQAAoJEIe2a0bZ0noz1b0H/2CbcFR3rmwWonsq6f1hm5nS wV68+TkYLRDAymewLCla2jrtfD0zz9wwVMfeFxy1Icn9LZG70vHG755fXWZY3DyA bmTXk81YaDuYbhkSqAL+IShFVo3FB+KgAciZavM63P7KLpmYngAUzEoXRMgjC5xj 80EWoiwmvR3PFEkTkGNbgNGNuj7eiFSqmnra7YWOT7MUQ27KAEy5f8d1sLV6G43o Ra9NRMpUYQCMMcJ7R0yYjFP0wTFcZkpR9btH7AopZV72y9CgjHDAKF1VG1QGUFbk HYZkMDtEHURns+ugDyL2JEFqEible1/oS5KF1RAGiclpGgKHF3i77zBpQhQK3r4= =/brn -----END PGP SIGNATURE----- --X0gD153PIUB7M9jIM8Vqhj7Ft3slO4EKl-- From nobody Mon Aug 1 07:59:30 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D088512D9C4 for ; Mon, 1 Aug 2016 07:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXYKQOr2Fnxa for ; Mon, 1 Aug 2016 07:59:27 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E172012D594 for ; Mon, 1 Aug 2016 07:59:26 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so185149901ioi.2 for ; Mon, 01 Aug 2016 07:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dnRBIbtGQcTCq/70oS6jjKziPhrqeRLrZ6deeLsGvQ0=; b=eV9RQrTzuxctKA+Lc8JZOWA8XiVB6IO8Yu7BymFKguKK1B8y0dEuS+xe5IuNDkANHN 13DfBKVfMTfLdB27qk/c9cZKVavfehK0BdE6vrhXhjqFcKRHkW6qfL7OQAsoHT9h87nJ swjSqKF1Jmsv7hDJW2hbz2QAAKQWOa8AotVEzdo8DpafeWTkuc0CZtJMS0SeV/RVNLEk l/KbQmr3cNhaKaMCG5i0fm93M7aFCIWuZdUYmNVaUgcXye7bFZmQOOG1KN3PpiFt9XGZ mBAKLI/1OoaJ0Dos1uJee52MthYgt6EIom1iP6fSBd0CZjBvHt0xp0HwuHkLN7BwUEoa GHXQ== 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:from:date :message-id:subject:to:cc; bh=dnRBIbtGQcTCq/70oS6jjKziPhrqeRLrZ6deeLsGvQ0=; b=cuVoAkMYcFgPEmQFfZBXb7oV8avGLKTv88D0+GYoR2kAN4eiZxPPs2aKcqfZ8Rw0qm LiZNeaQz1eMw5FE3ln6xoRhxAWaIaootGAOHbaIeylEXGOOe/D8s9hRtnEf0SAgN3/Rs OSA+bTQLH54wqy90XrJs66i7xpKieJNeigMR9YhmKv9MU/LJOKsMxJ7wPrhKfEMrg6Mx NtaTqyUy14afoyIY1XTfV5QwvHdDnQR70MMe9XbNPIOEzkIzWq5sBgBQLFJ93BzOoXto vAVfQp5VuwGlzxIl6BaJN6E1K82yv5MVIVUVr9Mzrw+ZBOhNZ+22WsqwkviG0oQHcJWw IpjQ== X-Gm-Message-State: AEkoouv0nFtcvhZjPSKzl2iL4tJxBWo89Khm+5rtu5Cyx8tSv6P1rrAhnMbtdAwt8VBySBp2ogI1vh+ZMgw/Lg== X-Received: by 10.107.25.75 with SMTP id 72mr57414920ioz.50.1470063566128; Mon, 01 Aug 2016 07:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 07:59:24 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Tom Herbert Date: Mon, 1 Aug 2016 07:59:24 -0700 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Stephan Neuhaus , Stephen Farrell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud , Brian Trammell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:59:29 -0000 On Sun, Jul 31, 2016 at 11:34 PM, Eliot Lear wrote: > > > On 7/30/16 9:59 PM, Tom Herbert wrote: >> >> No, it's not. In fact, exposing flow start/stop information is a good >> example of something that facilitates intrusiveness by middleboxes at >> the transport layer. >> >> The purpose of exposing this information is to allow network devices >> to track connections, but connection tracking in the network is >> fundamentally flawed since there is no requirement that all packets of >> a connection go any single network device (i.e. the Internet is packet >> switched not circuit switched). > > Except that I will bet you that over 99.999% of connections do, and that > this is particularly sufficient for home routers. > Eliot, If that number it is correct it is only because home routers have ossified the Internet in that regard, not because the standard was ever changed to require it. Desktops sitting behind home routers is no longer a sufficient model for the Internet; mobile devices are currently predominant and the Internet needs to adapt accordingly. Consider that mobile devices are multihomed having at least two network connections. We want the ability to seamlessly switch between networks (say from wifi to mobile) or between mobile networks as we drive down the road. Performing 3WHS is very expensive on mobile (literally for some of our users), so we need connections to survive across these path changes. If we hide the transport layer from the network devices (e.g. from home routers) then they can't enforce the single path assumption. In fact, once we disassociate location (addressing) from connection endpoint identification (like described in TOU) then connections should be able survive even across an address change and between two completely providers. This is of huge value to our users and IMO justifies encrypting the transport layer. Tom From nobody Mon Aug 1 08:09:03 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15F12DA16 for ; Mon, 1 Aug 2016 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.809 X-Spam-Level: X-Spam-Status: No, score=-15.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlNpCyxYsGnD for ; Mon, 1 Aug 2016 08:09:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D574512DC41 for ; Mon, 1 Aug 2016 08:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4539; q=dns/txt; s=iport; t=1470064139; x=1471273739; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FZn5rD/VwL1NZj7HoZcSLsZntW/sGbZaRdLJLzf2P9g=; b=EIc+KWZOFj2MEjnVCQgKVvE84CwlntN8ud0/ycInfCBo32adkALTNDaR oRazEa/miijVfCHIBvYY442d15D72kRevarXzBCmJ42wZt8uPptnejQYe Zk+Z+JsEp3HzNJurKZasWdsJEPGsMApaDPAVAaS8qkCMIT5ijNROXA5w6 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADkZJ9X/xbLJq1dhEW7YoYdAoFoE?= =?us-ascii?q?QEBAQEBAQFdJ4RfAQUjVhALGCoCAlcGDQgBAYgtsGyPaAEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBEg6IIoJVh0GCWgEEmTODOoFwiVWJU4VskCc0IIN8OohHAQEB?= X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="asc'?scan'208";a="680415254" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 15:08:57 +0000 Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u71F8vWt008352; Mon, 1 Aug 2016 15:08:57 GMT To: Tom Herbert References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Eliot Lear Message-ID: Date: Mon, 1 Aug 2016 17:08:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wJ9fXFAS74nTNFbakANxabDwaCNrPGcQH" Archived-At: Cc: Stephan Neuhaus , Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud , Brian Trammell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:09:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wJ9fXFAS74nTNFbakANxabDwaCNrPGcQH Content-Type: multipart/mixed; boundary="xT0JlIfo4L9v9IS8U9wCGUcQXxDbfH1ln" From: Eliot Lear To: Tom Herbert Cc: Stephan Neuhaus , Brian Trammell , Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: --xT0JlIfo4L9v9IS8U9wCGUcQXxDbfH1ln Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey Tom, On 8/1/16 4:59 PM, Tom Herbert wrote: > If that [99.999%] number it is correct it is only because home routers = have > ossified the Internet in that regard I realize that people have ossification on the head, but I'm sure you recognize that the right answer here is that most people only have a single connection into their homes. For those who have more than one, the two either are disconnected networks or they come together in the same box. We do not have the routing infrastructure today in place to multihome to your laptop/iPhone/tablet/Android/FB phone, something I deeply regret we have not yet worked out. Maybe some day. > , not because the standard was > ever changed to require it. Desktops sitting behind home routers is no > longer a sufficient model for the Internet; mobile devices are > currently predominant and the Internet needs to adapt accordingly. > > Consider that mobile devices are multihomed having at least two > network connections. We want the ability to seamlessly switch between > networks (say from wifi to mobile) or between mobile networks as we > drive down the road. Performing 3WHS is very expensive on mobile > (literally for some of our users), so we need connections to survive > across these path changes. If we hide the transport layer from the > network devices (e.g. from home routers) then they can't enforce the > single path assumption. In fact, once we disassociate location > (addressing) from connection endpoint identification (like described > in TOU) then connections should be able survive even across an address > change and between two completely providers. This is of huge value to > our users and IMO justifies encrypting the transport layer. But the way this is done is through multiple pesistent transport connections bound off of separate L3 local addresses. We have attempted to do otherwise through MIPv6 and LISP-MN. Not widely deployed, and even were they so, it is probably sufficient for something like the LISP header to be above PLUS (think about that until you're 103)! Eliot --xT0JlIfo4L9v9IS8U9wCGUcQXxDbfH1ln-- --wJ9fXFAS74nTNFbakANxabDwaCNrPGcQH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXn2YJAAoJEIe2a0bZ0nozbDsH/iFJC7v4p8aUI+SfF4X5AUUn nVV8HbNvzjJq+km9MYhoS6Y82vdqVA0ZlAfeybPhkjpSjtVATs6ipUaAvdBk/A0N 8kbTRpXD+whogU4t7YTg1bxPE4tiYWfcbcwwaz9JBmm/SX6K5R6qhmKV0+ZK+39k 2V6IjFBXw0A4FsB7ZwyGLIZHCvWJp7Pg3QJoGp3bByPYMrrnI7UAGtj/HAtDDxNK oD08pd8QEGFr8FD8Tr8Qs+4q+6G+TOgGpWxDdTM/3iDN24ETjUmGRrCMkNCj/rcI sGpW59N3Sx8Ri8MwGOia7ljDUn6Kbjx10qS8SgoJOQuua9bJZGJSm9lfDhFTOtE= =1YDb -----END PGP SIGNATURE----- --wJ9fXFAS74nTNFbakANxabDwaCNrPGcQH-- From nobody Mon Aug 1 08:56:06 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162FB12D0D3 for ; Mon, 1 Aug 2016 08:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOiuFZNZc_aW for ; Mon, 1 Aug 2016 08:56:04 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08D912B044 for ; Mon, 1 Aug 2016 08:56:03 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f6so249252846ith.1 for ; Mon, 01 Aug 2016 08:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DBS17KeJoJtZWyAcX6V4rwJk/jlNKKnr7GAU7gtTxi0=; b=TgwSNUzDtJk1PSSxruq6iarL6mccvPM/R7YnVdCOSdXqZeaMCig7imWj0VssIUSMSY NnF9AAaBWs2RXM5jprtBGP55nWVAY+gV9DWRGz9kRwB+AoRZ0rXG3ATAmXVWM4Hdgb+N sL/CSi62ZNZOp98m20zWjnvBR/O/eYfv2Ua/8NARce9maO+fHB/m3hbgvukTLaQ0KC1k VyqzcZ7KifMEXd7/qHR39NqnlqEAugge6K+ZLSBe2NLrikUdbN00F/07s3wMWgIdRigt b2FVj1Fow7mfmYOn3ycTqK1u5R7rUhLyp4Hc0Lb69/NzIPbUjgft+7l6oKRMAteTsDtM NyjA== 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:from:date :message-id:subject:to:cc; bh=DBS17KeJoJtZWyAcX6V4rwJk/jlNKKnr7GAU7gtTxi0=; b=hnsPTzhZwgfcgXnDuRb3BU4UZDuMWGF461VFsTcugoHee79hu9IDPlB7OM/PAVp84e RlviD+tnmdh2F2EknvlLxXu6Re++sYSetQ72Q638wMXyx/VlAwtG2/c8U2SWlXA43b5V hjlm/88i3VBxlJreagneiB+kv3YQWVldD6Lo6+fK0Bm03ejON3//foewEq1Mw4M82zGb HmF6p3elkH9XG6hm8MZdu6bRD7/Qwp4ELaHgW5BPZHRjJdxC1i6cfE1YbACcLi0PgB9K fbtcX2X0TACvHI1S/3bfiIryt8qDDkLdxw+Py8M6l2UVdOHoDB4FEb/LSRLRZtuOZGOw NPdg== X-Gm-Message-State: AEkoousFwzcs/uvt6CiqHaUWrVguvt6iKRRcV1h6+wDPhODKgi4eQ24ztGDRaKEmQ1Vsnvj5ZibKDBM5hh/HTg== X-Received: by 10.36.14.193 with SMTP id 184mr60324089ite.91.1470066963226; Mon, 01 Aug 2016 08:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 08:56:01 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Tom Herbert Date: Mon, 1 Aug 2016 08:56:01 -0700 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Stephan Neuhaus , Stephen Farrell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud , Brian Trammell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:56:05 -0000 > On 8/1/16 4:59 PM, Tom Herbert wrote: >> If that [99.999%] number it is correct it is only because home routers have >> ossified the Internet in that regard > > I realize that people have ossification on the head, but I'm sure you > recognize that the right answer here is that most people only have a > single connection into their homes. For those who have more than one, Well, I'm sitting here in my home looking at my Nexus 6 and I can confirm that it is attached to Internet my via Comcast wifi as well as Verizon's mobile network. So my smart phone is definitely a multihomed and I definitely have multiple connections into my home. Right now I'm using the wifi link, but if I walk into my backyard out of range then I don't want the device to have to restart all my TCP connections when switching to the mobile network. Neither do I want to have to create 2x connections like in MP-TCP just because I might at some point walk into my back yard (it's kind of gloomy right now so I don't think I'll be doing this anyway). > the two either are disconnected networks or they come together in the > same box. We do not have the routing infrastructure today in place to > multihome to your laptop/iPhone/tablet/Android/FB phone, something I > deeply regret we have not yet worked out. Maybe some day. > We don't need routing infrastructure to change and we are really not asking for any changes in the network other than they forward UDP packets, respect E2E protocols, and otherwise implement the Internet standard. The transport layer is being changed to facilitate multihoming. Please look at connection identifiers in QUIC and disassociated location in TOU ( draft-herbert-transports-over-udp) to see how this is being done. > >> , not because the standard was >> ever changed to require it. Desktops sitting behind home routers is no >> longer a sufficient model for the Internet; mobile devices are >> currently predominant and the Internet needs to adapt accordingly. >> >> Consider that mobile devices are multihomed having at least two >> network connections. We want the ability to seamlessly switch between >> networks (say from wifi to mobile) or between mobile networks as we >> drive down the road. Performing 3WHS is very expensive on mobile >> (literally for some of our users), so we need connections to survive >> across these path changes. If we hide the transport layer from the >> network devices (e.g. from home routers) then they can't enforce the >> single path assumption. In fact, once we disassociate location >> (addressing) from connection endpoint identification (like described >> in TOU) then connections should be able survive even across an address >> change and between two completely providers. This is of huge value to >> our users and IMO justifies encrypting the transport layer. > > But the way this is done is through multiple pesistent transport > connections bound off of separate L3 local addresses. We have attempted > to do otherwise through MIPv6 and LISP-MN. Not widely deployed, and > even were they so, it is probably sufficient for something like the LISP > header to be above PLUS (think about that until you're 103)! > Those some of the possible ways to do handle multihoming, but by no means does this define the complete solution space. There is still room for innovation in alternatives as I pointed out above. Tom From nobody Mon Aug 1 11:57:37 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10312D794 for ; Mon, 1 Aug 2016 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFgqlzmEqS9S for ; Mon, 1 Aug 2016 11:57:28 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC3A12D103 for ; Mon, 1 Aug 2016 11:57:27 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w18so205562077oiw.3 for ; Mon, 01 Aug 2016 11:57: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; bh=AwT2O2wqVWvyUJYJc1/TELeHTJ1bhCXj5WeZSzPZe+E=; b=049n9C52wfUy5sWRIWl+9++Csx0WHklJvFw31HNxpOkMcyZHtjURPD/5DOO5LXZ0Rg tGaK5AhMGLFRZSA0d0cv+4sH8AFOZRRkn3mjb5GuOzWRoZ4nlOcrvOLKk52AXfBC5iyl 362mr7LP02GsDDp0O+mKGBc0xzWSngtAic+1VBdzlRfStx6KlTLOTVfFmMlN7pHIZ0pY 2IPNzcuqDbZgBl5nyLSs80y/wHbl41Cw8V0cumd9U3g+Wn8Lye/MNrZZZHaOtqHa23J4 OtIKnrJmH16CYdHdW01Syj3TZeK0eJrbJyOeDosZk5m5kHqQC9DuOm8kdX1EygyPkm2U Vw8A== 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:from:date :message-id:subject:to:cc; bh=AwT2O2wqVWvyUJYJc1/TELeHTJ1bhCXj5WeZSzPZe+E=; b=bYblAOFnZHdExAsfLxw3EB/dtLGxizrwjRAfg5VSaaYQbT/k+4fpnioqTcUSEy3lSe gWsVotHCqCHvltLdlwT+0G/8paS2osQ20R0lVH6nR2gTUOdn22RpL3li13v3D+PQFBYa HNf+a8gxTv1fFo4FTcN76tlghXk/UwyEBo8ubbarXHjefwQlvJcXf9nuC8y2vuj5DWgJ /U5kqgblCJZq9tZwpEYG/u8mYMF0aQftyxTIaQS0MZVQvZ+aLhVC3nqRq2MUVjJhDryq Um23slQmoU2HeFtescznX7WNS7cbRynImPZtlNar8p/Xt1aiaJegx00PuwZkFqfLasfN 3CqA== X-Gm-Message-State: AEkooutQwgDXkHCXAZeCJ+HE3uqdrNdSE+/99h1sUT1PrZ35mt2ENdLoLz5l5YDojXEHbP3YOcY0qiaukrHBvA== X-Received: by 10.202.218.215 with SMTP id r206mr32267932oig.55.1470077847046; Mon, 01 Aug 2016 11:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Mon, 1 Aug 2016 11:56:57 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> From: Ted Hardie Date: Mon, 1 Aug 2016 11:56:57 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113d2b78dd90a00539072b19 Archived-At: Cc: Brian Trammell , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Tuexen Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:57:30 -0000 --001a113d2b78dd90a00539072b19 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell < > > IMO that case has not been made to the point where I would > consider it justifies privacy downsides. IOW, while I am of > course in favour of endpoints being able to signal to one > another without middlebox interference, I am not at all on > side with transport header integrity being counted as a major > win in the analysis of PLUS, if that "win" inherently requires > a significant privacy cost. (And I am clearly happy to endlessly > repeat myself that in this particular case: > > extensibility == privacy unfriendly > > Stephen, someone naively coming across this statement in the record will think you mean that any extensibility is privacy unfriendly. Obviously, you have championed the ability to shift cryptographic algorithms as needs change, which requires extensibility of specific forms. Lots of other work requires extensibility to be useful at all (imagine if the tag space of the web had been frozen in 1993). I should greatly appreciate you reformulating this into something that actually matches your meaning. That would likely be useful; this is not. thanks, Ted --001a113d2b78dd90a00539072b19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell <

IMO that case has not been made to the point where I would
consider it justifies privacy downsides. IOW, while I am of
course in favour of endpoints being able to signal to one
another without middlebox interference, I am not at all on
side with transport header integrity being counted as a major
win in the analysis of PLUS, if that "win" inherently requires a significant privacy cost. (And I am clearly happy to endlessly
repeat myself that in this particular case:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 extensibility =3D=3D privacy unfriendly


Stephen, someone naively coming across this statement in the recor= d will think you mean that any extensibility is privacy unfriendly.=C2=A0 O= bviously, you have championed the ability to shift cryptographic algorithms= as needs change, which requires extensibility of specific forms.=C2=A0=C2= =A0 Lots of other work requires extensibility to be useful at all (imagine = if the tag space of the web had been frozen in 1993).

I should greatly appreciate you reformulating this into = something that actually matches your meaning.=C2=A0 That would likely be us= eful; this is not.

thanks,

<= /div>
Ted
--001a113d2b78dd90a00539072b19-- From nobody Mon Aug 1 12:56:54 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E22712D60D for ; Mon, 1 Aug 2016 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSWHYyMF0S6F for ; Mon, 1 Aug 2016 12:56:50 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D6E126579 for ; Mon, 1 Aug 2016 12:56:50 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u134so182641802ywg.3 for ; Mon, 01 Aug 2016 12:56: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; bh=fG0QxlxNyNF2ip9mYK2Vu58RaZzSWzZ32ohrCf0AYms=; b=uBLhQWUVN4Aip0vllvA5AIY+ICnvGCWW1g+zBqkPxkTYRjkyviTYx9rGbxuYfykwGM jxMtkv58dh6cm0Rr5P4bzFaoGotv5iiwMdLJThUcv0tGJTDykKEr2SiASPhyDPSkdUh6 RozL8I4PCfgPcF/LIBKU57AlHw31zHMkNaPkBuJVOdw51lVMbR5IBGVNGsocmVwEBMxK 55WeXwgMZyesbXu9/K6OSvY1Mha6GhOrENVt4NWdqQV/cN+Adqhcsu5zCBlT6SzMR3+5 TkeR0TZP8XkJGL+SEHunFoS7AbDJfOA/uLTz5PfGKIlVQXFcw6S11XBScXPWaa0sXnEF YU6Q== 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:from:date :message-id:subject:to:cc; bh=fG0QxlxNyNF2ip9mYK2Vu58RaZzSWzZ32ohrCf0AYms=; b=K92Oujq9+a+2XENhEx1mp+d72weD/9S0ovRlvrf+r46hu7B6+2XcrRZKcFqh2Vl/OI vewoeuZNUnd2+F3B7AfIp5FyQh4ixvppGil5UMe3609aRmJdiBHGqMd/6S8u/WvUfmD/ fV1wpqAXvp95ByS4sgMYzX5y3aHSf1SIDVH3mi0I0fimllA2RIwz8LMSEe/rrt0+RVk5 PJ5GjYWOSsW0tKojdta2/CvjkHLxXS4i4M5bXY1qYocEaGBgIAmIhvFJ86ZzEQFjrpil Yn2HJoe7vyAtKhqvEuKlcY5rFTJfN56n5Lx6ybKtwTLpPV+AkBEHfhMvKzZzA811gUfn 3WRA== X-Gm-Message-State: AEkoouvRo6hHlqD9MRGnUFnu6cLhUoStomAm1l8P/F/V7jVDNYiHICa2HJYQimtwUXi82y5AWT8tDIrvmNm1nA== X-Received: by 10.37.60.67 with SMTP id j64mr9462545yba.111.1470081409495; Mon, 01 Aug 2016 12:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.132 with HTTP; Mon, 1 Aug 2016 12:56:48 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Spencer Dawkins at IETF Date: Mon, 1 Aug 2016 14:56:48 -0500 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114bdd4c343f970539080012 Archived-At: Cc: Eliot Lear , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Stephan Neuhaus , Brian Trammell , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 19:56:53 -0000 --001a114bdd4c343f970539080012 Content-Type: text/plain; charset=UTF-8 Hi, Tom, On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert wrote: > > On 8/1/16 4:59 PM, Tom Herbert wrote: > >> If that [99.999%] number it is correct it is only because home routers > have > >> ossified the Internet in that regard > > > > I realize that people have ossification on the head, but I'm sure you > > recognize that the right answer here is that most people only have a > > single connection into their homes. For those who have more than one, > > Well, I'm sitting here in my home looking at my Nexus 6 and I can > confirm that it is attached to Internet my via Comcast wifi as well as > Verizon's mobile network. So my smart phone is definitely a multihomed > and I definitely have multiple connections into my home. Right now I'm > using the wifi link, but if I walk into my backyard out of range then > I don't want the device to have to restart all my TCP connections when > switching to the mobile network. Neither do I want to have to create > 2x connections like in MP-TCP just because I might at some point walk > into my back yard (it's kind of gloomy right now so I don't think I'll > be doing this anyway). I'm not going to guess what wireshark would show on your home network or on Verizon's, but I'm having a hard idea understanding how a TCP connection identified by a 5-tuple that includes a local address from your wifi routed through Comcast stays active when you get in a car and drive away, so that the only active interface on your smart phone now has a local address that is routed through Verizon. Mine don't (admittedly, mine are Comcast and T-Mobile), but. When I walk to my car and get away, streaming media I was listening to in the house stops when I run out of wifi range. Are you sure you're not using (for instance) applications which open new TCP connections periodically? Spencer > > the two either are disconnected networks or they come together in the > > same box. We do not have the routing infrastructure today in place to > > multihome to your laptop/iPhone/tablet/Android/FB phone, something I > > deeply regret we have not yet worked out. Maybe some day. > > > We don't need routing infrastructure to change and we are really not > asking for any changes in the network other than they forward UDP > packets, respect E2E protocols, and otherwise implement the Internet > standard. The transport layer is being changed to facilitate > multihoming. Please look at connection identifiers in QUIC and > disassociated location in TOU ( draft-herbert-transports-over-udp) to > see how this is being done. > > > > >> , not because the standard was > >> ever changed to require it. Desktops sitting behind home routers is no > >> longer a sufficient model for the Internet; mobile devices are > >> currently predominant and the Internet needs to adapt accordingly. > >> > >> Consider that mobile devices are multihomed having at least two > >> network connections. We want the ability to seamlessly switch between > >> networks (say from wifi to mobile) or between mobile networks as we > >> drive down the road. Performing 3WHS is very expensive on mobile > >> (literally for some of our users), so we need connections to survive > >> across these path changes. If we hide the transport layer from the > >> network devices (e.g. from home routers) then they can't enforce the > >> single path assumption. In fact, once we disassociate location > >> (addressing) from connection endpoint identification (like described > >> in TOU) then connections should be able survive even across an address > >> change and between two completely providers. This is of huge value to > >> our users and IMO justifies encrypting the transport layer. > > > > But the way this is done is through multiple pesistent transport > > connections bound off of separate L3 local addresses. We have attempted > > to do otherwise through MIPv6 and LISP-MN. Not widely deployed, and > > even were they so, it is probably sufficient for something like the LISP > > header to be above PLUS (think about that until you're 103)! > > > Those some of the possible ways to do handle multihoming, but by no > means does this define the complete solution space. There is still > room for innovation in alternatives as I pointed out above. > > Tom > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a114bdd4c343f970539080012 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tom,

On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert <= tom@herbertland.co= m> wrote:
= > On 8/1/16 4:59 PM, Tom Herbert wrote:
>> If that [99.999%] number it is correct it is only because home rou= ters have
>> ossified the Internet in that regard
>
> I realize that people have ossification on the head, but I'm sure = you
> recognize that the right answer here is that most people only have a > single connection into their homes.=C2=A0 For those who have more than= one,

Well, I'm sitting here in my home looking at my Nexus 6 and I ca= n
confirm that it is attached to Internet my via Comcast wifi as well as
Verizon's mobile network. So my smart phone is definitely a multihomed<= br> and I definitely have multiple connections into my home. Right now I'm<= br> using the wifi link, but if I walk into my backyard out of range then
I don't want the device to have to restart all my TCP connections when<= br> switching to the mobile network. Neither do I want to have to create
2x connections like in MP-TCP just because I might at some point walk
into my back yard (it's kind of gloomy right now so I don't think I= 'll
be doing this anyway).

I'm not going to= guess what wireshark would show on your home network or on Verizon's, = but I'm having a hard idea understanding how a TCP connection identifie= d by a 5-tuple that includes a local address from your wifi routed through = Comcast stays active when you get in a car and drive away, so that the only= active interface on your smart phone now has a local address that is route= d through Verizon.

Mine don't (admittedly, min= e are Comcast and T-Mobile), but. When I walk to my car and get away, strea= ming media I was listening to in the house stops when I run out of wifi ran= ge.

Are you sure you're not using (for instanc= e) applications which open new TCP connections periodically?

=
Spencer
=C2=A0
> the two either are disconnected networks or they come to= gether in the
> same box.=C2=A0 We do not have the routing infrastructure today in pla= ce to
> multihome to your laptop/iPhone/tablet/Android/FB phone, something I > deeply regret we have not yet worked out. Maybe some day.
>
We don't need routing infrastructure to change and we are really= not
asking for any changes in the network other than they forward UDP
packets, respect E2E protocols, and otherwise implement the Internet
standard. The transport layer is being changed to facilitate
multihoming. Please look at connection identifiers in QUIC and
disassociated location in TOU ( draft-herbert-transports-over-udp) to
see how this is being done.

>
>> , not because the standard was
>> ever changed to require it. Desktops sitting behind home routers i= s no
>> longer a sufficient model for the Internet; mobile devices are
>> currently predominant and the Internet needs to adapt accordingly.=
>>
>> Consider that mobile devices are multihomed having at least two >> network connections. We want the ability to seamlessly switch betw= een
>> networks (say from wifi to mobile) or between mobile networks as w= e
>> drive down the road. Performing 3WHS is very expensive on mobile >> (literally for some of our users), so we need connections to survi= ve
>> across these path changes. If we hide the transport layer from the=
>> network devices (e.g. from home routers) then they can't enfor= ce the
>> single path assumption. In fact, once we disassociate location
>> (addressing) from connection endpoint identification (like describ= ed
>> in TOU) then connections should be able survive even across an add= ress
>> change and between two completely providers. This is of huge value= to
>> our users and IMO justifies encrypting the transport layer.
>
> But the way this is done is through multiple pesistent transport
> connections bound off of separate L3 local addresses.=C2=A0 We have at= tempted
> to do otherwise through MIPv6 and LISP-MN.=C2=A0 Not widely deployed, = and
> even were they so, it is probably sufficient for something like the LI= SP
> header to be above PLUS (think about that until you're 103)!
>
Those some of the possible ways to do handle multihoming, but by no<= br> means does this define the complete solution space. There is still
room for innovation in alternatives as I pointed out above.

Tom

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--001a114bdd4c343f970539080012-- From nobody Mon Aug 1 13:06:54 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBD312D734 for ; Mon, 1 Aug 2016 13:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VEu8iQLQ94k for ; Mon, 1 Aug 2016 13:06:52 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC6212D649 for ; Mon, 1 Aug 2016 13:06:51 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id j8so39807501itb.1 for ; Mon, 01 Aug 2016 13:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P/IrvpnC9isJx2tuhxhOHlCmVZGeZ2RsVJhD5PNLPvI=; b=m2BULtwM9k4CSE2Ys/H3okwSO2NtbrbANY11j8OUJZ91bypmNoT2xEOSZHlf3B4YVv 03dZq9m33o5UFYXy1UYah6kKYrrE/TWDSTvv2STrbgcfI+T7klLar7aAG/vC/TZZfbto ilFjnOhDF3I576fP+x5uqMpU8I6/LBuEzjeLrNXH2Kn/eb+ZnNfOBHj77PyURxKrbA9O fuRbpZk+yzOoW03xxHRqmTcA514JaHsSnGpdTNAU6VMzjB33b6A5IOmswZIstq6i6Qfw GD5aG9mqDOLMgrcC5E0DofWRHN94T8NdOKWcupf+QJz1FkPmIg837lVqnIuGbHLCzUHK sk/w== 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:from:date :message-id:subject:to:cc; bh=P/IrvpnC9isJx2tuhxhOHlCmVZGeZ2RsVJhD5PNLPvI=; b=iyqALL8Varq8eLHKVn5uVIyYcVL9C5yyq18n52uDswSaulwkuqjrKutpFPxHoxZoSm fgZpxhphquOZjWSaFkHwS4V8j1yTjRGM0x7qrBRAhFbSSI7djqX7y5UIUR/g/3kic/7W ZEJK9NSSqC7/OzoC/nNFpajKlcdNjmZ3DQeQ1hhTDbhBnHjbfoOrPQ3LeffeUzjckfbs 0qkxwjgSfhP73DoUV0HdiCpBVVwu+rqXfp0sNmZnshwqA+9t3dSIKUejlLRj2HtT6Mqe scVs/hWknGCSEa0mpMWc2aQPo5Hglqf1gH8UhQmW0vC4xDZzfMByVndiho6yYPaKcKis Ej0w== X-Gm-Message-State: AEkoouvKCKY+xnT5PJLcIEzIXSN3z1XDq5OZBTUgMkBiO6YQxQGNzW+BcwA5hlX68XSXXlUI3cmzQNNe1ayS0A== X-Received: by 10.36.51.206 with SMTP id k197mr38505410itk.37.1470082011183; Mon, 01 Aug 2016 13:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 13:06:49 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Tom Herbert Date: Mon, 1 Aug 2016 13:06:49 -0700 Message-ID: To: Spencer Dawkins at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eliot Lear , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Stephan Neuhaus , Brian Trammell , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:06:53 -0000 On Mon, Aug 1, 2016 at 12:56 PM, Spencer Dawkins at IETF wrote: > Hi, Tom, > > On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert wrote: >> >> > On 8/1/16 4:59 PM, Tom Herbert wrote: >> >> If that [99.999%] number it is correct it is only because home routers >> >> have >> >> ossified the Internet in that regard >> > >> > I realize that people have ossification on the head, but I'm sure you >> > recognize that the right answer here is that most people only have a >> > single connection into their homes. For those who have more than one, >> >> Well, I'm sitting here in my home looking at my Nexus 6 and I can >> confirm that it is attached to Internet my via Comcast wifi as well as >> Verizon's mobile network. So my smart phone is definitely a multihomed >> and I definitely have multiple connections into my home. Right now I'm >> using the wifi link, but if I walk into my backyard out of range then >> I don't want the device to have to restart all my TCP connections when >> switching to the mobile network. Neither do I want to have to create >> 2x connections like in MP-TCP just because I might at some point walk >> into my back yard (it's kind of gloomy right now so I don't think I'll >> be doing this anyway). > > > I'm not going to guess what wireshark would show on your home network or on > Verizon's, but I'm having a hard idea understanding how a TCP connection > identified by a 5-tuple that includes a local address from your wifi routed > through Comcast stays active when you get in a car and drive away, so that > the only active interface on your smart phone now has a local address that > is routed through Verizon. > TOU will negotiate a session identifier (similar to connection identifier) in QUIC. With this the TCP endpoints no longer use the 5-tuple to identifier the connection, they use the session identifier. This provides unambiguous connection identification that is independent of addresses or encapsulating UDP ports (the most immediate problem this resolves is NAT state remapping). Strong security is required to prevent connection hijacking and there are a couple of other caveats. Please look as section 3 in draft-herbert-transports-over-udp for details. Tom From nobody Mon Aug 1 13:10:32 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B812D973 for ; Mon, 1 Aug 2016 13:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlmRVLH5FHkC for ; Mon, 1 Aug 2016 13:10:28 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB2F12D741 for ; Mon, 1 Aug 2016 13:10:28 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u134so182982626ywg.3 for ; Mon, 01 Aug 2016 13:10:28 -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; bh=0Cve4Jhmgm6DFiXufPGd3WDA/hA7m0JnWQHa842FR3I=; b=xugvpfOaK+BvPxzwlQ4dtiXvgCwe4HjpIuogwJ3zwJ53kRuQ385rkdyoaH/IJWEyT5 YA3Im/b1z1c7cqdApUcdyr0kgLq4yS3qiT3B6Dtx/gaxTdonTckoP2W/awZhUcGjMXez wK49a9cus028ugX+uGyAGwvIeXWvDIeXorkWvauYzKL87x+qobD6bvU2NfmBfcrI22YF jpmyTUGWo6+AGANus9U1mmZjUz4RIBYQN/5tHfjyJwZHOq1tX8zHtQSO2wDkPh7oIPGu 2CAsIycOEsTizOkUv4pIbz/W+a9x2pAlqH4Lft4hWSy9n4EXPJXznJEoIqZDD7NH6APA 8ovw== 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:from:date :message-id:subject:to:cc; bh=0Cve4Jhmgm6DFiXufPGd3WDA/hA7m0JnWQHa842FR3I=; b=Yejv/oNvUXYCvEN5a/YI0XkLCAW8xVljCxsBIeP+ML7b32Ka93X0P7X0QZbVep1NI2 /TgtcYGyElhWD/2C+ipAUIdtXlwIHkUkFbZJpu3xn3A4WA7yLl2CDnHBl8NY4sn5Ne60 LgpttyvaZooSnpQmmK08XjePW6J4rAJudq3Us3WZyTL4Oei6b4DnN/rsDOllwk1kUfcA mHX7Oy3h1tAaGyIkUtpQNt/6LCoUf5oVnlO6YIUcCm7R+ChiuJlnfRS0yXxUmZFPd2s7 nB4BgQcTCtO5jfSlrGYpyXL6BlZ4u8lLkH6sU9Q6dsUjx4P2lbE1S29z+wBggPUsAdwQ 4tRg== X-Gm-Message-State: AEkoouvFgOu0qje2jlrnPachPb2PGnjzudHkTgnmHXrU/6NSNDMsaswmxkTF0Il7E/qV5htd0MKvyasNZmOiiw== X-Received: by 10.129.73.207 with SMTP id w198mr46830078ywa.64.1470082227713; Mon, 01 Aug 2016 13:10:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.132 with HTTP; Mon, 1 Aug 2016 13:10:26 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Spencer Dawkins at IETF Date: Mon, 1 Aug 2016 15:10:26 -0500 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114dc91cf93bd805390830ea Archived-At: Cc: Eliot Lear , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Stephan Neuhaus , Brian Trammell , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:10:30 -0000 --001a114dc91cf93bd805390830ea Content-Type: text/plain; charset=UTF-8 Hi, Tom, On Mon, Aug 1, 2016 at 3:06 PM, Tom Herbert wrote: > On Mon, Aug 1, 2016 at 12:56 PM, Spencer Dawkins at IETF > wrote: > > Hi, Tom, > > > > On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert > wrote: > >> > >> > On 8/1/16 4:59 PM, Tom Herbert wrote: > >> >> If that [99.999%] number it is correct it is only because home > routers > >> >> have > >> >> ossified the Internet in that regard > >> > > >> > I realize that people have ossification on the head, but I'm sure you > >> > recognize that the right answer here is that most people only have a > >> > single connection into their homes. For those who have more than one, > >> > >> Well, I'm sitting here in my home looking at my Nexus 6 and I can > >> confirm that it is attached to Internet my via Comcast wifi as well as > >> Verizon's mobile network. So my smart phone is definitely a multihomed > >> and I definitely have multiple connections into my home. Right now I'm > >> using the wifi link, but if I walk into my backyard out of range then > >> I don't want the device to have to restart all my TCP connections when > >> switching to the mobile network. Neither do I want to have to create > >> 2x connections like in MP-TCP just because I might at some point walk > >> into my back yard (it's kind of gloomy right now so I don't think I'll > >> be doing this anyway). > > > > > > I'm not going to guess what wireshark would show on your home network or > on > > Verizon's, but I'm having a hard idea understanding how a TCP connection > > identified by a 5-tuple that includes a local address from your wifi > routed > > through Comcast stays active when you get in a car and drive away, so > that > > the only active interface on your smart phone now has a local address > that > > is routed through Verizon. > > > TOU will negotiate a session identifier (similar to connection > identifier) in QUIC. With this the TCP endpoints no longer use the > 5-tuple to identifier the connection, they use the session identifier. > This provides unambiguous connection identification that is > independent of addresses or encapsulating UDP ports (the most > immediate problem this resolves is NAT state remapping). Strong > security is required to prevent connection hijacking and there are a > couple of other caveats. Please look as section 3 in > draft-herbert-transports-over-udp for details. > AH - I didn't realize you were talking about your proposal. I've read that. I lost any reference to it in the post I replied to - hence my confusion. Thanks for the clue. > > Tom > --001a114dc91cf93bd805390830ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tom,

On Mon, Aug 1, 2016 at 3:06 PM, Tom Herbert <<= a href=3D"mailto:tom@herbertland.com" target=3D"_blank">tom@herbertland.com= > wrote:
On Mon, Aug 1, 2016 at 12:56 PM, Spencer Dawkins at I= ETF
<spencerdawkins.ietf@gm= ail.com> wrote:
> Hi, Tom,
>
> On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert <tom@herbertland.com> wrote:
>>
>> > On 8/1/16 4:59 PM, Tom Herbert wrote:
>> >> If that [99.999%] number it is correct it is only because= home routers
>> >> have
>> >> ossified the Internet in that regard
>> >
>> > I realize that people have ossification on the head, but I= 9;m sure you
>> > recognize that the right answer here is that most people only= have a
>> > single connection into their homes.=C2=A0 For those who have = more than one,
>>
>> Well, I'm sitting here in my home looking at my Nexus 6 and I = can
>> confirm that it is attached to Internet my via Comcast wifi as wel= l as
>> Verizon's mobile network. So my smart phone is definitely a mu= ltihomed
>> and I definitely have multiple connections into my home. Right now= I'm
>> using the wifi link, but if I walk into my backyard out of range t= hen
>> I don't want the device to have to restart all my TCP connecti= ons when
>> switching to the mobile network. Neither do I want to have to crea= te
>> 2x connections like in MP-TCP just because I might at some point w= alk
>> into my back yard (it's kind of gloomy right now so I don'= t think I'll
>> be doing this anyway).
>
>
> I'm not going to guess what wireshark would show on your home netw= ork or on
> Verizon's, but I'm having a hard idea understanding how a TCP = connection
> identified by a 5-tuple that includes a local address from your wifi r= outed
> through Comcast stays active when you get in a car and drive away, so = that
> the only active interface on your smart phone now has a local address = that
> is routed through Verizon.
>
TOU will negotiate a session identifier (similar to connection<= br> identifier) in QUIC. With this the TCP endpoints no longer use the
5-tuple to identifier the connection, they use the session identifier.
This provides unambiguous connection identification that is
independent of addresses or encapsulating UDP ports (the most
immediate problem this resolves is NAT state remapping). Strong
security is required to prevent connection hijacking and there are a
couple of other caveats. Please look as section 3 in
draft-herbert-transports-over-udp for details.

AH - I didn't realize you were talking about your proposal. I&#= 39;ve read that. I lost any reference to it in the post I replied to - henc= e my confusion.

Thanks for the clue.
=C2= =A0

Tom

--001a114dc91cf93bd805390830ea-- From nobody Mon Aug 1 13:16:04 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFE112D603 for ; Mon, 1 Aug 2016 13:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc3lcaUrnVbG for ; Mon, 1 Aug 2016 13:16:01 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F041612B062 for ; Mon, 1 Aug 2016 13:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rNjV0m7PBIHc9VMbwAUpAf8w5U1dLqhq/igMPr+52yo=; b=nD9I0a6D6FeioK4A6XPUBg2Ln3pj7Kxfyt69SfqmnywgmTu4F+p32jnYxhfAIZLoqox6k6ElnEon1tR5+RskFTmbemmlg7Lk3C/VyXLPCy+1MjIRmu8Pcjx/pZKe39/lVd/B8qiFY0PBODkiibklO9QuBBpQDnLBSc3Vsb83nWI= Received: from BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) by BN6PR03MB2674.namprd03.prod.outlook.com (10.173.143.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 20:15:57 +0000 Received: from BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) by BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 20:15:57 +0000 From: Christian Huitema To: Spencer Dawkins at IETF , Tom Herbert Thread-Topic: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks Thread-Index: AQHR6o+XeijpweZ3K0OXgZM+Fyi9e6AxZMEAgAJDfwCAAI01AIAAAquAgAANJ4CAAENGAIAAAs2AgAABAgCAAABuYA== Date: Mon, 1 Aug 2016 20:15:57 +0000 Message-ID: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:8::593] x-ms-office365-filtering-correlation-id: 9c1e65cd-71d9-4da5-0358-08d3ba48a638 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2674; 6:JIDYNWS1GEofDgGsHqEcEkJUhU+tW8FesKLUEE4no2GiEVgowKnaKKldSjmcFpTdiKkVIBIyHl/xqR2zuygLbst7O/EXVJkGCKlTjPFdtF1zsfm9aLRMSY2/O4/GXB+b8Efg8d8WKMgoR3LTJYZR5mLDG3grAF6ANXkUrOiH7nWUs3ymWnrqPeqPW3fIm4fEkfJsL8fMX9sgZnyHmZGMK5GaySoqsOMGiMZTNdD/x/rhvWpFIgaciDaPDOqezKTYlphEzyykTiUa2bTzEC4rcn55vks2nmsv0C5sVxqTyUDLDj8/1ULiHe6ktQDuuIpeDDozDMi9DP+czQ3IQczE7Q==; 5:p2zAnjlOoTIk1S7ckg3UJ75NvvUFqB4NMQOYLaEPP4+Hviqulm99Ir1XyLF8h8OPd1+/LSbfaLQuboaNQsEIsvBNTx3VR0vcK9080Zmii+kYmrEHVvfMnv4enmPMNMLN0w7Ev5pE6ZkQk21HHkJFAA4MsunuBMhAbr/LYISYyvE=; 24:urzj1bxVI7O3y+4CqH5i0o4ExvTvQfyTd+DUZincCG7jhPtuJIWUBMTJg3vWRLIH3+fHJhoMCzzhriOUXzK1lVchK/LQ0hg9L7Fw46ui6Hs=; 7:FlXSDwnSvPI7Roxo4S+uXJbbzf8zKW/ktCT1V+nMyTVbOnJN83luGgQ0eSZLTBwH6rGBVsqoT/y26VjTYiRYjEhznrfvoyXQ9bLPB7owc05ZaXKRj/Q32hwNcPCq9reKdpmNp33X3GEAMj+O+02ekpEjX2l7VGMiMIednDZiYT0eD5ZewxqhqNbwH3jiqRatCsvKomWkMzj4Af48pZ0s1YrFNKf+ZBUGcsEXteAxrXdZAgY2qW0KwRbEVvJDNThx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2674; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2674; BCL:0; PCL:0; RULEID:(304825044); SRVR:BN6PR03MB2674; x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(106356001)(54356999)(101416001)(33656002)(50986999)(77096005)(122556002)(8936002)(93886004)(6116002)(5002640100001)(2906002)(76176999)(8990500004)(81166006)(81156014)(586003)(4326007)(8676002)(106116001)(74316002)(9686002)(76576001)(7696003)(189998001)(11100500001)(2900100001)(102836003)(10400500002)(86612001)(561944003)(7846002)(3280700002)(7736002)(2950100001)(3660700001)(10290500002)(92566002)(87936001)(305945005)(99286002)(105586002)(10090500001)(68736007)(97736004)(5001770100001)(5005710100001)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2674; H:BN6PR03MB2675.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 20:15:57.5870 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2674 Archived-At: Cc: Eliot Lear , spud , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Brian Trammell , Stephan Neuhaus , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:16:03 -0000 T24gTW9uZGF5LCBBdWd1c3QgMSwgMjAxNiAxOjEwIFBNLCBTcGVuY2VyIERhd2tpbnMgd3JvdGU6 DQo+DQo+IEFIIC0gSSBkaWRuJ3QgcmVhbGl6ZSB5b3Ugd2VyZSB0YWxraW5nIGFib3V0IHlvdXIg cHJvcG9zYWwuIEkndmUgcmVhZCB0aGF0LiBJIGxvc3QgYW55DQo+IHJlZmVyZW5jZSB0byBpdCBp biB0aGUgcG9zdCBJIHJlcGxpZWQgdG8gLSBoZW5jZSBteSBjb25mdXNpb24uDQoNClRoZSBxdWVz dGlvbiB3YXMgd2hldGhlciBpdCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIHNwZWNpYWwgbWFya3Mg Zm9yIHBhY2tldHMgdGhhdCAic3RhcnQgYSBjb25uZWN0aW9uLCIgYW5kIHNwZWNpZmljYWxseSBm b3IgcGFja2V0cyBzZW50IG92ZXIgVURQIGJ5IGVuY3J5cHRlZCB0cmFuc3BvcnRzLiBUb20ncyBw b2ludCBpcyB0aGF0IHRoaXMgd2lsbCBjcmVhdGUgYnJlYWthZ2UgaW4gbWFueSBjb25kaXRpb25z LCBzdWNoIGFzIG11bHRpLWhvbWVkIG5vZGVzLiBJIGNhbiBzZWUgYXQgbGVhc3QgdHdvIHNjZW5h cmlvcyBpbiB3aGljaCB3ZSBjb3VsZCBzZWUgYnJlYWthZ2Ugd2l0aCBRVUlDOg0KDQoxKSBDbGll bnQgaXMgc2l0dGluZyBiZWhpbmQgYSBub25wbHVzc2VkIE5BVC4gVGhlIFFVSUMgc2Vzc2lvbiB3 aXRoIHRoZSBzZXJ2ZXIgYmVjb21lcyBzaWxlbnQgZm9yIGEgc2hvcnQgcGVyaW9kLCBhbmQgdGhl IGNsaWVudCdzIE5BVCByZWxlYXNlcyB0aGUgVURQIG1hcHBpbmcuIFRoZSBjbGllbnQgdGhlbiBz ZW5kcyBtb3JlIGRhdGEuIFRoZSBOQVQgd2lsbCBhc3NpZ24gYSBkaWZmZXJlbnQgcG9ydCBtYXBw aW5nLiBUaGUgc2VydmVyIHdpbGwgdXNlIHRoZSBjb25uZWN0aW9uLUlEIGZpZWxkIGluIHRoZSBR VUlDIGhlYWRlciB0byByb3V0ZSB0aGUgcGFja2V0cyB0byB0aGUgcmlnaHQgc2VydmVyLCBhbmQg YXV0b21hdGljYWxseSByZXBhaXIgdGhlIGNvbm5lY3Rpb24uIFN1cHBvc2Ugbm93IHRoYXQgc29t ZXdoZXJlIG9uIHBhdGgsIG1heWJlIGF0IHRoZSBJU1Agcm91dGVyLCBzb21lIHBpZWNlIG9mIHNv ZnR3YXJlIHRyYWNlcyB0aGUgY29ubmVjdGlvbnMgYW5kIHJlbGllcyBvbiAic3RhcnQgb2YgY29u bmVjdGlvbiIgbWFya3MuIFRoZSAicmVwYWlyIiBwYWNrZXQgY29tZXMgZnJvbSBhIGRpZmZlcmVu dCBVRFAgcG9ydCwgYW5kIGRvZXMgbm90IGNhcnJ5IGFueSAic3RhcnQiIG1hcmsuIFdpbGwgaXQg YmUgZHJvcHBlZD8NCg0KMikgQ2xpZW50IGlzIHNpdHRpbmcgb24gYSBtdWx0aS1ob21lZCBuZXR3 b3JrLCBtYW5hZ2VkIGJ5IG91dGdvaW5nIE5BVC4gQXQgc29tZSBwb2ludCwgTkFUIG1hbmFnZW1l bnQgY2F1c2VzIHRoZSBwYWNrZXRzIHRvIHRoZSBzZXJ2ZXIgdG8gYmUgcm91dGVkIHRocm91Z2gg dGhlICJmYWxsIGJhY2siIElTUC4gVGhlIHBhY2tldHMgcmVhY2ggdGhlIHNlcnZlciwgdGhlIGNv bm5lY3Rpb24tSUQgZmlsZWQgZG9lcyBpdHMgbWFnaWMsIGFuZCB0aGUgY29ubmVjdGlvbiBpcyBh dXRvbWF0aWNhbGx5IHJlcGFpcmVkLiBCdXQgb2YgY291cnNlLCB0aGUgcm91dGVycyBvbiB0aGUg bmV3IHBhdGggZG9uJ3Qgc2VlIGFueSAic3RhcnQgb2YgY29ubmVjdGlvbiIgbWFyay4NCg0KVGhl cmUgYXJlIHByb2JhYmx5IG1vcmUgY2FzZXMsIGJ1dCB0aGVzZSB0d28gY2FuIGhhcHBlbiB0b2Rh eSwgd2l0aCBzaGlwcGluZyBjb2RlIGFuZCBleGlzdGluZyBoYXJkd2FyZS4gVGhlIE5BVCBtYXBw aW5nIHJlZnJlc2gsIGluIHBhcnRpY3VsYXIsIGlzIHF1aXRlIGNvbW1vbi4gVGhpcyBpcyB3aHkg SSBtdWNoIHByZWZlciAiaW1wbGljaXQgc3RhcnQiIHByb2Nlc3NlcyB0byAiZXhwbGljaXQgbWFy a3MuIg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg== From nobody Mon Aug 1 13:52:19 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196312D8A5 for ; Mon, 1 Aug 2016 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXtiLJsOpuWN for ; Mon, 1 Aug 2016 13:52:16 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4233212D9F9 for ; Mon, 1 Aug 2016 13:52:15 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id f6so255693093ith.1 for ; Mon, 01 Aug 2016 13:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t53FGuZ0ongnqELsjOCiE5I50wwsm8DGXIHZA0eUQP4=; b=bIEIbGW3dmu4gOSVpkFxq+56KgcnVTH4BRscQFxE7faiEpYE0G/2cAZJ+yH4bH3OXG 2LaYG5QknqsH6wUBsQGJr1GfhGJIHxOkwf/uuPf3cJX/+mRzz71dwmt1VEsneFXGSP72 b/J9ntjZqmjYjgfwvRq3b5jy0okSkpzLU8+ioatOnmKntVBExUfMtL186Kz2pL1Uny+5 oi7YFxA978M1jrxLKjKxAPyozi1jNU7845TLYJr3rk7GWSLoWWr1iKdpOBXBTMlZXUM7 iD9V7e7jtB/Zw5ROOnAxgE1xYCPjK+PJeiVZFCUDes7aHV7ULweVjIIgbLyb24ejDeox Ab0Q== 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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t53FGuZ0ongnqELsjOCiE5I50wwsm8DGXIHZA0eUQP4=; b=nKXbJNOp+juNrl8FMpspMzKWRInVZUjoHTxsx4fRG3q3EzrU8EHSHCr1m9hSENtgIO TGao4yu8LssCdOYOjvHXpG+zXdu5jM3QzVDlFU2i7pRHt3losASbbJlvwkdJry6+Euyu 07hiFaNoI9Z1RTE7qwNEg2692NHe833mwlmlFzM14S3NTf2WQ8y4N5HhlBfMnawOXzxr H67f22s0AqdSuzsaXE1dq6/SYVjY4HCPNyCGUwiTlPExZERsBTWi2Ta0DEu3zClNkQE7 Ladrkvy7wwpRMfQF/wrwiu/QF7Zd7KXUJyEzRZ0alXcaIJ2jWPFFqCIYFVieO4J33s3E lNpw== X-Gm-Message-State: AEkooutGhZoyGb4DC19+h6PyTR/9Mw0Y86vURL3Zd0Q4mJ1mFah3KHfWVDzYmno6gv4jnmrcYarVvp2BY+SiBA== X-Received: by 10.36.194.65 with SMTP id i62mr16262846itg.91.1470084734575; Mon, 01 Aug 2016 13:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 13:52:12 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Tom Herbert Date: Mon, 1 Aug 2016 13:52:12 -0700 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Eliot Lear , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Spencer Dawkins at IETF , Brian Trammell , Stephan Neuhaus , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:52:17 -0000 On Mon, Aug 1, 2016 at 1:15 PM, Christian Huitema w= rote: > On Monday, August 1, 2016 1:10 PM, Spencer Dawkins wrote: >> >> AH - I didn't realize you were talking about your proposal. I've read th= at. I lost any >> reference to it in the post I replied to - hence my confusion. > > The question was whether it is a good idea to have special marks for pack= ets that "start a connection," and specifically for packets sent over UDP b= y encrypted transports. Tom's point is that this will create breakage in ma= ny conditions, such as multi-homed nodes. I can see at least two scenarios = in which we could see breakage with QUIC: > > 1) Client is sitting behind a nonplussed NAT. The QUIC session with the s= erver becomes silent for a short period, and the client's NAT releases the = UDP mapping. The client then sends more data. The NAT will assign a differe= nt port mapping. The server will use the connection-ID field in the QUIC he= ader to route the packets to the right server, and automatically repair the= connection. Suppose now that somewhere on path, maybe at the ISP router, s= ome piece of software traces the connections and relies on "start of connec= tion" marks. The "repair" packet comes from a different UDP port, and does = not carry any "start" mark. Will it be dropped? > > 2) Client is sitting on a multi-homed network, managed by outgoing NAT. A= t some point, NAT management causes the packets to the server to be routed = through the "fall back" ISP. The packets reach the server, the connection-I= D filed does its magic, and the connection is automatically repaired. But o= f course, the routers on the new path don't see any "start of connection" m= ark. > > There are probably more cases, but these two can happen today, with shipp= ing code and existing hardware. The NAT mapping refresh, in particular, is = quite common. This is why I much prefer "implicit start" processes to "expl= icit marks." > The question is also whether we need to send an explicit "end connection" signal. Network devices want this to know when to free their connection tracking state, but in a multipath Internet I don't readily how this would be a useful signal either. Tom From nobody Mon Aug 1 13:55:57 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A372212DAF4 for ; Mon, 1 Aug 2016 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qZUz2YLqjk8 for ; Mon, 1 Aug 2016 13:55:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D06A12D8AB for ; Mon, 1 Aug 2016 13:55:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47076BE3E; Mon, 1 Aug 2016 21:55:49 +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 MrnUIxB9ahFF; Mon, 1 Aug 2016 21:55:47 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3524CBE39; Mon, 1 Aug 2016 21:55:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470084947; bh=KZ3CoB9VQ6+3VzOPwicAIMexuXDcfJO6AYB0MUowxh0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=09rpKU4/r/Qth6qz7OUKaeFr8eT559bnePU32G2P+B/x195OEKvKMcnSH7ghnkyxk wA5hlBcVrr/mirpj18ODOGvFsoQXE1NUqg0cQ0Gmvoeo3+76wA8AYJ7ipyxUhI+8o+ xSoB1LmlEDotLfSL7GSYQ+XsqOv/H+Ym1zcRblOM= To: Ted Hardie References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> Date: Mon, 1 Aug 2016 21:55:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030709050205010304080700" Archived-At: Cc: Brian Trammell , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Michael Tuexen Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:55:54 -0000 This is a cryptographically signed message in MIME format. --------------ms030709050205010304080700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/08/16 19:56, Ted Hardie wrote: > On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell < >=20 >> >> IMO that case has not been made to the point where I would >> consider it justifies privacy downsides. IOW, while I am of >> course in favour of endpoints being able to signal to one >> another without middlebox interference, I am not at all on >> side with transport header integrity being counted as a major >> win in the analysis of PLUS, if that "win" inherently requires >> a significant privacy cost. (And I am clearly happy to endlessly >> repeat myself that in this particular case: >> >> extensibility =3D=3D privacy unfriendly >> >> > Stephen, someone naively coming across this statement in the record wil= l > think you mean that any extensibility is privacy unfriendly. Obviously= , > you have championed the ability to shift cryptographic algorithms as ne= eds > change, which requires extensibility of specific forms. Lots of other= > work requires extensibility to be useful at all (imagine if the tag spa= ce > of the web had been frozen in 1993). > > I should greatly appreciate you reformulating this into something that > actually matches your meaning. That would likely be useful; this is no= t. Sorry if there was context lacking and happy to try elucidate further (and please do feel free to help improve my description of the issue)... In the specific case of exposing higher layer information about well protected (e.g. encrypted) traffic to lower layers, (whether via an interface from the higher layer, or via addition by the lower layers) I believe any extensible mechanism for that kind of interface severely risks being extremely privacy unfriendly. And the transport layer may be the worst possible case of such an extensible higher/lower layer interaction as it by definition spans the full "width" of the network. I think the main reason is that there would be significant pressure and temptation to try support non-technical policies being enforced at one place in the network based on information provided at another. In this case, by "non-technical," I mean any information not absolutely necessary for the correct operation of the lower layer. That's a term and definition I'm sure could be improved, and I'm also sure there could be borderline cases. But there would immediately also be cases that are nowhere near any border... such policies would almost certainly demand methods to expose personally identifying information or identifiers that can be easily (re)identified as such. That would directly enable the kind of meta-data collection and tracking that the IETF has agreed is an attack in BCP188. (I assume here that no relevant lower layers "need" PII to operate correctly - if they do, they are probably broken:-) But another and possibly even worse (ab)use case might signal that the person associated with a flow is a member of some set of people, for example, over-18, a member of the ruling party, or of some minority. The consequences of standardising that kind of extensibility in a way that could allow such "policy enforcement" at essentially any place on the Internet is for me supremely scary. While there do doubtlessly exist use-cases for such extensibility in this context that initially appear reasonable, the potential impact of the abuse cases, and my own opinion of their probability of occurrence being approx 1.0 at some place(s) and times on the big-I Internet for me very much outweighs any potential utility from non-abuse cases of this particular kind of extensibility. As an aside, I fully accept that folks arguing for non abuse-cases of extensibility are doing so with good intentions. I think this is just an unusual case where our normal ways of engineering extensibility are way more dangerous than usual. (*) In the case of the proposed charter at the BoF, the use of an IANA registry seems particularly unwise to me as in addition to being open to pressure to formally register privacy-unfriendly codepoints, any IANA-based scheme would also allow for squatting on codepoints, which we know can become a fait-accompli. I don't see any way in which IETF/IANA processes could resist the pressure to provide such "policy" support. I also cannot think of a non-IANA extensibility mechanism that could work here and not have the privacy downsides. And lastly, there is a significant difference here between existing non-standard methods for injecting the above kinds of information and a world in which we have standardised such extensibility. The status quo may allow for such injection but the full horror of the worst abuse-cases here would require that the abuse-case information flow from end-to-end unimpeded (or almost end-to-end) so reliably abusing that kind of information does I think require a standard. Hopefully that's clearer, (it's definitely longer;-) and again, I'd really welcome crisper and better text to describe these issues as I'm sure it's a discussion that will recur at other times and places. Cheers, S. (*) The "usual" dangers of extensibility are I guess complexity and loss of interoperability, exemplified in the current debate about TLS ciphersuite structure and TLS version intolerance. >=20 > thanks, >=20 > Ted >=20 --------------ms030709050205010304080700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDEy MDU1NDZaMC8GCSqGSIb3DQEJBDEiBCCLplGYb6ynjnkTOflEq6Tz37MnEE2sR2SPlb8njwrX pDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCMM+pHw9XTLYbDTJHhjWFPxXXym/iBT4wml3M98sgJese1Q3BHIJaW 2LzCIW2lOHOCSi02A8aaCkmV9yO5VQSLHI8f2SbQB6JqI3VGfLshlFrvrZOC1JO8GM+rwaS7 zRf14ZCnVlpkdGPRJqR1VhIj5LNqTv0naE7EgM1Khi8r2GLiVH0YxY4YsEfwSOy0Lvr+DyGa mY3SW0OE+rR/sgFaJzWtdYyN9eu58vlNAOJeUJWwgMyUjAG7FB5BH1dH5XiS2qu6RCjOmCQG K6Micf0xZaslWTDCEc3Vywd+g5sosCX3DfkQycRbTHqQNHPc8w0Z1WjTGUkk5kq9AggLw1V1 AAAAAAAA --------------ms030709050205010304080700-- From nobody Mon Aug 1 14:02:57 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D23012D890 for ; Mon, 1 Aug 2016 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXrR8mHCzL6O for ; Mon, 1 Aug 2016 14:02:54 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0110.outbound.protection.outlook.com [104.47.34.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2725412B016 for ; Mon, 1 Aug 2016 14:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2tEwyI8mQ7xHVVopHf822mcBJNS0dasymQwdSzIyofM=; b=EzyZCU7DTPdneQaCI4yVpMw7IbqTQSFjvXDuP5Otur/Witmfy4cOSUmWWjiQZ3FqGTd+Onn8aNvUMcvlSCXmzLctQ47/FcR+ro/cEJfA2n0gy7LE5r5cw2GsnxPL20mZd9tNuttkiaXiAGJARUNiVCzQtw1AwZsvw/8wDlQ667s= Received: from BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) by BN6PR03MB2673.namprd03.prod.outlook.com (10.173.143.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 21:02:51 +0000 Received: from BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) by BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 21:02:51 +0000 From: Christian Huitema To: Tom Herbert Thread-Topic: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks Thread-Index: AQHR6o+XeijpweZ3K0OXgZM+Fyi9e6AxZMEAgAJDfwCAAI01AIAAAquAgAANJ4CAAENGAIAAAs2AgAABAgCAAABuYIAACz4AgAAB9VA= Date: Mon, 1 Aug 2016 21:02:51 +0000 Message-ID: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:8::593] x-ms-office365-filtering-correlation-id: 4e24e17a-bdc6-438c-233d-08d3ba4f3393 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2673; 6:z5P/MAjXM/QWSgdZaRhobg2FR2JZY4JDPDZWmJrRKLmg/RvLcXIS+CypMCLArSO2tWYkpWSdq0h/ErzD8p3Igas3ELMohSesmwOkKJiOEgvfrT3dTCieId3DhKBaBxNrL0hGRzvuUOaslPmLJ8APPMXGCcRAeD+hhmpMuFfC3/MuXA8IZPdgifG5TYGv422d2T3E1pE5RPe7Go2ecpdeiMRneaYN3ILAXUOvdcQviXB3Qvwg70+c3+cZ+NZfpBOJwLQYd8kYvXc8LfajKTv+O+SXf3ZLkdaMioJIHVLKt9+qPPRxZzOhEO4UU4+0oG08iASTlMrWw1yRDqiLdSpZfg==; 5:BLUfoJa88LhcW0Vz9n+bkjy4GUCmE7muBTGCcuAlE2IiEBqkVY1qESoDbNJegyM9PJt1ecX35r0RaWcnmOE9cDIM9I31UfeKbJqT+I2+fWBY9lPEL+Gkd8Sso6fuYZAAd6ybcTkSsynaPmgAzNmNdw==; 24:U9a3FpHwlW1oEYM2h4i5+1IkkuYzz7hWSRABuc414win1JCiqD/mUz+ebOfkFm5nJy6aXQlV4RONlTDdxbd0LG+TthYFufK8lvFBBiifGec=; 7:KHFxuqiAE6lMY58B9732IJYHeb+AnADA04RJCy4W1a9FUbbXd2L9ese8bCgaQP3NnAq+A716X2g2ACnLnq+MJui/rgbPu3dqUqwSCQnQ9zZT652bqTsqZriOyrgqRQr1+CbDkfED8VPzy8cOaWSSG/aDtmqD3U2hKtqlqhYkubfuvhLNN0zaju1+2/OL6w2b9rXsNUZzJoT2lPMrb6o8A6glvj1Q+DX4AllQeONAsswMt9V5RmC7cdnHqBw25VCq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2673; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2673; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2673; x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(74316002)(5002640100001)(7696003)(92566002)(2900100001)(7846002)(7736002)(99286002)(77096005)(305945005)(2950100001)(105586002)(106356001)(106116001)(3280700002)(8676002)(11100500001)(8936002)(76576001)(81156014)(5005710100001)(81166006)(54356999)(86612001)(101416001)(97736004)(68736007)(110136002)(3660700001)(586003)(9686002)(10090500001)(50986999)(76176999)(87936001)(33656002)(10290500002)(10400500002)(2906002)(8990500004)(93886004)(4326007)(86362001)(122556002)(189998001)(6116002)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2673; H:BN6PR03MB2675.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 21:02:51.7853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2673 Archived-At: Cc: Eliot Lear , spud , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Spencer Dawkins at IETF , Brian Trammell , Stephan Neuhaus , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:02:55 -0000 T24gTW9uZGF5LCBBdWd1c3QgMSwgMjAxNiAxOjUyIFBNLCBUb20gSGVyYmVydCB3cm90ZToNCj4N Cj4gVGhlIHF1ZXN0aW9uIGlzIGFsc28gd2hldGhlciB3ZSBuZWVkIHRvIHNlbmQgYW4gZXhwbGlj aXQgImVuZA0KPiBjb25uZWN0aW9uIiBzaWduYWwuIE5ldHdvcmsgZGV2aWNlcyB3YW50IHRoaXMg dG8ga25vdyB3aGVuIHRvIGZyZWUNCj4gdGhlaXIgY29ubmVjdGlvbiB0cmFja2luZyBzdGF0ZSwg YnV0IGluIGEgbXVsdGlwYXRoIEludGVybmV0IEkgZG9uJ3QNCj4gcmVhZGlseSBob3cgdGhpcyB3 b3VsZCBiZSBhIHVzZWZ1bCBzaWduYWwgZWl0aGVyLg0KDQpUaGUgY29uY2VybiBhYm91dCB0aGUg ImVuZCIgc2lnbmFscyBpcyBwb3RlbnRpYWwgbWlzdXNlIC0tIHNvbWV0aGluZyBzaW1pbGFyIHRv IHNwb29maW5nIFRDUCBSU1QgLS0gdGhpbmsgIm1hbiBvbiB0aGUgc2lkZSIgYXR0YWNrcy4gVGhl IHNwb29mZWQgcGFja2V0cyB3aWxsIG5vdCBmb29sIHRoZSBlbmRwb2ludCwgYnV0IHRoZXkgY2Fu IGNhdXNlIGludGVybWVkaWF0ZSBzeXN0ZW1zIHRvIGRyb3Agc3RhdGUsIGFuZCBlZmZlY3RpdmVs eSBmb3JjZSBhbiBvbmdvaW5nIGNvbm5lY3Rpb24gdG8gc3RvcC4gQW55IGRlc2lnbiB3b3VsZCBo YXZlIHRvIHNvbWVob3cgbWl0aWdhdGUgdGhpcyBzcG9vZmluZyBhdHRhY2suDQoNCi0tIENocmlz dGlhbiBIdWl0ZW1hDQoNCg0K From nobody Mon Aug 1 15:02:56 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F5012D927 for ; Mon, 1 Aug 2016 15:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.809 X-Spam-Level: X-Spam-Status: No, score=-15.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwhlB-iyW8ps for ; Mon, 1 Aug 2016 15:02:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9169612D91A for ; Mon, 1 Aug 2016 15:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3454; q=dns/txt; s=iport; t=1470088974; x=1471298574; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=9i7/yw4PvILQv37X6oG+jtMb/m+OloutYYkbQWht21w=; b=iE5KfjfpSMieCNBpHfN5RPnMntOUTY24Y8esaaIif/vxkZsBPMTjXErX 2Ajn/x6KjrnoAK2nrzVflt5czFxs0B3xwfNDdua1y16zno0Au62S4d0aN Kd80Mq6ru1RWNkLR0cCqSQUVCBDv9mCGb/Id/XCycn8QqRXKnaM3j/JeN w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CgAwxp9X/xbLJq1dhEW7YoYdAoFtE?= =?us-ascii?q?AEBAQEBAQFdJ4RfAQUjVhALGCoCAlcGAQwIAQGILbBnkAQBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQERDogiglWHQYJaAQSZM4M6gXCJVYFVAYd9hWyQJzUfg3w6iB4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,457,1464652800"; d="asc'?scan'208";a="680479898" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 22:02:52 +0000 Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u71M2pO5005363; Mon, 1 Aug 2016 22:02:52 GMT To: Tom Herbert , Christian Huitema References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Eliot Lear Message-ID: <1351f583-93b4-b81f-b661-4fe61dd7a803@cisco.com> Date: Tue, 2 Aug 2016 00:02:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E7lAuRoGM4w1iepx1TSUEQ6QJScoVl0nr" Archived-At: Cc: spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Spencer Dawkins at IETF , Brian Trammell , Stephan Neuhaus , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:02:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E7lAuRoGM4w1iepx1TSUEQ6QJScoVl0nr Content-Type: multipart/mixed; boundary="BSDVRAgvVaOWf56NBNHqxs7GJ90bOV5H2" From: Eliot Lear To: Tom Herbert , Christian Huitema Cc: Spencer Dawkins at IETF , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Stephan Neuhaus , Brian Trammell , Stephen Farrell Message-ID: <1351f583-93b4-b81f-b661-4fe61dd7a803@cisco.com> Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: --BSDVRAgvVaOWf56NBNHqxs7GJ90bOV5H2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/1/16 10:52 PM, Tom Herbert wrote: > The question is also whether we need to send an explicit "end > connection" signal. Network devices want this to know when to free > their connection tracking state, but in a multipath Internet I don't > readily how this would be a useful signal either. > Look at that as an optimization. We always have to handle the case where the device drops dead or a process dies. Eliot --BSDVRAgvVaOWf56NBNHqxs7GJ90bOV5H2-- --E7lAuRoGM4w1iepx1TSUEQ6QJScoVl0nr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXn8cPAAoJEIe2a0bZ0nozIEQIAMiWuhdrIFgdI//3sYE5poR0 t4MyQRpbRhVKCY9Iy2gZfQw3aV/RFtsoPyvJ+oeOfbfCLryE38kX5qrcoHTfeUHj 3Wwq+c8kPK21Zc5jWTZ8+d9Tf7tNij8E967EZ6lXAKIEcKV4e/NLcZ9OrZ7Q47I6 uW0HPBdLJwC6YU5ZdPrLEl1pI3EqPEKuoDOSVeeaMozli34OfpwUM0Cgdfu3/2cj P3PObbLFrVuOR8vhRWzFx9Nd82l65VLpOVNkaq8Cghb1otz3nSt0Ef+KWO6PMp79 y/AYnftxk+Gu3WOpSScqo48WNlhZFIVxOIISUEVC0k6KY7OsDJpog6Vy/eoSGcA= =ydxy -----END PGP SIGNATURE----- --E7lAuRoGM4w1iepx1TSUEQ6QJScoVl0nr-- From nobody Tue Aug 2 00:47:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE0B12B008 for ; Tue, 2 Aug 2016 00:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBCNepS00eT6 for ; Tue, 2 Aug 2016 00:47:46 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D6712B035 for ; Tue, 2 Aug 2016 00:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8696; q=dns/txt; s=iport; t=1470124065; x=1471333665; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=V6qDePNefp4Ux7wV5w/ZQVGtRAEtoguez/TgYK39z/c=; b=Qhn3/KoUMkOT25IRcvboqJCokrzwxnbXD7/lJKXpA0OmJfc/+QdXt/x5 HJuJQlUuA3GdSzWJzwgE9Araq3sCbdYaIiS5737Inl5duYqG8WP8p933f 6vipH6uf1D1+1ptCEMAPRrtC5WaNCAe+gvuS1hGu1Gj7Pl1uqFrxt+bI3 o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DICACQT6BX/xbLJq1chEW0dIcDgmaDN?= =?us-ascii?q?wKCAwEBAQEBAV4nhF8BBAEjVgULCwQ+AgJXBgEMCAEBiCUIsQSQBwEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQ4OiCIIgk2EDIM1gloBBJkzgzqBcIlVgWuEWoMOhWyQJ?= =?us-ascii?q?1SCEhyBTjqISQEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,459,1464652800"; d="asc'?scan'208,217";a="639025745" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2016 07:47:43 +0000 Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u727lgje025530; Tue, 2 Aug 2016 07:47:42 GMT To: Tom Herbert , Spencer Dawkins at IETF References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Eliot Lear Message-ID: <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com> Date: Tue, 2 Aug 2016 09:47:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OI3i50SweanneBI5S5p1Mk5MkbReBWGx" Archived-At: Cc: Brian Trammell , Stephan Neuhaus , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 07:47:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0OI3i50SweanneBI5S5p1Mk5MkbReBWGx Content-Type: multipart/mixed; boundary="VgGAf2W18robeKAJD2D7Vgtqeb4sPkk3T" From: Eliot Lear To: Tom Herbert , Spencer Dawkins at IETF Cc: Stephan Neuhaus , Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud , Brian Trammell Message-ID: <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com> Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: --VgGAf2W18robeKAJD2D7Vgtqeb4sPkk3T Content-Type: multipart/alternative; boundary="------------86134EE86A2EDC12F3B23B4A" This is a multi-part message in MIME format. --------------86134EE86A2EDC12F3B23B4A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tom, On 8/1/16 10:06 PM, Tom Herbert wrote: > TOU will negotiate a session identifier (similar to connection > identifier) in QUIC. With this the TCP endpoints no longer use the > 5-tuple to identifier the connection, they use the session identifier. > This provides unambiguous connection identification that is > independent of addresses or encapsulating UDP ports (the most > immediate problem this resolves is NAT state remapping). Strong > security is required to prevent connection hijacking and there are a > couple of other caveats. Please look as section 3 in > draft-herbert-transports-over-udp for details. > TOU is similar in many ways to what HIP did in the early days, and the HIP developers had a pretty cool demo of it. The threats we faced back then were nowhere near as advanced as they are today, nor are they as prevalent. There is not a single platform upon which you base your software that hasn't been attacked successfully, although some have been attacked more regularly than others. Let me be as clear as I possibly can be: I view a protocol that doesn't offer an answer to the question =E2=80=9Cwho initiated the communication=E2= =80=9D as unsafe to be deployed on the Internet. I will make another bet with you, that at least half of your user base is running on old code with known vulnerabilities. This is even more critical on battery-powered constrained devices, where a broad-scaled and sustained DDoS attack could drain those batteries and harm a lot of people, in a short period of time. If there are tradeoffs to be made in mobility design because of this, then those tradeoffs should be made. But before you view it in that light, lengthy research has demonstrated that RF requires repeated selection queries to determine what is available. That is the work done by SCTP researchers such as Randy Stewart, and so mobility isn't being traded off at all.** You are seeking formal agreement of network behavior. I am seeking an answer to my question. If we formalize the answer to that question, then you have what you want and I have what I want. I've been told that QUIC has such an answer to my question, which is good. I'd like to understand how that is accomplished in a secure manner.=20 Certainly integrity protecting the 5-tuple and any sequence #s sounds like a good idea, to say the least, if it can be efficiently accomplished= =2E Eliot --------------86134EE86A2EDC12F3B23B4A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Tom,


On 8/1/16 10:06 PM, Tom Herbert wrote:= 

TOU will negotiate a session identifier (similar to =
connection
identifier) in QUIC. With this the TCP endpoints no longer use the
5-tuple to identifier the connection, they use the session identifier.
This provides unambiguous connection identification that is
independent of addresses or encapsulating UDP ports (the most
immediate problem this resolves is NAT state remapping). Strong
security is required to prevent connection hijacking and there are a
couple of other caveats. Please look as section 3 in
draft-herbert-transports-over-udp for details.

TOU is similar in many ways to what HIP did in the early days, and the HIP developers had a pretty cool demo of it.=C2=A0 The threats we= faced back then were nowhere near as advanced as they are today, nor are they as prevalent.=C2=A0 There is not a single platform upon whic= h you base your software that hasn't been attacked successfully, although some have been attacked more regularly than others.

Let me be as clear as I possibly can be: I view a protocol that doesn't offer an answer to the question =E2=80=9Cwho initiated the communication=E2=80=9D as unsafe to be deployed on the Internet.=C2=A0= I will make another bet with you, that at least half of your user base is running on old code with known vulnerabilities.=C2=A0 This is even mo= re critical on battery-powered constrained devices, where a broad-scaled and sustained DDoS attack could drain those batteries and harm a lot of people, in a short period of time.

If there are tradeoffs to be made in mobility design because of this, then those tradeoffs should be made.=C2=A0 But before you view = it in that light, lengthy research has demonstrated that RF requires repeated selection queries to determine what is available.=C2=A0 That= is the work done by SCTP researchers such as Randy Stewart, and so mobility isn't being traded off at all.

You are seeking formal agreement of network behavior.=C2=A0 I am seek= ing an answer to my question.=C2=A0 If we formalize the answer to that question, then you have what you want and I have what I want.=C2=A0 I= 've been told that QUIC has such an answer to my question, which is good.
I'd like to understand how that is accomplished in a secure manner.=C2= =A0 Certainly integrity protecting the 5-tuple and any sequence #s sounds like a good idea, to say the least, if it can be efficiently accomplished.

Eliot

--------------86134EE86A2EDC12F3B23B4A-- --VgGAf2W18robeKAJD2D7Vgtqeb4sPkk3T-- --0OI3i50SweanneBI5S5p1Mk5MkbReBWGx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXoFAeAAoJEIe2a0bZ0nozRtMH/AiVkOcwvwcKTMuI3OmYTpiU qFOMFXPgrMryXNP+TB4GA1A/6D6qrm3ZWB5ePe2SdOzGdx9KEDJ90XgvqRXd3g7Q 92X5di6QzjREepd6C856sRv4jpdbt4SWvdDJ+xX6tW6CeVf18eU17bJ+vDhH+qQA YYgnmj6O1ZJrncSUf1GnrYZwbHBuJzSUj8sTjVK3suUjnA2NF/2tNc0ob41JZR69 p6rgWNEZVivbpjCHib7CZEEPpfviZB20TeonAxzXoQdnMrcjooXYXa46gEz5uMe5 u+wlWoJMb+rd4nIeQJ5hYMevs5wW+pFV0frl1AUBioZ3ccUZid/Gu2W31ZAiBE4= =LdUa -----END PGP SIGNATURE----- --0OI3i50SweanneBI5S5p1Mk5MkbReBWGx-- From nobody Tue Aug 2 10:03:39 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38F12D0E5 for ; Tue, 2 Aug 2016 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoF2QNShP0A2 for ; Tue, 2 Aug 2016 10:03:35 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116A212D0A6 for ; Tue, 2 Aug 2016 10:03:34 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q83so219161363iod.1 for ; Tue, 02 Aug 2016 10:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OoaEtL+UuwX1otuypPXGN7Ci8NQtaHXLHZxoW7bt60U=; b=P1wNh/Q47PD0kvoWq6+Sr1w5BTbn8pMJhu6nSdCdpzJh+NAX3nxB/FPIsWwXmhcZM0 /Av6vHCbXHoTCNktcMjY1jMMs3cTxOIE7hTdz5z43nQI6zPWyL9KpY0PHqdK6yuk+wE4 XMQ2HxCDjT0xjgryJIVG0X/W8TKuZJzQsvdtx1SeY/5U55EPFI6de7VnM8R1btk9bU9h xA2ylmCE5tqpu1efMUMgY5bOq0WLzhdoOGsdfmYhd8PozCOD3IHZR2KegaXiYh1KeDel CuNpxabNy+tLdWTpyW1UIHipoyy4dfnsM1y8uQCMSXFy3J4+SO5/V7d5o5UuZe93IAFc 9Dag== 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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OoaEtL+UuwX1otuypPXGN7Ci8NQtaHXLHZxoW7bt60U=; b=gKbzPnYW4izjVq0Km/LY9eLTsp/q9subjxWgnxL3wRnhV0gaLB2p626MsCn8iJhq1E nNq20QfU5jC97rheRjfHCKwnf2VenTFSTdfGITD+wUGitBGoYdT+hCJlHdw8gRV+fv4C aleuCWQ+dCgR5O3k3YxRUzTDy3yvXJ44XitZ5CdjVM8Pu0MuxVQErpjYPyInO2IxuIHO bWB+4hy1IvvB7lpONF8n9ZoyU19gsK4H+K4xDtZ4/QdxQxUwkDvkTqSuUDEnOyKXtGIe 8x6LOUcNtMy4UrG1beJYtIomtl9YxfGDRpshoDSmQqSMN9XjeTAbEPh+cy4u+UankqIo Q4MA== X-Gm-Message-State: AEkoouvCoJnMyR1vv0kXJ7j9z6DlZyf2mFro4qLe3n2IsnBrvFKPzWS9KNLmjykgOcNVBummGYIhCJLJ9uN1RQ== X-Received: by 10.107.25.75 with SMTP id 72mr63659271ioz.50.1470157413537; Tue, 02 Aug 2016 10:03:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Tue, 2 Aug 2016 10:03:31 -0700 (PDT) In-Reply-To: <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com> From: Tom Herbert Date: Tue, 2 Aug 2016 10:03:31 -0700 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Spencer Dawkins at IETF , Stephan Neuhaus , Brian Trammell , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 17:03:37 -0000 On Tue, Aug 2, 2016 at 12:47 AM, Eliot Lear wrote: > Hi Tom, > > > On 8/1/16 10:06 PM, Tom Herbert wrote: > > TOU will negotiate a session identifier (similar to connection > identifier) in QUIC. With this the TCP endpoints no longer use the > 5-tuple to identifier the connection, they use the session identifier. > This provides unambiguous connection identification that is > independent of addresses or encapsulating UDP ports (the most > immediate problem this resolves is NAT state remapping). Strong > security is required to prevent connection hijacking and there are a > couple of other caveats. Please look as section 3 in > draft-herbert-transports-over-udp for details. > > > TOU is similar in many ways to what HIP did in the early days, and the HI= P > developers had a pretty cool demo of it. The threats we faced back then > were nowhere near as advanced as they are today, nor are they as prevalen= t. > There is not a single platform upon which you base your software that has= n't > been attacked successfully, although some have been attacked more regular= ly > than others. > > Let me be as clear as I possibly can be: I view a protocol that doesn't > offer an answer to the question =E2=80=9Cwho initiated the communication= =E2=80=9D as unsafe Eliot, With that view IP is completely unsafe and shouldn't be deployed since IP source addresses can and are trivially spoofed. Session identifiers with security that authenticates the peer provide an unambiguous and far more trustworthy answer to the question about who initiated a communication. > to be deployed on the Internet. I will make another bet with you, that a= t > least half of your user base is running on old code with known > vulnerabilities. This is even more critical on battery-powered constrain= ed > devices, where a broad-scaled and sustained DDoS attack could drain those > batteries and harm a lot of people, in a short period of time. > Yes, we all want DDoS prevention. But my application needs to be able to run securely on _every_ network on the planet. Unless you can prove that every one of these networks implements some common standard DDoS mitigation and other required security mechanisms, then I really have no choice but to treat the network is an insecure black box, assume my applications are at risk, and implement all of my own security. > If there are tradeoffs to be made in mobility design because of this, the= n > those tradeoffs should be made. But before you view it in that light, > lengthy research has demonstrated that RF requires repeated selection > queries to determine what is available. That is the work done by SCTP > researchers such as Randy Stewart, and so mobility isn't being traded off= at > all. > > You are seeking formal agreement of network behavior. I am seeking an > answer to my question. If we formalize the answer to that question, then > you have what you want and I have what I want. I've been told that QUIC = has > such an answer to my question, which is good. > I'd like to understand how that is accomplished in a secure manner. > Certainly integrity protecting the 5-tuple and any sequence #s sounds lik= e a > good idea, to say the least, if it can be efficiently accomplished. > To be clear I am not seeking formal agreement of universal network behavior (I believe that is supposed to be already covered by networking layer standards), we are trying to resolve protocol ossification to move the Internet forward. Protocol ossification happens in the network when devices anonymous to the endpoints attempt to interpret transport layer information to some effect and does this without the auspices of any standard. Usually this is with benevolent intent, but the problem is that when the end points attempt something "new" (e.g. TCP fast open, new TCP options, using SCTP, trying sustain connections between mobile networks) the network can break E2E communication in a variety of ways because the communication doesn't match _its_ concept of what a "legal" communication is. Encrypting the transport layer is the only proposed solution to defeat protocol ossification. I don't believe the PLUS proponents will argue against the rationale of encrypting the transport layer. Protocol ossification is a real problem and we can demonstrate several examples where it has thwarted innovation of transport protocols. What is at question is what transport layer information hosts are either required or should voluntarily "give back" once the transport layer is encrypted. IMO, from the perspective of a large application provider, the default answer is currently none. If signaling transport layer information were to be explicit between hosts and network devices, and there is an established trust relationship with an agreement the spells out the precise use of the information and the scope of information propagation-- then I think there is a much better chance to achieve the cooperation necessary to solve things like the mobile DDoS problem you mentioned above. I think the mobile guidance draft (draft-flinck-mobile-throughput-guidance) is on the right track in this regard, it make signals explicit and non-anonymous (although I don't like the part where they allow middleboxes to parse and modify TCP options, IMO this, as well as PLUS, should be using HBH options for host-network signaling). Explicit non-anonymous signaling can also adhere to the E2E model if network devices are expressly acting on behalf of a host with specific directives to do that. All of this is just my opinion, but it is why I had to hum no at the BOF... Thanks, Tom > Eliot > From nobody Tue Aug 2 17:36:00 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C6C12B03D; Tue, 2 Aug 2016 17:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=f84cr3B/; dkim=pass (1024-bit key) header.d=rsa.com header.b=E8mGLM2Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUAEwhOVSo1k; Tue, 2 Aug 2016 17:35:58 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A76B12B04A; Tue, 2 Aug 2016 17:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1470184558; x=1501720558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IZgs1QYN2RZYh6JVySPIephSaNvA6AvUhwEnq2H4chQ=; b=f84cr3B/gH6BWR+kWJI50AoJPZhTuW2RtVEjyrZcMMyALj0Z2hkjQisj RQOAcGmxGkp7XtbGbOIYXsYm7UHxqyI0NTHLAA3jEeonS7XCqPeejkXJw 0Qb7mlMDvBNg2QVhj7wTtiQMxPaQElCAptPLQg1q4naAD+DxEedOWYa/U s=; Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 05:35:57 +0500 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u730Zu71004943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Aug 2016 20:35:56 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u730Zu71004943 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1470184556; bh=o85b2Gk421YCUQfLX3HlM2+iaH0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=E8mGLM2ZTnO8t9YqDMaOVHG6WOFd3JwmRIZnhtC8BtLtmkyartWzpo/ZgQdrc1Ppn gM74mU/Z+CdXj0X7gvyJ1G2TYCrRU6KiNsSR6feBstvfg1mG8KGIXiSpJhx7OMjB5x d38BNh1NkgXJOIQBHQ6fyQISQ8Qr5CXyAOllZOo0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u730Zu71004943 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 2 Aug 2016 20:35:34 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u730Zjk1017226 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 2 Aug 2016 20:35:45 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Tue, 2 Aug 2016 20:35:44 -0400 From: "Black, David" To: Aaron Falk , spud Thread-Topic: [Spud] draft PLUS BoF minutes posted Thread-Index: AQHR53cHdznh6SyHfkiS5qKz4RS3Y6A2bt6g Date: Wed, 3 Aug 2016 00:35:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F6207E9MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "plus-chairs@ietf.org" Subject: Re: [Spud] draft PLUS BoF minutes posted X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 00:36:00 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F6207E9MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBvbmx5IHNlZSB0aGUgc2Vjb25kIGh1bSByZWNvcmRlZCBpbiB0aGUgbWludXRlcywgbm90IHRo ZSBmaXJzdCBvbmUgLi4uDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBTcHVkIFttYWlsdG86 c3B1ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWFyb24gRmFsaw0KU2VudDogVHVl c2RheSwgSnVseSAyNiwgMjAxNiAzOjUxIFBNDQpUbzogc3B1ZA0KQ2M6IHBsdXMtY2hhaXJzQGll dGYub3JnDQpTdWJqZWN0OiBbU3B1ZF0gZHJhZnQgUExVUyBCb0YgbWludXRlcyBwb3N0ZWQNCg0K VGhlIG5vdGVzIGZyb20gdGhlIFBMVVMgQm9GIGhhdmUgYmVlbiBwb3N0ZWQgYXMgZHJhZnQgbWlu dXRlcy4gIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvcnJlY3Rpb25zIHRvIHRoaXMgbGlzdC4g IE5pdHMgbWF5IGJlIHNlbnQgdG8gdGhlIGNoYWlycy4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTYvbWludXRlcy9taW51dGVzLTk2LXBsdXMNCg0K4oCUYWFyb24gJiBuYXRh c2hhDQo= --_000_CE03DB3D7B45C245BCA0D243277949362F6207E9MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBvbmx5IHNlZSB0aGUgc2Vj b25kIGh1bSByZWNvcmRlZCBpbiB0aGUgbWludXRlcywgbm90IHRoZSBmaXJzdCBvbmUgLi4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWFyb24gRmFsazxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBKdWx5IDI2LCAyMDE2IDM6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IHNwdWQ8YnI+DQo8 Yj5DYzo8L2I+IHBsdXMtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtTcHVk XSBkcmFmdCBQTFVTIEJvRiBtaW51dGVzIHBvc3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBub3RlcyBmcm9tIHRoZSBQTFVTIEJvRiBoYXZlIGJl ZW4gcG9zdGVkIGFzIGRyYWZ0IG1pbnV0ZXMuICZuYnNwO1BsZWFzZSBzZW5kIHN1YnN0YW50aXZl IGNvcnJlY3Rpb25zIHRvIHRoaXMgbGlzdC4gJm5ic3A7Tml0cyBtYXkgYmUgc2VudCB0byB0aGUg Y2hhaXJzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvbWludXRlcy9taW51dGVz LTk2LXBsdXMiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L21pbnV0ZXMvbWlu dXRlcy05Ni1wbHVzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igJRhYXJvbiAmYW1wOyBuYXRhc2hhPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE03DB3D7B45C245BCA0D243277949362F6207E9MX307CL04corpem_-- From nobody Wed Aug 3 02:08:09 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4381312D1AA for ; Wed, 3 Aug 2016 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hBCO9kIMRmka for ; Wed, 3 Aug 2016 02:08:05 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B321127078 for ; Wed, 3 Aug 2016 02:08:04 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id BA47E1A1166; Wed, 3 Aug 2016 11:07:33 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4DC0E581-8B4C-467E-8A06-B9AA8899CAEC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> Date: Wed, 3 Aug 2016 11:07:32 +0200 Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@c s.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Tuexen , Ted Hardie , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 09:08:07 -0000 --Apple-Mail=_4DC0E581-8B4C-467E-8A06-B9AA8899CAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, Thanks for this; I understand the concerns you have better, now. I have = a couple of questions, and one major point of remaining confusion, = inline, below: > On 01 Aug 2016, at 22:55, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 01/08/16 19:56, Ted Hardie wrote: >> On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell < >>=20 >>>=20 >>> IMO that case has not been made to the point where I would >>> consider it justifies privacy downsides. IOW, while I am of >>> course in favour of endpoints being able to signal to one >>> another without middlebox interference, I am not at all on >>> side with transport header integrity being counted as a major >>> win in the analysis of PLUS, if that "win" inherently requires >>> a significant privacy cost. (And I am clearly happy to endlessly >>> repeat myself that in this particular case: >>>=20 >>> extensibility =3D=3D privacy unfriendly >>>=20 >>>=20 >> Stephen, someone naively coming across this statement in the record = will >> think you mean that any extensibility is privacy unfriendly. = Obviously, >> you have championed the ability to shift cryptographic algorithms as = needs >> change, which requires extensibility of specific forms. Lots of = other >> work requires extensibility to be useful at all (imagine if the tag = space >> of the web had been frozen in 1993). >>=20 >> I should greatly appreciate you reformulating this into something = that >> actually matches your meaning. That would likely be useful; this is = not. >=20 > Sorry if there was context lacking and happy to try elucidate > further (and please do feel free to help improve my description of > the issue)... >=20 > In the specific case of exposing higher layer information about well > protected (e.g. encrypted) traffic to lower layers, (whether via an > interface from the higher layer, or via addition by the lower layers) > I believe any extensible mechanism for that kind of interface severely > risks being extremely privacy unfriendly. And the transport layer may > be the worst possible case of such an extensible higher/lower layer > interaction as it by definition spans the full "width" of the network. (Aside: I'll note again that this isn't the proposal. Transports expose = transport layer information that used to be available from inspection of = now-encrypted transport headers. Applications can help with this, and of = course the APIs should allow applications control over what gets said. = Preventing linkage between that information and higher-level data (e.g. = making sure that certain kinds of content aren't commonly tagged so as = to be fingerprintable) is a matter for careful design of the vocabulary. = It's clear we disagree as to whether it's possible to carefully design a = vocabulary that is large enough to be useful. I can't (yet) prove that = it is, but I strongly suspect so.) > I think the main reason is that there would be significant pressure > and temptation to try support non-technical policies being enforced > at one place in the network based on information provided at another. > In this case, by "non-technical," I mean any information not > absolutely necessary for the correct operation of the lower layer. > That's a term and definition I'm sure could be improved, and I'm also > sure there could be borderline cases. Of course, there's a fair range of opinion hiding behind that = "absolutely"; which point along that continuum do you mean? *All* of the = extended information we envision applications exposing to the path via = PLUS are intended to improve the performance and/or economy of the = network. Some of them we're pretty sure will work, while others will = require more experimentation to know. Let's say we're wildly successful = and PLUS signaling allows a network to operate at a given capacity with = M% less spectrum (due e.g. to unwanted traffic rejection before the = RAN), or reduce user-perceived latency by N% (loss/latency signaling and = other smarter queue management), or use P% less battery in aggregate = (due to better state management), or reduce operational diagnostic costs = by Q% (in-band measurement), with respect to an approach where we have = fully encrypted transport headers. What are the M, N, P, and Q values = that divide "absolutely necessary for correct operation" from = "non-technical information exposure"? > But there would immediately also be cases that are nowhere near any > border... such policies would almost certainly demand methods to = expose > personally identifying information or identifiers that can be easily > (re)identified as such. That would directly enable the kind of > meta-data collection and tracking that the IETF has agreed is an > attack in BCP188. (I assume here that no relevant lower layers "need" > PII to operate correctly - if they do, they are probably broken:-) >=20 > But another and possibly even worse (ab)use case might signal that the > person associated with a flow is a member of some set of people, for > example, over-18, a member of the ruling party, or of some minority. > The consequences of standardising that kind of extensibility in a way > that could allow such "policy enforcement" at essentially any place > on the Internet is for me supremely scary. >=20 > While there do doubtlessly exist use-cases for such extensibility in > this context that initially appear reasonable, the potential impact of > the abuse cases, and my own opinion of their probability of occurrence > being approx 1.0 at some place(s) and times on the big-I Internet for > me very much outweighs any potential utility from non-abuse cases of > this particular kind of extensibility. In your estimation, is the probability of occurrence of this kind of = abuse of the present protocol stack, at some places and times on the = big-I Internet, currently less than 1.0? (I know you think this question = is irrelevant. I'd just like to how bad you think things are today.) > As an aside, I fully accept > that folks arguing for non abuse-cases of extensibility are doing so > with good intentions. I think this is just an unusual case where our > normal ways of engineering extensibility are way more dangerous than > usual. (*) >=20 > In the case of the proposed charter at the BoF, the use of an IANA > registry seems particularly unwise to me as in addition to being > open to pressure to formally register privacy-unfriendly codepoints, Now I'm really confused. Of course this pressure exists. Are you arguing that a vocabulary = registry for a signaling protocol which requires a standards action to = modify is necessarily less resistant to this pressure than the standards = process itself? If so, can you explain the mechanism by which that is = the case? Because they seem like exactly the same thing to me. > any IANA-based scheme would also allow for squatting on codepoints, > which we know can become a fait-accompli. How is squatting on codepoints not equivalent to the abuse of widely = deployed protocols and implicit behaviors thereof? > I don't see any way in > which IETF/IANA processes could resist the pressure to provide such > "policy" support. When a registry is requires a standards action to add to, how is this = statement not equivalent to "The IETF standards process is incapable of = resisting the pressure to provide such policy support"? This seems quite = pessimistic, even to me. > I also cannot think of a non-IANA extensibility > mechanism that could work here and not have the privacy downsides. I at least fully agree with you that the IANA-managed extensibility is = as dangerous as or less dangerous than non-IANA managed extensibility. = So at least we have that. :) Thanks, cheers, Brian > And lastly, there is a significant difference here between existing > non-standard methods for injecting the above kinds of information > and a world in which we have standardised such extensibility. The > status quo may allow for such injection but the full horror of the > worst abuse-cases here would require that the abuse-case information > flow from end-to-end unimpeded (or almost end-to-end) so reliably > abusing that kind of information does I think require a standard. >=20 > Hopefully that's clearer, (it's definitely longer;-) and again, I'd > really welcome crisper and better text to describe these issues as > I'm sure it's a discussion that will recur at other times and places. >=20 > Cheers, > S. >=20 > (*) The "usual" dangers of extensibility are I guess complexity and > loss of interoperability, exemplified in the current debate about TLS > ciphersuite structure and TLS version intolerance. >=20 >>=20 >> thanks, >>=20 >> Ted >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_4DC0E581-8B4C-467E-8A06-B9AA8899CAEC 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXobRVAAoJEIoSt78L6kajH0EP/0KDVFXPO8eyC/fNl9tbbWo+ OwTiCUDmsmrklnNNceIhb6ZIUPW7kQab+jjjwddZfWUhOzLSVQPhyvpfU98qaypw P9UNwROtzc/ukvNzlVVoVeCrEExwSIzOpj0Ke84pNcm1FwFpQo17pQVxOmESZyQB c+GKQT5J8u0B79gQZ5QeDAU63A4Hdi37dCxCM/HBdOJTzmubjrgo8x9PDxMPHbw9 +obxjI6zudqAxGDKyCJvELDkSFbA8UtYC9B8RcazsQMomwVRvrl2UG9IiBW6twzn GmD7dFVOLAIo1XF6M+RzUrc2Y8YHo+usx5/e2LwtUQHk4Ui24U3xcmrDBhQHDfgL FL6D6Hlgoisg6ZsmqE+N0sBQjoUB5tybBfCO+82doh7cxBzFI+0TbF1t+KF3EWTH LWFb8Oz0lxG/hDlX5wDvPRCUqK8y00KXL1ANP4MIPBBGIHuTlYxWqBAPT01ILhHN E3AuyMHmeht3ne76zMKlE8kJNcjA4GQDHqQOdAlFslyxCjY2id4QGi82RDMYZo4z 7AQVeyY8ya2aJ23AhFPkgKuovcG1xzVAsLLANT6VWtjOfDbH32Rfv0miOBnEktY/ GsOzNgfvH2A+RfSLcU9skPGNQ3kAZngLO8vefAUWxmyzi6f4nKZedmsFPaO1HvvE MeAvE1Hcrby5lsRMK6GA =FYwM -----END PGP SIGNATURE----- --Apple-Mail=_4DC0E581-8B4C-467E-8A06-B9AA8899CAEC-- From nobody Wed Aug 3 04:00:08 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D503712D1BE for ; Wed, 3 Aug 2016 04:00:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0wsgfo1rD_V for ; Wed, 3 Aug 2016 04:00:03 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1064712D12D for ; Wed, 3 Aug 2016 04:00:03 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id w38so140034860qtb.0 for ; Wed, 03 Aug 2016 04:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cjuBf36RkurnsDPHsv2kFAnYYGpnUrC0MgGiI5F1qFs=; b=nNcOYXTr2Pm/xQVvR21jfWpFT6vHUZ5NZXREXipio5vtVNMHWB6ITjmQA2sMidXIu5 5AX7NqtZXKZmZUrrBybrvIvDYeX05+y4jqkmYU3cDFq0yrNI6pTymbXk31uaiw04Mgxd eFxIDhyS32E/HrOpkQ3Q0EBOmEmpUglO+VlcY= 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:from:date :message-id:subject:to:cc; bh=cjuBf36RkurnsDPHsv2kFAnYYGpnUrC0MgGiI5F1qFs=; b=hqnjnSViq8N0HL6Tnh4dIaBRqiVlp+bGBLUegb9/EXHEuxvtTrk6ku/e1+1ZLv0CtX Rx1TkzLBcOAu/5ShMBCgZDTPBzhry5idZ0cx6NRameadE9c+Y3BnhuSEcQHEg5R/9HlY FXDBEYFmD2A8HvUU2Yo0HYt812xZnFhIk1Aryb9sG7DiwArRkhK76pqENzdfKbJiOjqI 4/5xnUh6FfsEwdiqF3F5Nuap403y7L4LymRn+rvrYIrq61KR9VlgN6MbRJZ86DEd/yZ7 o+XZTRV9OhgnaSR+72MioQ+Hp/pXd0EanSs1/Vo20lNMfytfzpnqlzWOCDN/gVhijHFt txUw== X-Gm-Message-State: AEkoouuPaF5mWEzed0M0w/dWdEAuwQ9zIZ/R4kc3QHsb0MNM89BAWPa2Wxedx9tmw2/eG00bRwTXy23FfRTT6A== X-Received: by 10.200.55.27 with SMTP id o27mr106700890qtb.85.1470222002036; Wed, 03 Aug 2016 04:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Wed, 3 Aug 2016 04:00:01 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:d866:7f9f:ae1:b38a] In-Reply-To: <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> From: Kyle Rose Date: Wed, 3 Aug 2016 07:00:01 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113e6e5c2c3a72053928bcc0 Archived-At: Cc: Michael Tuexen , Brian Trammell , Ted Hardie , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 11:00:06 -0000 --001a113e6e5c2c3a72053928bcc0 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 1, 2016 at 4:55 PM, Stephen Farrell wrote: > But another and possibly even worse (ab)use case might signal that the > person associated with a flow is a member of some set of people, for > example, over-18, a member of the ruling party, or of some minority. > The consequences of standardising that kind of extensibility in a way > that could allow such "policy enforcement" at essentially any place > on the Internet is for me supremely scary. > I've been thinking and having offline conversations about this for a few days. (Sorry to lob a bomb and then disappear. Stupid work.) Perhaps ironically, this argument has basically re-convinced me that privacy at the routing layers on the public internet is hopeless. If your threat model concerns itself with coercion over a single bit of information, then the very architecture of the internet is completely broken: a government can simply issue even addresses to over-18's and odd addresses to under-18's. Enforce it at the ISPs and you're done. Continuing this line of thought, with IPv6 it seems pointless to worry about end-to-end survival of any metadata shorter than 64 bits (the host ID), which leaves 2^31 identifiers per human should a government want to enforce specific assignment of those addresses by ISPs. There's already far too much space baked in at the IP layer for a threat model that includes coercion of small amounts of metadata. A good argument might start with, "Twenty years from now, perhaps the internet will look a lot different than it does today." Which is something I've said myself, based on conversations with you and Dave Plonka. But I think we need lots more details on what that would actually look like to justify vetoing all extensibility mechanisms from now until that day comes. Worry doesn't seem sufficient justification given the implications of this kind of threat model and the demonstrable usefulness of extensibility: the architecture of a privacy-first internet needs to be fleshed out. For instance, what would an internet without plaintext source addresses look like? Without BCP38, what would we do to address (what are today spoofing-based) DoS attacks? I'm sympathetic to architectural changes like this, as from a security perspective the source address is simply a hint: it's 128 bits that the sender can almost always lie about. But an actual proposal is needed to know if an internet without them is even feasible. And even if we confirm that this new internet is deployable, there's still the whole problem of actually deploying it. If it requires starting from scratch as IPv7 because it won't interoperate with v6, it's going to be really hard to get adoption without using v4/v6 as a substrate, like TOR. At which point we might as well return to the approach of running smaller private internets over the public internet. I think there still are some good arguments being made that exposing any transport signaling to middle boxes creates further implicit ossification around multipath that need to be explored further, but at this point I'm unconvinced by the coercion argument given the internet we have. Kyle --001a113e6e5c2c3a72053928bcc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 1, 2016 at 4:55 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
But another = and possibly even worse (ab)use case might signal that the
person associated with a flow is a member of some set of people, for
example, over-18, a member of the ruling party, or of some minority.
The consequences of standardising that kind of extensibility in a way
that could allow such "policy enforcement" at essentially any pla= ce
on the Internet is for me supremely scary.

<= div>I've been thinking and having offline conversations about this for = a few days. (Sorry to lob a bomb and then disappear. Stupid work.)

P= erhaps ironically, this argument has basically re-convinced me that privacy= at the routing layers on the public internet is hopeless.

If your t= hreat model concerns itself with coercion over a single bit of information,= then the very architecture of the internet is completely broken: a governm= ent can simply issue even addresses to over-18's and odd addresses to u= nder-18's. Enforce it at the ISPs and you're done.

Continuing this line of thought, with IPv6 it seems pointless to worry ab= out end-to-end survival of any metadata shorter than 64 bits (the host ID),= which leaves 2^31 identifiers per human should a government want to enforc= e specific assignment of those addresses by ISPs. There's already far t= oo much space baked in at the IP layer for a threat model that includes coe= rcion of small amounts of metadata.

A good argument might= start with, "Twenty years from now, perhaps the internet will look a = lot different than it does today." Which is something I've said my= self, based on conversations with you and Dave Plonka. But I think we need = lots more details on what that would actually look like to justify vetoing = all extensibility mechanisms from now until that day comes. Worry doesn'= ;t seem sufficient justification given the implications of this kind of thr= eat model and the demonstrable usefulness of extensibility: the architectur= e of a privacy-first internet needs to be fleshed out.

For instance,= what would an internet without plaintext source addresses look like? Witho= ut BCP38, what would we do to address (what are today spoofing-based) DoS a= ttacks? I'm sympathetic to architectural changes like this, as from a s= ecurity perspective the source address is simply a hint: it's 128 bits = that the sender can almost always lie about. But an actual proposal is need= ed to know if an internet without them is even feasible. And even if we con= firm that this new internet is deployable, there's still the whole prob= lem of actually deploying it. If it requires starting from scratch as IPv7 = because it won't interoperate with v6, it's going to be really hard= to get adoption without using v4/v6 as a substrate, like TOR. At which poi= nt we might as well return to the approach of running smaller private inter= nets over the public internet.

I think there s= till are some good arguments being made that exposing any transport signali= ng to middle boxes creates further implicit ossification around multipath t= hat need to be explored further, but at this point I'm unconvinced by t= he coercion argument given the internet we have.

Kyle
=
--001a113e6e5c2c3a72053928bcc0-- From nobody Sat Aug 6 05:23:58 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D1912B02E for ; Sat, 6 Aug 2016 05:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgGj5yTtiSCf for ; Sat, 6 Aug 2016 05:23:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8035128E18 for ; Sat, 6 Aug 2016 05:23:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC956C0D6; Sat, 6 Aug 2016 13:23:47 +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 bEtiFASgDYWE; Sat, 6 Aug 2016 13:23:45 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F1E8AC0D1; Sat, 6 Aug 2016 13:23:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470486225; bh=s0O3lGvDhtVhZdUnMGNPLGroAgQJi45MAOJOgDgt8+0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cH7dbRVfla+5rLjUOJqXc88swpWXepyvHWt9J+rim+NNCtRwjDyjukpixhabyFunU RrjobZWK3nIzE5LfR7RNw3oiArOm7yqe4m9d1A/Z9V3y3i3WnviCInizdPAZdmdZi3 YRR0ad75XSWT1L2kBT12msbikos4cpeux3KcfiMg= To: Brian Trammell References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@c s.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 6 Aug 2016 13:23:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JLG3BxIRBXh2SQBBfAmJUesuHWN26ep9k" Archived-At: Cc: Michael Tuexen , Ted Hardie , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 12:23:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JLG3BxIRBXh2SQBBfAmJUesuHWN26ep9k Content-Type: multipart/mixed; boundary="odW2uTkdhPMoC07BvMw1sS36EDCGuo5Vs" From: Stephen Farrell To: Brian Trammell Cc: Ted Hardie , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Michael Tuexen Message-ID: Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@c s.tcd.ie> In-Reply-To: --odW2uTkdhPMoC07BvMw1sS36EDCGuo5Vs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Sorry for the slow response... On 03/08/16 10:07, Brian Trammell wrote: > hi Stephen, >=20 > Thanks for this; I understand the concerns you have better, now. I > have a couple of questions, and one major point of remaining > confusion, inline, below: >=20 >> On 01 Aug 2016, at 22:55, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >> On 01/08/16 19:56, Ted Hardie wrote: >>> On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell < >>>=20 >>>>=20 >>>> IMO that case has not been made to the point where I would=20 >>>> consider it justifies privacy downsides. IOW, while I am of=20 >>>> course in favour of endpoints being able to signal to one=20 >>>> another without middlebox interference, I am not at all on side >>>> with transport header integrity being counted as a major win in >>>> the analysis of PLUS, if that "win" inherently requires a >>>> significant privacy cost. (And I am clearly happy to endlessly=20 >>>> repeat myself that in this particular case: >>>>=20 >>>> extensibility =3D=3D privacy unfriendly >>>>=20 >>>>=20 >>> Stephen, someone naively coming across this statement in the >>> record will think you mean that any extensibility is privacy >>> unfriendly. Obviously, you have championed the ability to shift >>> cryptographic algorithms as needs change, which requires >>> extensibility of specific forms. Lots of other work requires >>> extensibility to be useful at all (imagine if the tag space of >>> the web had been frozen in 1993). >>>=20 >>> I should greatly appreciate you reformulating this into something >>> that actually matches your meaning. That would likely be useful; >>> this is not. >>=20 >> Sorry if there was context lacking and happy to try elucidate=20 >> further (and please do feel free to help improve my description of=20 >> the issue)... >>=20 >> In the specific case of exposing higher layer information about >> well protected (e.g. encrypted) traffic to lower layers, (whether >> via an interface from the higher layer, or via addition by the >> lower layers) I believe any extensible mechanism for that kind of >> interface severely risks being extremely privacy unfriendly. And >> the transport layer may be the worst possible case of such an >> extensible higher/lower layer interaction as it by definition spans >> the full "width" of the network. >=20 > (Aside: I'll note again that this isn't the proposal. That's not clear to me. I really can't see how one does what would work for f/w folks without running into this risk. I fully accept that many proponents of PLUS don't want to see the privacy-unfriendly outcome I fear. > Transports > expose transport layer information that used to be available from > inspection of now-encrypted transport headers. Applications can help > with this, and of course the APIs should allow applications control > over what gets said. Preventing linkage between that information and > higher-level data (e.g. making sure that certain kinds of content > aren't commonly tagged so as to be fingerprintable) is a matter for > careful design of the vocabulary. It's clear we disagree as to > whether it's possible to carefully design a vocabulary that is large > enough to be useful. I can't (yet) prove that it is, but I strongly > suspect so.) Determining if such a safe vocabulary is or is not possible seems like a fine bit of work to undertake for those keen on PLUS. >=20 >> I think the main reason is that there would be significant >> pressure and temptation to try support non-technical policies being >> enforced at one place in the network based on information provided >> at another. In this case, by "non-technical," I mean any >> information not absolutely necessary for the correct operation of >> the lower layer. That's a term and definition I'm sure could be >> improved, and I'm also sure there could be borderline cases. >=20 > Of course, there's a fair range of opinion hiding behind that > "absolutely"; which point along that continuum do you mean? *All* of > the extended information we envision applications exposing to the > path via PLUS are intended to improve the performance and/or economy > of the network. Some of them we're pretty sure will work, while > others will require more experimentation to know. Let's say we're > wildly successful and PLUS signaling allows a network to operate at a > given capacity with M% less spectrum (due e.g. to unwanted traffic > rejection before the RAN), or reduce user-perceived latency by N% > (loss/latency signaling and other smarter queue management), or use > P% less battery in aggregate (due to better state management), or > reduce operational diagnostic costs by Q% (in-band measurement), with > respect to an approach where we have fully encrypted transport > headers. What are the M, N, P, and Q values that divide "absolutely > necessary for correct operation" from "non-technical information > exposure"? >=20 >> But there would immediately also be cases that are nowhere near >> any border... such policies would almost certainly demand methods >> to expose personally identifying information or identifiers that >> can be easily (re)identified as such. That would directly enable >> the kind of meta-data collection and tracking that the IETF has >> agreed is an attack in BCP188. (I assume here that no relevant >> lower layers "need" PII to operate correctly - if they do, they are >> probably broken:-) >>=20 >> But another and possibly even worse (ab)use case might signal that >> the person associated with a flow is a member of some set of >> people, for example, over-18, a member of the ruling party, or of >> some minority. The consequences of standardising that kind of >> extensibility in a way that could allow such "policy enforcement" >> at essentially any place on the Internet is for me supremely >> scary. >>=20 >> While there do doubtlessly exist use-cases for such extensibility >> in this context that initially appear reasonable, the potential >> impact of the abuse cases, and my own opinion of their probability >> of occurrence being approx 1.0 at some place(s) and times on the >> big-I Internet for me very much outweighs any potential utility >> from non-abuse cases of this particular kind of extensibility. >=20 > In your estimation, is the probability of occurrence of this kind of > abuse of the present protocol stack, at some places and times on the > big-I Internet, currently less than 1.0? (I know you think this > question is irrelevant. I'd just like to how bad you think things are > today.) >=20 >> As an aside, I fully accept that folks arguing for non abuse-cases >> of extensibility are doing so with good intentions. I think this is >> just an unusual case where our normal ways of engineering >> extensibility are way more dangerous than usual. (*) >>=20 >> In the case of the proposed charter at the BoF, the use of an IANA=20 >> registry seems particularly unwise to me as in addition to being=20 >> open to pressure to formally register privacy-unfriendly >> codepoints, >=20 > Now I'm really confused. >=20 > Of course this pressure exists. Are you arguing that a vocabulary > registry for a signaling protocol which requires a standards action > to modify is necessarily less resistant to this pressure than the > standards process itself? If so, can you explain the mechanism by > which that is the case? Because they seem like exactly the same thing > to me. I do think the IANA route is necessarily more risky yes. I do not claim that there exists an acceptably risky non-IANA approach. The reason is that if there is an IANA registry for extensibility then that a) allows squatting and b) constrains protocol design, e.g. to protocols that allow for a large enough codepoint-space. To try be more concrete: without an IANA registry one could design a protocol with one octet of space for some features and one could ensure that all bits have defined, useful semantics. It would then be possible to ensure that extending the protocol would generate backwards compatibility issues. I am not saying that that would be a good design or a good outcome, but I do think that any IANA based scheme for extensibility is, in this case, necessarily more risky. >=20 >> any IANA-based scheme would also allow for squatting on >> codepoints, which we know can become a fait-accompli. >=20 > How is squatting on codepoints not equivalent to the abuse of widely > deployed protocols and implicit behaviors thereof? Squatting is easier. And formalising the recognition of squatted codepoints is also easier. >=20 >> I don't see any way in which IETF/IANA processes could resist the >> pressure to provide such "policy" support. >=20 > When a registry is requires a standards action to add to, how is this > statement not equivalent to "The IETF standards process is incapable > of resisting the pressure to provide such policy support"? This seems > quite pessimistic, even to me. See above. Maybe this explanation might help too: we create IANA registries for good reasons, one primary one being that those make it easier to extend protocols. For protocols where we do not want extensions to be easy, we ought only very carefully create IANA registries. Cheers, S. >=20 >> I also cannot think of a non-IANA extensibility mechanism that >> could work here and not have the privacy downsides. >=20 > I at least fully agree with you that the IANA-managed extensibility > is as dangerous as or less dangerous than non-IANA managed > extensibility. So at least we have that. :) >=20 > Thanks, cheers, >=20 > Brian >=20 >> And lastly, there is a significant difference here between >> existing non-standard methods for injecting the above kinds of >> information and a world in which we have standardised such >> extensibility. The status quo may allow for such injection but the >> full horror of the worst abuse-cases here would require that the >> abuse-case information flow from end-to-end unimpeded (or almost >> end-to-end) so reliably abusing that kind of information does I >> think require a standard. >>=20 >> Hopefully that's clearer, (it's definitely longer;-) and again, >> I'd really welcome crisper and better text to describe these issues >> as I'm sure it's a discussion that will recur at other times and >> places. >>=20 >> Cheers, S. >>=20 >> (*) The "usual" dangers of extensibility are I guess complexity >> and loss of interoperability, exemplified in the current debate >> about TLS ciphersuite structure and TLS version intolerance. >>=20 >>>=20 >>> thanks, >>>=20 >>> Ted >>>=20 >>=20 >> _______________________________________________ Spud mailing list=20 >> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >=20 --odW2uTkdhPMoC07BvMw1sS36EDCGuo5Vs-- --JLG3BxIRBXh2SQBBfAmJUesuHWN26ep9k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXpdbQAAoJEC88hzaAX42i5u8H/3L3rGpvwQ5Fjjz/1L+tm962 9oWB/A2N84pKiVJIn6M8GJO3NtZkr6f7QK4wEoTzWidic31T4OmsVlKLGHmEElJx IJEvhpM26ltDG7j/8E3RX/qdgzmVZ/KnlX9OFwRGcHq0qHChcKlcxVEqOyxiAK0b 5WkzBy0HNRwSts2TUEt32UkXFrL+QWUS1NCe36MnTyNH6hSUn8M+jMB2uQBeRVSH 5xOdVpNpUj6PX3jCN0Dy1IQ+gZNf9eb5E9RnDUbOxi+eke0FQIeep0T8E+NkIeqv 81AXbSBlgfUrcBtVugOWqRmUsNWpbIIYuHQqdPRbmoFi/z/gxg6uJOaHMkmWpWI= =/fJP -----END PGP SIGNATURE----- --JLG3BxIRBXh2SQBBfAmJUesuHWN26ep9k-- From nobody Sat Aug 6 05:38:44 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589B12B056 for ; Sat, 6 Aug 2016 05:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v79qCpwTs_rH for ; Sat, 6 Aug 2016 05:38:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890B612B02E for ; Sat, 6 Aug 2016 05:38:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37BDDC0C3; Sat, 6 Aug 2016 13:38:39 +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 9F-TGx_DDfZ1; Sat, 6 Aug 2016 13:38:37 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 13B92C09F; Sat, 6 Aug 2016 13:38:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470487117; bh=QR9q8b7KMRLt7K1DF0dQWGl3ujwtvRTZvd6PG1QdKnc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kgy8gCnLKs451f7DyVbOjbBCUQ9/0Za+SsS6+26VswuQTLW0U4rUptW5bFi6ubdAq YOlk+QCfUVgklmwccgxwPPZtyeeoFLrKN1OOTY4MJ6FyTPFAb7Rf1Ohi2EPRm+IvLM +hWySkNOVbP7/IfCMpjSJCo9Dan0O9mmjr8yqZn4= To: Kyle Rose References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 6 Aug 2016 13:38:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010308040603070303000505" Archived-At: Cc: Michael Tuexen , Brian Trammell , Ted Hardie , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 12:38:42 -0000 This is a cryptographically signed message in MIME format. --------------ms010308040603070303000505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kyle, Again, sorry for the slow response. But we're likely evens on that:-) On 03/08/16 12:00, Kyle Rose wrote: > On Mon, Aug 1, 2016 at 4:55 PM, Stephen Farrell > wrote: >=20 >> But another and possibly even worse (ab)use case might signal that the= >> person associated with a flow is a member of some set of people, for >> example, over-18, a member of the ruling party, or of some minority. >> The consequences of standardising that kind of extensibility in a way >> that could allow such "policy enforcement" at essentially any place >> on the Internet is for me supremely scary. >> >=20 > I've been thinking and having offline conversations about this for a fe= w > days. (Sorry to lob a bomb and then disappear. Stupid work.) >=20 > Perhaps ironically, this argument has basically re-convinced me that > privacy at the routing layers on the public internet is hopeless. FWIW, I never agree that privacy is hopeless. And even if it, in some sense, were, I firmly believe that we can choose to make the Internet worse wrt privacy or to not do that. So even if we cannot "solve" the "privacy problem," there is still an onus on us (as good engineers) to not make that worse and to define tooling that would allow folks to make things better should they later choose to deploy those tools. (That last has to be done quite selectively though, only after some tool looks like it might get at least some real traction, as otherwise we enter the realm of speculative research and not engineering.) IOW - it is not hopeless and the sky is not falling:-) Also - I'm not sure what you mean by "routing layers" nor how that maps to the transport issues SPUD/PLUS is trying to address. >=20 > If your threat model concerns itself with coercion over a single bit of= > information, then the very architecture of the internet is completely > broken: a government can simply issue even addresses to over-18's and o= dd > addresses to under-18's. Enforce it at the ISPs and you're done. Yes, that and many other abominations could theoretically be attempted. In that and many cases though the other endpoint would not (in general) know of the silly addressing scheme. If we standardise such, then all endpoints know of the silliness and the situation is worse. I'm also not sure that coercion is the right term for this part of the problem. At least as I envisage things, if a middlebox can ever add a standardised extensible value to the flow, then we are likely to run into these issues. It's very unclear to me that SPUD/PLUS can work and not allow such addition whilst also not introducing new round-trips. But we'll need to wait and see what the PLUS proponents actually propose before we can really analyse that. Cheers, S. >=20 > Continuing this line of thought, with IPv6 it seems pointless to worry > about end-to-end survival of any metadata shorter than 64 bits (the hos= t > ID), which leaves 2^31 identifiers per human should a government want t= o > enforce specific assignment of those addresses by ISPs. There's already= far > too much space baked in at the IP layer for a threat model that include= s > coercion of small amounts of metadata. >=20 > A good argument might start with, "Twenty years from now, perhaps the > internet will look a lot different than it does today." Which is someth= ing > I've said myself, based on conversations with you and Dave Plonka. But = I > think we need lots more details on what that would actually look like t= o > justify vetoing all extensibility mechanisms from now until that day co= mes. > Worry doesn't seem sufficient justification given the implications of t= his > kind of threat model and the demonstrable usefulness of extensibility: = the > architecture of a privacy-first internet needs to be fleshed out. >=20 > For instance, what would an internet without plaintext source addresses= > look like? Without BCP38, what would we do to address (what are today > spoofing-based) DoS attacks? I'm sympathetic to architectural changes l= ike > this, as from a security perspective the source address is simply a hin= t: > it's 128 bits that the sender can almost always lie about. But an actua= l > proposal is needed to know if an internet without them is even feasible= =2E > And even if we confirm that this new internet is deployable, there's st= ill > the whole problem of actually deploying it. If it requires starting fro= m > scratch as IPv7 because it won't interoperate with v6, it's going to be= > really hard to get adoption without using v4/v6 as a substrate, like TO= R. > At which point we might as well return to the approach of running small= er > private internets over the public internet. >=20 > I think there still are some good arguments being made that exposing an= y > transport signaling to middle boxes creates further implicit ossificati= on > around multipath that need to be explored further, but at this point I'= m > unconvinced by the coercion argument given the internet we have. >=20 > Kyle >=20 --------------ms010308040603070303000505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDYx MjM4MzZaMC8GCSqGSIb3DQEJBDEiBCBsUkLg+ogFsuCatX1+SWQCFQnvsmWcCEWHnD6yctwK uTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBxmc73Y8qySrYJ24Mar3+QrjRcleU6UfdBRKBvPDFt7UstFzjjVx5y YRKBps5kISnsM199oGr9R1aEhezdhX/yEfJFbIzIbY0I7oqvXq7eBBx9Qz90z+fiDhsvthB+ BFwuLjflxbarxOxohmoRCT3XwZLvNLT554i3Z7S89JM6gC6GtXiDiO5qxqye5ijTRgPtvLa9 1KCe/CBOKyw28oVSLqffhRMdBqh2+COR2CZJompAAa3Vbbi1fIo1B/35mGQGqJR1YrTjHvB1 UcWa7+kOfnD3Sb378GRP4BHzJowd9zsx+NOx/CfjfiWO7THhwyL+33bwqRuW3g8vcwpN2MdY AAAAAAAA --------------ms010308040603070303000505-- From nobody Wed Aug 10 05:41:46 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3612B076 for ; Wed, 10 Aug 2016 05:41:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk3r3YPA7jvL for ; Wed, 10 Aug 2016 05:41:36 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE3212D0FF for ; Wed, 10 Aug 2016 05:41:35 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 52so19915788qtq.3 for ; Wed, 10 Aug 2016 05:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xT9h+OQhi5q6C/D2iChWaQKZ2/+xezJex5oVTN+tlz8=; b=pHV6sk4CeNI1cC+Yfh+wB29LZIhWkKZ5etgBEhEHMeJ5SXZYu8qbGnH0J88R1MMZrG ZjFdgdKV7hTfitBrl0jINjp/kgBL5BDE3Xg+oTOXLzowYkM/JEBfihwHH2X9HBOYCOxv szQ80pdbcnVsgEWpytXRmLpMUeWxGD4rc2fn4= 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:from:date :message-id:subject:to:cc; bh=xT9h+OQhi5q6C/D2iChWaQKZ2/+xezJex5oVTN+tlz8=; b=OsUWirUubFT2ooNUGHacIKZh9+Ey30au1jWmL5G7DLrRIgZ7kU5BqR3ZIDw4JOWIio Cdmb3slAqMsDpdsBEE11U+ZOC8M8h2fb01NWdXEqx5OcpyRKgfZ/vwlwluxPyTGOhoyL TcbI9TkmVRLojtAgC8FdmFDXgLDO3Gx6/DrGJUY/7KiEi02j9YXrpaZDfX4Zu0Cfw06O hMXLwx+aoK5xFoLBCAVyBqVxZKn7YmpgK88D3NJejv20VHOYoUSJ+aC0kVEFxZIsiMLr keVNKBaQ7Z2LSG7d6hxp3i4HKZLpgmL+QfM5Rt3SOFGNTaQsnIaTbKZFDs3m/uaD92bt vFSQ== X-Gm-Message-State: AEkoouvpOd5rlolw3O2Aaz5ytC3ZNkpqu7t/xALHv5MjJDjL/O/guoNo6MvcXJrPfbtEWQY0o31mz+puLyA0mg== X-Received: by 10.237.45.135 with SMTP id i7mr4071432qtd.30.1470832894980; Wed, 10 Aug 2016 05:41:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Wed, 10 Aug 2016 05:41:33 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:a85a:f18f:f2c0:e72d] In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie> From: Kyle Rose Date: Wed, 10 Aug 2016 08:41:33 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c069e183acbbb0539b6f802 Archived-At: Cc: Michael Tuexen , Brian Trammell , Ted Hardie , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 12:41:40 -0000 --94eb2c069e183acbbb0539b6f802 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 6, 2016 at 8:38 AM, Stephen Farrell wrote: > > Hi Kyle, > > Again, sorry for the slow response. But we're likely evens on that:-) > And again for me. :-) > > Perhaps ironically, this argument has basically re-convinced me that > > privacy at the routing layers on the public internet is hopeless. > > FWIW, I never agree that privacy is hopeless. > I'll agree that "hopeless" is a bit hyperbolic, but the degree of hopelessness depends on what the threat model is. For coercion of single bits, I'm willing to stand by that phrasing. > And even if it, in some sense, were, I firmly believe that we can > choose to make the Internet worse wrt privacy or to not do that. > > So even if we cannot "solve" the "privacy problem," there is still > an onus on us (as good engineers) to not make that worse and to define > tooling that would allow folks to make things better should they later > choose to deploy those tools. (That last has to be done quite > selectively though, only after some tool looks like it might get at > least some real traction, as otherwise we enter the realm of speculative > research and not engineering.) > A necessary element to the approach you outline is having a coherent vision for what we want a privacy-first internet to look like, and how we would get there. I don't think an incremental approach based on RFC 6973 and derivatives is going to achieve that because so far what I see is a blanket prohibition on extensibility out of fear that some mechanism could be used for nefarious purposes, when what protocol designers need is guidance on what they *can* do. The threat model in 7624 may be a good starting point for this, but the prohibitions implied there need to be inverted into a set of design guidelines that the IAB considers acceptable. I don't think the black box approach to standards approval is the right one, but it feels like that's where we are without explicit guidance. Furthermore, during the transition phase between the internet of 2016 and the internet of 2036, we can't hamstring all standards development because not all the building blocks for the privacy-first internet are in place. Users have needs, and if they aren't fulfilled by the IESG, users will migrate to getting their standards elsewhere, and everyone will be worse off from the resulting fragmentation. Our sweet spot is not standing athwart all development, yelling "stop!": it's balancing individual user needs and wider privacy concerns and standardizing something that will work well enough that people use it, that don't materially worsen the existing privacy problems, and that we can show will improve such things over time. (Emphasis on "show".) We don't have dictatorial control over the internet, but a lot of these discussions seem to implicitly frame the problem that way. If we don't give users what they want, we risk becoming irrelevant. Concern about one bit seems not to fit with a balanced approach; worrying about a generic key/value mechanism not under endpoint control probably does. Where do we draw the line, and why? > Also - I'm not sure what you mean by "routing layers" nor how that > maps to the transport issues SPUD/PLUS is trying to address. > Sorry, by "routing layers" I mean essentially the metadata that must be made known to third-party network elements in order to direct packets to a logical destination: DNS requests and the destination address in a packet are the most obvious of these, but it also includes things like SNI for certain layer 3 routers and load balancers. I think we would both (all?) agree that today there is too much public metadata, and that metadata is not narrowly directed at only those network devices that actually need it. I would argue we need to start scoping out possible reductions in this envelope, both in a v6 internet and in an ideal world with the protocols we really want. We can then express balanced guidance on privacy protections for the internet we have, allowing standards development to continue for users' real-world needs, while also moving forward in the research/experimental direction toward the internet we want. Constraining standards development in the internet we have based on what's possible in the internet we want, but haven't scoped or defined, and that we might get at some undetermined point in the future, is not acting in the interests of users. > In that and many cases though the other endpoint would not (in general) > know of the silly addressing scheme. If we standardise such, then all > endpoints know of the silliness and the situation is worse. > Understood, but the even/odd address thing is something any ISP or government can unilaterally implement and enforce for all of its own users: it requires no further standards work. At least with IPv6, I'd argue the only unilateral mitigation for this kind of concern is to shut off the network. So including this in the threat model as anything other than "accepted risk" effectively shuts down all discussion of protocol extensibility. > I'm also not sure that coercion is the right term for this part of the > problem. At least as I envisage things, if a middlebox can ever add a > standardised extensible value to the flow, then we are likely to run > into these issues. I read your initial objection as 'the ISP can make the user add this information, or a blank space for fill-in by path elements, to its PLUS header before signing'. Coercing users into adding either the information itself or a blank space for the information (such that modifications to that value are allowed by recipient stacks, even in the presence of a MAC for the keys and all the other values) seems like the general threat here. For each specific threat, the two relevant follow-up questions seem to be: (1) How does this extension make privacy more difficult to achieve than it is today? (2) How does this extension make privacy more difficult to achieve than it would otherwise be under this new internet we'll have deployed X years from now, and is the objection relevant if the protocol stack will look entirely different? I am using a comparative ("more difficult") rather than an absolute (e.g., "unachievable") because there are other, heavier-weight approaches like TOR that can give us a lot of what we want on top of the public internet of today. It's very unclear to me that SPUD/PLUS can work and > not allow such addition whilst also not introducing new round-trips. > But we'll need to wait and see what the PLUS proponents actually > propose before we can really analyse that. > I think the burden is on both sides of the argument: the PLUS proponents need to demonstrate a need and a protocol that narrowly achieves that need, and privacy advocates need to come to some public agreement on what degree of extensibility is okay, and formalize that so protocol designers aren't shooting arrows in the dark or at a moving target. Kyle --94eb2c069e183acbbb0539b6f802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Aug 6, 2016 at 8:38 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

Hi Kyle,

Again, sorry for the slow response. But we're likely evens on that:-)

And again for me. :-)
=C2= =A0
> Perhaps ironically, this argument has basically re-co= nvinced me that
> privacy at the routing layers on the public internet is hopeless.

FWIW, I never agree that privacy is hopeless.
<= br>
I'll agree that "hopeless" is a bit hyperbolic,= but the degree of hopelessness depends on what the threat model is. For co= ercion of single bits, I'm willing to stand by that phrasing.
=
=C2=A0
And even if it, in some sense, were, I firmly believe that we can
choose to make the Internet worse wrt privacy or to not do that.

So even if we cannot "solve" the "privacy problem," the= re is still
an onus on us (as good engineers) to not make that worse and to define
tooling that would allow folks to make things better should they later
choose to deploy those tools. (That last has to be done quite
selectively though, only after some tool looks like it might get at
least some real traction, as otherwise we enter the realm of speculative research and not engineering.)

A necess= ary element to the approach you outline is having a coherent vision for wha= t we want a privacy-first internet to look like, and how we would get there= . I don't think an incremental approach based on RFC 6973 and derivativ= es is going to achieve that because so far what I see is a blanket prohibit= ion on extensibility out of fear that some mechanism could be used for nefa= rious purposes, when what protocol designers need is guidance on what they = *can* do.

The threat model in 7624 may be a good starting point for = this, but the prohibitions implied there need to be inverted into a set of = design guidelines that the IAB considers acceptable. I don't think the = black box approach to standards approval is the right one, but it feels lik= e that's where we are without explicit guidance.

Furt= hermore, during the transition phase between the internet of 2016 and the i= nternet of 2036, we can't hamstring all standards development because n= ot all the building blocks for the privacy-first internet are in place. Use= rs have needs, and if they aren't fulfilled by the IESG, users will mig= rate to getting their standards elsewhere, and everyone will be worse off f= rom the resulting fragmentation. Our sweet spot is not standing athwart all= development, yelling "stop!": it's balancing individual user= needs and wider privacy concerns and standardizing something that will wor= k well enough that people use it, that don't materially worsen the exis= ting privacy problems, and that we can show will improve such things over t= ime. (Emphasis on "show".)

We don't have dictatorial c= ontrol over the internet, but a lot of these discussions seem to implicitly= frame the problem that way. If we don't give users what they want, we = risk becoming irrelevant.

Concern about one bit seems not= to fit with a balanced approach; worrying about a generic key/value mechan= ism not under endpoint control probably does. Where do we draw the line, an= d why?
=C2=A0
Also - I'm not sure what you mean by "routing layers" nor how= that
maps to the transport issues SPUD/PLUS is trying to address.

Sorry, by "routing layers" I mean essential= ly the metadata that must be made known to third-party network elements in = order to direct packets to a logical destination: DNS requests and the dest= ination address in a packet are the most obvious of these, but it also incl= udes things like SNI for certain layer 3 routers and load balancers.
I think we would both (all?) agree that today there is too much= public metadata, and that metadata is not narrowly directed at only those = network devices that actually need it. I would argue we need to start scopi= ng out possible reductions in this envelope, both in a v6 internet and in a= n ideal world with the protocols we really want. We can then express balanc= ed guidance on privacy protections for the internet we have, allowing stand= ards development to continue for users' real-world needs, while also mo= ving forward in the research/experimental direction toward the internet we = want.

Constraining standards development in the internet we have bas= ed on what's possible in the internet we want, but haven't scoped o= r defined, and that we might get at some undetermined point in the future, = is not acting in the interests of users.
=C2=A0
In that and many cases though the other endpoint would not (in general)
know of the silly addressing scheme. If we standardise such, then all
endpoints know of the silliness and the situation is worse.

Understood, but the even/odd address thing is somethin= g any ISP or government can unilaterally implement and enforce for all of i= ts own users: it requires no further standards work. At least with IPv6, I&= #39;d argue the only unilateral mitigation for this kind of concern is to s= hut off the network. So including this in the threat model as anything othe= r than "accepted risk" effectively shuts down all discussion of p= rotocol extensibility.
=C2=A0
I'm also not sure that coercion is the right term for this part of the<= br> problem. At least as I envisage things, if a middlebox can ever add a
standardised extensible value to the flow, then we are likely to run
into these issues.

I read your initial obje= ction as 'the ISP can make the user add this information, or a blank sp= ace for fill-in by path elements, to its PLUS header before signing'. C= oercing users into adding either the information itself or a blank space fo= r the information (such that modifications to that value are allowed by rec= ipient stacks, even in the presence of a MAC for the keys and all the other= values) seems like the general threat here.

For each spe= cific threat, the two relevant follow-up questions seem to be:

(1) H= ow does this extension make privacy more difficult to achieve than it is to= day?
(2) How does this extension make privacy more difficult = to achieve than it would otherwise be under this new internet we'll hav= e deployed X years from now, and is the objection relevant if the protocol = stack will look entirely different?

I am using a comparat= ive ("more difficult") rather than an absolute (e.g., "unach= ievable") because there are other, heavier-weight approaches like TOR = that can give us a lot of what we want on top of the public internet of tod= ay.

It's very u= nclear to me that SPUD/PLUS can work and
not allow such addition whilst also not introducing new round-trips.
But we'll need to wait and see what the PLUS proponents actually
propose before we can really analyse that.

<= div>I think the burden is on both sides of the argument: the PLUS proponent= s need to demonstrate a need and a protocol that narrowly achieves that nee= d, and privacy advocates need to come to some public agreement on what degr= ee of extensibility is okay, and formalize that so protocol designers aren&= #39;t shooting arrows in the dark or at a moving target.
=C2= =A0
Kyle

--94eb2c069e183acbbb0539b6f802-- From nobody Fri Aug 19 15:32:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8212B024 for ; Fri, 19 Aug 2016 15:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 W3PKe1LiQ53G for ; Fri, 19 Aug 2016 15:32:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BF7127071 for ; Fri, 19 Aug 2016 15:32:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPT46146; Fri, 19 Aug 2016 22:32:26 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 19 Aug 2016 23:32:25 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 19 Aug 2016 15:32:18 -0700 From: Linda Dunbar To: "spud@ietf.org" , "mirja.kuehlewind@tik.ee.ethz.ch" , Brian Trammell , "ted.ietf@gmail.com" Thread-Topic: Can Malicious users can use PLUS layer to force their traffic through firewalls in the network? Thread-Index: AdH6aYroTRCdiFrBT+mI/47rWkKsjQ== Date: Fri, 19 Aug 2016 22:32:18 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F164DA@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.154] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F164DAdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57B788FA.00DE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d8a28bf1eeabd6a26239b4e1292bd175 Archived-At: Subject: [Spud] Can Malicious users can use PLUS layer to force their traffic through firewalls in the network? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 22:32:32 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F164DAdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, etc, I have a couple of questions for PLUS: * PLUS allowing end points to expose more information to middle boxe= s. But how do end points know what kind of middle boxes their traffic will = traverse through? * Malicious users can use this PLUS layer to force their traffic th= rough firewalls in the network. How can middle boxes trust the bits encoded= in the PLUS layer? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F164DAdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian, etc,

 

I have a couple of questions for PLUS:

 

·        PLUS allowing end points to expose more info= rmation to middle boxes. But how do end points know what kind of middle box= es their traffic will traverse through?

 

·        Malicious users  can use this PLUS laye= r to force their traffic through firewalls in the network. How can middle b= oxes trust the bits encoded in the PLUS layer?

 

Thanks, Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F164DAdfweml501mbb_--