From fred@cisco.com Thu Jan 2 10:07:10 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17F11A1F65 for ; Thu, 2 Jan 2014 10:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.14 X-Spam-Level: X-Spam-Status: No, score=-115.14 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCNTV9bAfgwC for ; Thu, 2 Jan 2014 10:07:08 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C71A1F02 for ; Thu, 2 Jan 2014 10:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4891; q=dns/txt; s=iport; t=1388686021; x=1389895621; h=from:to:cc:subject:date:message-id:mime-version; bh=CJrTOOuuI+TMdsyHVFvPLcjfPNi7wkaOibHLneKH07g=; b=YCPe38VdX43tGyaknF7j54Qx2c9SVcMad9vMDETylh5nCTQhAze6qEGB /mpK5KuSQrVjsTIkIHtQ6ub0GdeCFzVJNGWjYm/vwdF7qOociI1iaqTi+ gdVEGyXlnrIHb6z0K0uSPHWQBJYAHHAxHBBMgDQz/sr2jtUqfYGTNTQj9 A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAOGpxVKtJXG8/2dsb2JhbABOCoMLOFW4b4ELFnSCLB0qJA4SATkCRScEDhOHdqxvliAXjjsGCgIBTxYYgnyBEwSQM4ExhjOSFIMtgio X-IronPort-AV: E=Sophos;i="4.95,592,1384300800"; d="asc'?scan'208";a="295006900" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jan 2014 18:07:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s02I70ld023002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jan 2014 18:07:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 2 Jan 2014 12:07:00 -0600 From: "Fred Baker (fred)" To: "info@EESST.org" Thread-Topic: draft-davin-eesst Thread-Index: AQHPB+VudpXpFqniN0Sq7fewQXFvTg== Date: Thu, 2 Jan 2014 18:06:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_7B5254A3-6252-42E2-BA62-7B087AD210AE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass Subject: [perpass] draft-davin-eesst X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 18:07:10 -0000 --Apple-Mail=_7B5254A3-6252-42E2-BA62-7B087AD210AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I scanned quickly through draft-davin-eesst with a few basic puzzlements = in mind. The mechanism makes sense. I have two questions on = security/privacy considerations, one on the protocol involved, and one = on scope. I am copying perpass, because I suspect that my considerations = have bearing on the broader topic of pervasive monitoring of traffic. If I understand correctly, the EESST specification is intended to = facilitate the secure transmission of data private to one party but = originated by a second party to a set of third parties with legitimate = and authorized interest. The specific case is a secondary school = transcript, being sent by a student, originated by an institution, and = received by a set of other institutions; the data is, of course, private = to the the student, who is presumably applying to the receiving = institutions.=20 My question on scope is: "why so narrow a description?" I can think of = other cases in which data private to one party and originated by a = second party is sent to a set of third parties with legitimate and = authorized interest; medical records come quickly to mind. I could = imagine the basic mechanism being described in generic terms and the = transmission of transcripts described separately as a use case for the = mechanism.=20 My protocol question is "why spend so much time on the structure of the = email message?" If the student has the files, they could be communicated = via http upload, IM, USB key, twitter, or any other application. Even if = email is used, the student is likely to simply attach them to an email = message using his or her favorite email tool without regard to the = specifics of the EESST specification. In any case, the transmission will = need context: unless s/he is uploading them to an application web page = at the receiving institution (which is its own context), the student = will likely include either text or another file as a cover letter. Why = not simply say that the files are exchanged without reference to the = protocol in question? But now to what I consider the heart of the matter.=20 The specification calls for a pair of files (XML and PDF) to be signed = by the originating institution, for purposes of authenticity and = integrity checking, and for the MIME object containing it to be = optionally encrypted, so that it cannot be inspected in an MTA. I = understand that encryption being optional, in that few mail tools make = S/MIME or OpenPGP easy enough for a non-expert to use - even in the = IETF, few have PGP keys, and since our lists don't have keys, even this = email is being sent in the clear. So the call for encryption is largely = vacuous, and the very real possibility remains for inspection of data = while at rest in an MTA or captured in flight on a traffic analyzer. Due = to our failure to provide simple key creation and management tools, this = private and important data is accessible to a casual eye in flight. However, in the use case, the transcript is likely to survive as a = record for years, and perhaps forever, but only be in transit for a = period of seconds to minutes in the usual case. The specification leaves = the data at rest unencrypted, available for casual inspection. One could = argue that this is not an issue with a transcript; nobody is going to = lose their job over having gotten a bad grade decades earlier. In the = medical record use case, it can have dramatic effects. I think the = primary threat is unauthorized or inappropriate access/use when the data = is at rest.=20 Why not have the originating institution encrypt the data using its = private key and make that key available to other institutions? In this = or another specification, you could give them a naming guideline that = would identify the file as pertaining to an individual and an = institution, and therefore a specified public key. This is not perfect = security, of course; an unauthorized party that obtained the public key = of the originating institution could read the file. But it at least = forces them to do so, as opposed to leaving the data open to hack or = casual access. --Apple-Mail=_7B5254A3-6252-42E2-BA62-7B087AD210AE 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 - http://gpgtools.org iD8DBQFSxarBbjEdbHIsm0MRAjlmAJ9eSCezaEf4sdaxSpblBnTm4Rjw6wCg2Kzn k7AVovR3oilb35WaEX6BOg0= =W8w9 -----END PGP SIGNATURE----- --Apple-Mail=_7B5254A3-6252-42E2-BA62-7B087AD210AE-- From fred@cisco.com Fri Jan 3 16:02:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735E21ACCED for ; Fri, 3 Jan 2014 16:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.339 X-Spam-Level: X-Spam-Status: No, score=-114.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA1bmo8QiMfL for ; Fri, 3 Jan 2014 16:02:06 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF81ACC91 for ; Fri, 3 Jan 2014 16:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11209; q=dns/txt; s=iport; t=1388793719; x=1390003319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UQSUeyck+O63Mc9Y4hFcUAIaeLIB9ZaGF0klPqc4Ixw=; b=KwZXZSiRCXUQw+8gZmaX7b7DS1keqeVKoFWQUbwvyh2XVgXaKhhBprvz K30EbZGzns4kSoybs51h0eRqOA0OWOB/xjNcjfogoaCnoPndKwV5+TMWe DxyRxTSXpWCWMb1KcT9f/2VF8Zrv1ghobnnQloceVD7gcbv3YVr7azWq4 Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABBPx1KtJXHA/2dsb2JhbABOCoMLOFWoE5EUgQwWdIIlAQEBAwEdFBYgBAEFBQMFCwIBCBgZAhMyJQIECgQDAg4GBYdjCKtvgWyVYheOLAYKAgFPBwkGGIJ9gRMBA5AzgTGGM4EwkGSDLUCBag X-IronPort-AV: E=Sophos;i="4.95,600,1384300800"; d="asc'?scan'208";a="295246158" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jan 2014 00:01:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0401wMu012740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jan 2014 00:01:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 3 Jan 2014 18:01:57 -0600 From: "Fred Baker (fred)" To: "" Thread-Topic: draft-davin-eesst Thread-Index: AQHPB+VudpXpFqniN0Sq7fewQXFvTppz/yOAgAAWAoA= Date: Sat, 4 Jan 2014 00:01:56 +0000 Message-ID: <686BDF23-A166-42DB-BB70-FD4E5C288E39@cisco.com> References: <1388788989.1552.30.camel@chuck> In-Reply-To: <1388788989.1552.30.camel@chuck> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_B8A62A64-2E4C-481B-93EC-591C24533A06"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] draft-davin-eesst X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 00:02:09 -0000 --Apple-Mail=_B8A62A64-2E4C-481B-93EC-591C24533A06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 3, 2014, at 2:43 PM, Chuck Davin wrote: > I may not have completely understood your second security concern. It > seems to relate to the vulnerability of student information either at > rest or in transit across MTAs. To me, these seem like different > cases. >=20 > The information is "at rest" only when held by the originator, the > student, or the recipient, but they are all authorized users. =20 In that, I will disagree, or will ask you to accept two variants of "at = rest". I'm using the term in the sense of having the entire transmission = in one place in the application layer and a choice of what to do with = it, as opposed to looking at it at the network layer or lower and simply = passing the trash.=20 Ask yourself, for example, what an Ironport or Barracuda Spam Barrier = is; to my mind, it is an MTA that analyzes an email message and applies = a policy to it. In some defined set of cases, it might observe that the = message comes from a common business partner and is therefore likely to = be OK, and passes it like any other MTA might. In another set of cases, = it might summarily discard the message, and in a third set of cases, it = might simply hold it, or it might redirect it to somewhere else for = further processing. In determining whether an email is viral, it might = ask whether users receiving the message are marking it junk, and might = as a result search for it in a held database and "junk" it. And it might = look through attachments for recognizable patterns of malware. If a MIME object is encrypted, it is harder to poke through for malware = structures. Other analyses, such as looking for common names of objects = carried in MIME, can still be done. So for most of the purposes relevant = to pervasive monitoring, at least to my small mind, it is at rest. But we agree that in the two MUAs, it is at rest. I will argue that it = will spend most of its life at rest in the databases of at least some of = the institutions. My concern there is with the integrity and privacy of = the data itself. Walking off into another world, consider automated billing such as is = intended to be done in the smart grid. These are records that will have = to be reproduced and proven valid in the event of a billing dispute, and = therefore must be retained. However, not everyone is authorized to have = access to the data in the same form. The billing agent needs access that = will support billing, which may include how many KWH were transferred at = each of several billing rates. The electrical utility itself needs = aggregate information for planning purposes. The homeowner, at least in = California, is supposed to be able to access their own data in real time = (for some definition of that term) in a manner that allows them to = evaluate changes they make to their homes. And a their that has access = to the billing or real-time data might use it as a way to remotely case = a break-in target. Data at rest becomes a means not only for legitimate = and authorized behavior, but inappropriate and unauthorized behavior. Data at rest in the medical world is notoriously used to investigate = medical conditions that an insurer would like to not have to cover. Data = at rest is sought by others for various purposes. Target recently had a = problem with its POS systems that captured credentials for some 40M = credit card accounts.=20 So yes, while the risks are probably not as high with high school = transcripts, I think the same fundamental issue is in play. I'm = concerned about the transcript five years after the institution has = received it. I'd like a hacker to not be able to gain access to its = contents. > Your closing paragraph seems to sketch an alternative approach to the > MTA transit problem (??) or other "casual access." I took its gist to > be that, absent student encryption, the originator could control > access to the student data using the originator's encryption keys. In > common with other centralized approaches, it is, as you say, "not > perfect security." In particular, the student is not really in = control > of her own data. Well, I would submit that the student is still not in control of their = own data. Once they give it to someone else, that someone can give it to = an additional party without the student's knowledge. And the level of = limits that can be placed on that are pretty low; the student could = encrypt it in the public key of the institution s/he sends it to, = meaning that only that person or institution can open it, but once = decrypted, it is in the clear and can be saved and transferred. So while = I support the goal, I think it has limits. > I undertook this work less to innovate and more to address a real > world problem. Although, to this community, the posted draft should > seem pedestrian, to a broader audience, it clearly demonstrates that > large centralized databases are not the only technical option for > addressing school transcript distribution. The centralized approach > permits students little real privacy and no real control over > distribution of their own personal information. In contrast, the > common format and distributed approach in the posting assign protocol > roles to the various players that are appropriate to their proper > rights and responsibilities. Review, support, and implementation > within this community would counter the claim that a more > paternalistic, centralized approach is the only one that is > technically feasible. Ah, yes, I have enrolled a kid in college as well, and has to specify = the set of schools that the student's transcripts would be sent to. I = get this. That said, what I suggested (that each institution have a = public key and distribute the keys to each other in some way) is only = centralized if you consider hkp://wwwkeys.pgp.net and its friends a = centralized server. > Thanks for your very thoughtful review and comments. >=20 > Best, > Chuck >=20 > On Thu, 2014-01-02 at 18:06 +0000, Fred Baker (fred) wrote: >> I scanned quickly through draft-davin-eesst with a few basic = puzzlements in mind. The mechanism makes sense. I have two questions on = security/privacy considerations, one on the protocol involved, and one = on scope. I am copying perpass, because I suspect that my considerations = have bearing on the broader topic of pervasive monitoring of traffic. >>=20 >> If I understand correctly, the EESST specification is intended to = facilitate the secure transmission of data private to one party but = originated by a second party to a set of third parties with legitimate = and authorized interest. The specific case is a secondary school = transcript, being sent by a student, originated by an institution, and = received by a set of other institutions; the data is, of course, private = to the the student, who is presumably applying to the receiving = institutions.=20 >>=20 >> My question on scope is: "why so narrow a description?" I can think = of other cases in which data private to one party and originated by a = second party is sent to a set of third parties with legitimate and = authorized interest; medical records come quickly to mind. I could = imagine the basic mechanism being described in generic terms and the = transmission of transcripts described separately as a use case for the = mechanism.=20 >>=20 >> My protocol question is "why spend so much time on the structure of = the email message?" If the student has the files, they could be = communicated via http upload, IM, USB key, twitter, or any other = application. Even if email is used, the student is likely to simply = attach them to an email message using his or her favorite email tool = without regard to the specifics of the EESST specification. In any case, = the transmission will need context: unless s/he is uploading them to an = application web page at the receiving institution (which is its own = context), the student will likely include either text or another file as = a cover letter. Why not simply say that the files are exchanged without = reference to the protocol in question? >>=20 >> But now to what I consider the heart of the matter.=20 >>=20 >> The specification calls for a pair of files (XML and PDF) to be = signed by the originating institution, for purposes of authenticity and = integrity checking, and for the MIME object containing it to be = optionally encrypted, so that it cannot be inspected in an MTA. I = understand that encryption being optional, in that few mail tools make = S/MIME or OpenPGP easy enough for a non-expert to use - even in the = IETF, few have PGP keys, and since our lists don't have keys, even this = email is being sent in the clear. So the call for encryption is largely = vacuous, and the very real possibility remains for inspection of data = while at rest in an MTA or captured in flight on a traffic analyzer. Due = to our failure to provide simple key creation and management tools, this = private and important data is accessible to a casual eye in flight. >>=20 >> However, in the use case, the transcript is likely to survive as a = record for years, and perhaps forever, but only be in transit for a = period of seconds to minutes in the usual case. The specification leaves = the data at rest unencrypted, available for casual inspection. One could = argue that this is not an issue with a transcript; nobody is going to = lose their job over having gotten a bad grade decades earlier. In the = medical record use case, it can have dramatic effects. I think the = primary threat is unauthorized or inappropriate access/use when the data = is at rest.=20 >>=20 >> Why not have the originating institution encrypt the data using its = private key and make that key available to other institutions? In this = or another specification, you could give them a naming guideline that = would identify the file as pertaining to an individual and an = institution, and therefore a specified public key. This is not perfect = security, of course; an unauthorized party that obtained the public key = of the originating institution could read the file. But it at least = forces them to do so, as opposed to leaving the data open to hack or = casual access. >=20 >=20 =95 Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_B8A62A64-2E4C-481B-93EC-591C24533A06 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 - http://gpgtools.org iD8DBQFSx09zbjEdbHIsm0MRAsm1AKCQkI2s1v4hJpiPOJ4vEJv+75S8lQCg5j9I UWW0StIPgzg+6CfMmHJINYQ= =pmrQ -----END PGP SIGNATURE----- --Apple-Mail=_B8A62A64-2E4C-481B-93EC-591C24533A06-- From chuck@eesst.org Fri Jan 3 14:45:11 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584E51AE005 for ; Fri, 3 Jan 2014 14:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jNXX7nHrlLP for ; Fri, 3 Jan 2014 14:45:08 -0800 (PST) Received: from obermeyer.clearbearing.net (smtp.clearbearing.net [IPv6:2607:fc58:1004::9]) by ietfa.amsl.com (Postfix) with ESMTP id BCE1F1ADFFF for ; Fri, 3 Jan 2014 14:45:08 -0800 (PST) Received: from mail.nuleaf.com (unknown [32.165.233.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by obermeyer.clearbearing.net (Postfix) with ESMTPSA id E44E4F162F; Fri, 3 Jan 2014 17:43:58 -0500 (EST) Received: from [192.168.100.139] (IP139.NULEAF.COM [192.168.100.139]) by mail.nuleaf.com (Postfix) with ESMTP id 832B5412F0; Fri, 3 Jan 2014 17:43:10 -0500 (EST) From: Chuck Davin To: "Fred Baker (fred)" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Rarely Date: Fri, 03 Jan 2014 17:43:09 -0500 Message-ID: <1388788989.1552.30.camel@chuck> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-ClearBearing-MailScanner-Information: Please contact ClearBearing (http://www.clearbearing.com) for more information on our anti-spam/anti-virus efforts. X-ClearBearing-MailScanner-ID: E44E4F162F.ABAEF X-ClearBearing-MailScanner: Found to be clean X-ClearBearing-MailScanner-IP-Protocol: IPv4 X-ClearBearing-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-6.001, required 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_50 1.00, TLS_AUTH_NOSPAM -5.00) X-ClearBearing-MailScanner-From: chuck@eesst.org X-ClearBearing-MailScanner-Watermark: 1389393896.70561@gAwAjzb2uYlSrIuuT3uy1w X-Mailman-Approved-At: Fri, 03 Jan 2014 16:04:20 -0800 Cc: perpass Subject: Re: [perpass] draft-davin-eesst X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chuck@eesst.org List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 22:45:11 -0000 Hi Fred, Nice to hear from a once familiar face. Your questions are very much to the point. Your scope question is "why so narrow a description?" A brief answer is that the specified format targets a particular application. At some point, the generality of onion-layered infrastructure must give way to the particularity of doing some actual real-world task. In this case, the OpenPGP standard is applied to provide exactly the services for which it is designed. While OpenPGP services could certainly also be applied in other application domains (e.g., your example of electronic health records (EHR)), the two applications are really quite different in terms of audience, requirements, etc. My guess is that the superficial commonality between them is not enough that distilling it would greatly simplify the solution to either problem. Your protocol question is "why spend so much time on the structure of the email message?" The answer is that we want interoperable applications. If a student is applying for a job at a small commercial enterprise, then his transcript will likely be received as a normal email message, validated using a normal email reader, and the PDF component will be reviewed by a human. However, if our student has applied to Big University, then the defined format supports automated validation of the received transcript and automated extraction of the transcript content (XML) into an Admissions Department database. Automation is important, because the Internet, common application, and other factors have dramatically changed college admissions, so that even smaller institutions can receive surprisingly large numbers of applications. Naturally, we want transcript recipients to be as tolerant as possible of how students convey their transcript information, and the spec is perhaps not so restrictive as it sounds, but application implementors also need guidance about how hard they should try to unpack a received message before kicking it to a human. Your first security concern relates to the optional use of encryption by students in sending their transcripts to recipients. For me, you have certainly struck at the "heart of the matter." I confess that, in earlier versions, the encryption was mandatory. Arguments for relaxing the encryption requirement are, first, international students may not always have easy access to encryption, and, second, that encryption may sometimes be beyond the technical reach of Mom-N-Pop enterprises. But either of these limitations could be overcome by, for example, burning a transcript onto a CD-ROM disk and sending it via postal mail. Thus, I vacillate frequently on the question of mandatory encryption. However, I do not fully share your concern about students who decline to encrypt owing to the poor usability of email encryption tools. One can imagine a trivial, very application-specific script that students could use to send their transcripts to chosen recipients. I may not have completely understood your second security concern. It seems to relate to the vulnerability of student information either at rest or in transit across MTAs. To me, these seem like different cases. The information is "at rest" only when held by the originator, the student, or the recipient, but they are all authorized users. What remains are attacks upon their hosts. Thus, the "at rest" question seems close to the question of whether or not one should encrypt one's files when not logged in, a question with an easy answer (yes!) but a bit beyond the scope of the draft. Of course, the "at rest" threat is yet another reason to require encryption when the student transmits his transcript, so perhaps the scale should be tilting much more that way. The "MTA transit" problem also argues for mandatory encryption of student transmissions. But there are alternate approaches as well. The Internet is supposed to be end-to-end. Thus, the MTA transit risk could be mitigated by enabling end-to-end email connections between student and recipient, who could operate a specialized server that welcomes arbitrary SMTP connections. Insofar as the balkanization of our email infrastructure had been largely a response to spam, individual sites could, if they wish, choose to prefer built-in end-to-end security over the convenience of reduced spam. Your closing paragraph seems to sketch an alternative approach to the MTA transit problem (??) or other "casual access." I took its gist to be that, absent student encryption, the originator could control access to the student data using the originator's encryption keys. In common with other centralized approaches, it is, as you say, "not perfect security." In particular, the student is not really in control of her own data. I undertook this work less to innovate and more to address a real world problem. Although, to this community, the posted draft should seem pedestrian, to a broader audience, it clearly demonstrates that large centralized databases are not the only technical option for addressing school transcript distribution. The centralized approach permits students little real privacy and no real control over distribution of their own personal information. In contrast, the common format and distributed approach in the posting assign protocol roles to the various players that are appropriate to their proper rights and responsibilities. Review, support, and implementation within this community would counter the claim that a more paternalistic, centralized approach is the only one that is technically feasible. Thanks for your very thoughtful review and comments. Best, Chuck On Thu, 2014-01-02 at 18:06 +0000, Fred Baker (fred) wrote: > I scanned quickly through draft-davin-eesst with a few basic puzzlements in mind. The mechanism makes sense. I have two questions on security/privacy considerations, one on the protocol involved, and one on scope. I am copying perpass, because I suspect that my considerations have bearing on the broader topic of pervasive monitoring of traffic. > > If I understand correctly, the EESST specification is intended to facilitate the secure transmission of data private to one party but originated by a second party to a set of third parties with legitimate and authorized interest. The specific case is a secondary school transcript, being sent by a student, originated by an institution, and received by a set of other institutions; the data is, of course, private to the the student, who is presumably applying to the receiving institutions. > > My question on scope is: "why so narrow a description?" I can think of other cases in which data private to one party and originated by a second party is sent to a set of third parties with legitimate and authorized interest; medical records come quickly to mind. I could imagine the basic mechanism being described in generic terms and the transmission of transcripts described separately as a use case for the mechanism. > > My protocol question is "why spend so much time on the structure of the email message?" If the student has the files, they could be communicated via http upload, IM, USB key, twitter, or any other application. Even if email is used, the student is likely to simply attach them to an email message using his or her favorite email tool without regard to the specifics of the EESST specification. In any case, the transmission will need context: unless s/he is uploading them to an application web page at the receiving institution (which is its own context), the student will likely include either text or another file as a cover letter. Why not simply say that the files are exchanged without reference to the protocol in question? > > But now to what I consider the heart of the matter. > > The specification calls for a pair of files (XML and PDF) to be signed by the originating institution, for purposes of authenticity and integrity checking, and for the MIME object containing it to be optionally encrypted, so that it cannot be inspected in an MTA. I understand that encryption being optional, in that few mail tools make S/MIME or OpenPGP easy enough for a non-expert to use - even in the IETF, few have PGP keys, and since our lists don't have keys, even this email is being sent in the clear. So the call for encryption is largely vacuous, and the very real possibility remains for inspection of data while at rest in an MTA or captured in flight on a traffic analyzer. Due to our failure to provide simple key creation and management tools, this private and important data is accessible to a casual eye in flight. > > However, in the use case, the transcript is likely to survive as a record for years, and perhaps forever, but only be in transit for a period of seconds to minutes in the usual case. The specification leaves the data at rest unencrypted, available for casual inspection. One could argue that this is not an issue with a transcript; nobody is going to lose their job over having gotten a bad grade decades earlier. In the medical record use case, it can have dramatic effects. I think the primary threat is unauthorized or inappropriate access/use when the data is at rest. > > Why not have the originating institution encrypt the data using its private key and make that key available to other institutions? In this or another specification, you could give them a naming guideline that would identify the file as pertaining to an individual and an institution, and therefore a specified public key. This is not perfect security, of course; an unauthorized party that obtained the public key of the originating institution could read the file. But it at least forces them to do so, as opposed to leaving the data open to hack or casual access. From benl@google.com Mon Jan 6 09:02:29 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAB1AE111 for ; Mon, 6 Jan 2014 09:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsD0SiKY4NKp for ; Mon, 6 Jan 2014 09:02:23 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2268B1AE100 for ; Mon, 6 Jan 2014 09:02:23 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id le5so1295621vcb.36 for ; Mon, 06 Jan 2014 09:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BbPqWKvwWplYG8M5vOLkqxUwNweYjpIZsNhKr1FK0Uw=; b=b1j1TJGHf5MJxCuqnX9I//XoZHtHk9+z/fLh+lljOsCibNNGATxN8JUgpWpv8fqIFI 9haOZ1a/7TxK25u69IbMebH9ZNutB01idEqKGOHyUsQuP1PTv1BDA0gfNOpfYEI9a5wk g/shs2ragv5qG7xff/9rVrzkGLxVeBb9shmfrmizG3g2Wr8gKo233TH2wwhF4OwhN0xJ Y6KSvE+5HM+N5ew91Fglb+z1N8VjQOp2BmxkoB7OY97G56Os1c2Jjm1YlknDcS8K4/R5 UhAUAP/6SR14b24G2J9B+T/2fF8QIfxV3iJzHISl0pER6Q6HzrEx7lHK+g1LWMpwxwwG DrcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BbPqWKvwWplYG8M5vOLkqxUwNweYjpIZsNhKr1FK0Uw=; b=NvMF8z8NLj4m5LZT5SUuLNeMO0BoGnY1/D/1lSzlwdZOfzWszzAbRNv42qJqTzpqNg af7kh/UFJhxmECaMXC+GkWwYy7BN9PHGM9gkvboJf4XiTG5LL1Wu6qSh1ks2rqKZDLfD o+tikreuX1DrOcLdpYAAPJNAvZsEEkgSaFMeMXVuAy5Il/bsrgY5IKr4tB4zTCU2gO0Q kFyyl/CP8hYI3aCcma9j4MKghIWqTWqSa/uWm1SzWrs0AnCg7VL0nHeLN8ntjkZwGk0Y 0A4wZxb/gKZHMJwEaiiYXmSUjpQKNBuWeT9yqaS+nYPqdQ93wpUomDz7TtlOqhB+yWgY vZWw== X-Gm-Message-State: ALoCoQnOGZ09WWNlOoTDf49UXQywSvxiFFN9cDi2lISKibGf8pCKq67VlZ2NJkupF9xSeF0cnBCUCV+CBlSNz32ih60g5Gi/yEFuALRIKjHibI6vffzys9wgNPM6y0FnKRTH7ojk2B+JKqnYiuKXZZPLKLS/FfVxzX3q2T1oLEW/Sb1mQzbymAm6b25eomFvTH/SHeu474MU MIME-Version: 1.0 X-Received: by 10.52.33.178 with SMTP id s18mr3230491vdi.39.1389027734368; Mon, 06 Jan 2014 09:02:14 -0800 (PST) Received: by 10.52.169.202 with HTTP; Mon, 6 Jan 2014 09:02:14 -0800 (PST) In-Reply-To: <52C19300.3050201@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> <52C19300.3050201@bbn.com> Date: Mon, 6 Jan 2014 17:02:14 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:02:29 -0000 On 30 December 2013 15:36, Stephen Kent wrote: > Ben, > >> How's this? >> >> [1] A cryptographically verifiable log is an append-only log of hashes >> of more-or-less anything that can prove its own correctness >> cryptographically. >> >> For example, from RFC 6962: =E2=80=9CThe append-only property of each lo= g is >> technically achieved using Merkle Trees, which can be used to show >> that any particular version of the log is a superset of any particular >> previous version. Likewise, Merkle Trees avoid the need to blindly >> trust logs: if a log attempts to show different things to different >> people, this can be efficiently detected by comparing tree roots and >> consistency proofs. Similarly, other misbehaviours of any log (e.g., >> issuing signed timestamps for certificates they then don't log) can be >> efficiently detected and proved to the world at large.=E2=80=9D >> >> See RFC 6962, >> http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf >> and http://www.links.org/files/RevocationTransparency.pdf for >> background. >> > Sorry to be so late in responding; holidays ... Likewise. > The text describing how 6962 uses Merkle trees is good. I think the > phrase "prove its own correctness" is way too broad. The example > you cite shows how to demonstrate internal consistency for a log, > and to enable third parties to verify certain lob properties. That > is much narrower than what the term "correctness" implies. How about, instead of "can prove its own correctness cryptographically", we say "allows efficient verification of behaviour"? From wilton@isoc.org Mon Jan 6 09:20:28 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0A1AE115 for ; Mon, 6 Jan 2014 09:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW8IbP1cdehE for ; Mon, 6 Jan 2014 09:20:26 -0800 (PST) Received: from smtp110.iad3a.emailsrvr.com (smtp110.iad3a.emailsrvr.com [173.203.187.110]) by ietfa.amsl.com (Postfix) with ESMTP id 17B431AE111 for ; Mon, 6 Jan 2014 09:20:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 95C622B8086; Mon, 6 Jan 2014 12:20:16 -0500 (EST) X-Virus-Scanned: OK Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id C3E8D2B80FF; Mon, 6 Jan 2014 12:20:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_682D8C24-8DA6-4737-B8A9-A27119A111EE" From: Robin Wilton In-Reply-To: Date: Mon, 6 Jan 2014 17:20:53 +0000 Message-Id: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> <52C19300.3050201@bbn.com> To: Ben Laurie X-Mailer: Apple Mail (2.1283) Cc: perpass , Stephen Kent , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:20:28 -0000 --Apple-Mail=_682D8C24-8DA6-4737-B8A9-A27119A111EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all - A further suggestion inline. One motivation for my suggesting a change = is that I am instinctively uneasy when the word "proof" crops up in this = kind of context. I think what we're doing is providing the means to = accrue evidence, on the basis of which someone can make an inference as = to whether correct log behaviour has been recorded.=20 R On 6 Jan 2014, at 17:02, Ben Laurie wrote: > On 30 December 2013 15:36, Stephen Kent wrote: >> Ben, >>=20 >>> How's this? >>>=20 >>> [1] A cryptographically verifiable log is an append-only log of = hashes >>> of more-or-less anything that can prove its own correctness >>> cryptographically. >>>=20 >>> For example, from RFC 6962: =93The append-only property of each log = is >>> technically achieved using Merkle Trees, which can be used to show >>> that any particular version of the log is a superset of any = particular >>> previous version. Likewise, Merkle Trees avoid the need to blindly >>> trust logs: if a log attempts to show different things to different >>> people, this can be efficiently detected by comparing tree roots and >>> consistency proofs. Similarly, other misbehaviours of any log (e.g., >>> issuing signed timestamps for certificates they then don't log) can = be >>> efficiently detected and proved to the world at large.=94 >>>=20 >>> See RFC 6962, >>> http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf >>> and http://www.links.org/files/RevocationTransparency.pdf for >>> background. >>>=20 >> Sorry to be so late in responding; holidays ... >=20 > Likewise. >=20 >> The text describing how 6962 uses Merkle trees is good. I think the >> phrase "prove its own correctness" is way too broad. The example >> you cite shows how to demonstrate internal consistency for a log, >> and to enable third parties to verify certain lob properties. That >> is much narrower than what the term "correctness" implies. >=20 > How about, instead of "can prove its own correctness > cryptographically", we say "allows efficient verification of > behaviour"? "A cryptographically verifiable log is an append-only log of hashes, = structured in such a way as to provide efficiently-accessible, = cryptographically-supported evidence of correct [log] behaviour".=20 That way, you capture the following: - use of hashing/cryptographic mechanisms to maintain the integrity of = the evidence trail - reference to the relevance of structure (Merkle trees) - de-coupling of the evidence (signed records) from what it is that the = evidence is intended to show (correct behaviour) Hope this helps -=20 Robin > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_682D8C24-8DA6-4737-B8A9-A27119A111EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all -

A further suggestion inline. One motivation for = my suggesting a change is that I am instinctively uneasy when the word = "proof" crops up in this kind of context. I think what we're doing is = providing the means to accrue evidence, on the basis of which someone = can make an inference as to whether correct log behaviour has been = recorded. 


On 6 Jan 2014, at 17:02, Ben Laurie wrote:

On 30 = December 2013 15:36, Stephen Kent <kent@bbn.com> wrote:
Ben,

How's this?

[1] A cryptographically = verifiable log is an append-only log of = hashes
of more-or-less anything that can prove its own = correctness
cryptographically.

For example, from RFC 6962: =93The= append-only property of each log = is
technically achieved using Merkle Trees, which can be used = to show
that any particular version of the log is a superset of = any particular
previous version. Likewise, = Merkle Trees avoid the need to = blindly
trust logs: if a log attempts to show different things to = different
people, this can be efficiently = detected by comparing tree roots = and
consistency proofs. Similarly, other misbehaviours of any = log (e.g.,
issuing signed timestamps for = certificates they then don't log) can = be
efficiently detected and proved to the world at = large.=94

See RFC = 6962,
http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
=
and http://www.= links.org/files/RevocationTransparency.pdf = for
background.

Sorry to be so late in responding; holidays = ...

Likewise.

The = text describing how 6962 uses Merkle trees is good. I think = the
phrase "prove its own = correctness" is way too broad. The example
you cite shows how to demonstrate internal consistency for = a log,
and to enable third = parties to verify certain lob properties. = That
is much narrower than = what the term "correctness" implies.

How about, = instead of "can prove its own correctness
cryptographically", we say = "allows efficient verification = of
behaviour"?

"A = cryptographically verifiable log is an append-only log of hashes, = structured in such a way as to provide efficiently-accessible, = cryptographically-supported evidence of correct [log] = behaviour". 

That way, you capture the = following:

- use of hashing/cryptographic = mechanisms to maintain the integrity of the evidence trail
- = reference to the relevance of structure (Merkle trees)
- = de-coupling of the evidence (signed records) from what it is that the = evidence is intended to show (correct = behaviour)

Hope this helps = - 

Robin

_______________________________________________
perp= ass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_682D8C24-8DA6-4737-B8A9-A27119A111EE-- From rlb@ipv.sx Mon Jan 6 18:24:30 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A651AE3C2 for ; Mon, 6 Jan 2014 18:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Ih5puFbU1g for ; Mon, 6 Jan 2014 18:24:28 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 58F431AE260 for ; Mon, 6 Jan 2014 18:24:28 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id o6so3122701oag.39 for ; Mon, 06 Jan 2014 18:24:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=e/I9VPkQHssKSJWoJh5AwZK+tBuAWEngBPA3WndKc1w=; b=X0+47kJtZGMhZPxKZ8p+UznmjEQYVjNj2w2KwnEpDT3/WtjRzYLQm/R2ithvLoCECb PISJnQcTYUctHgPZCXkMwMo1R9PMmOSOSOMXOx0Duz7Noe5/TlZvGeoZxk3h8oq3JP9Z FVPdzvqam5xX4nePp9u88GVa0kp/KlPQqVR4klOtT0+Tkt9CHhwLG+Msb1sJWmdVlgzA Jtfm3xJBSP1kqNL6bjIBgpovffOiqLTPau2pbXnEKmaN6IpbfSWpQvTGa4FeM8H/mOcc 8Fk2Y60UpfFjlY1Oqb695HGzm17wozc42gRxIazU5SVPibqD7yC/jIFJ/rfYp3Hf3QaH Ce6A== X-Gm-Message-State: ALoCoQkxIVSriCBiHaC6nux/OVR2oqjDubDmZU+me1SUMRPjUogmBlErQ7qtWCqPUSo2U9UHBYRb MIME-Version: 1.0 X-Received: by 10.60.123.19 with SMTP id lw19mr19305954oeb.24.1389061458548; Mon, 06 Jan 2014 18:24:18 -0800 (PST) Received: by 10.60.54.65 with HTTP; Mon, 6 Jan 2014 18:24:18 -0800 (PST) In-Reply-To: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 21:24:18 -0500 Message-ID: From: Richard Barnes To: perpass Content-Type: multipart/alternative; boundary=047d7b5d2f88cefeed04ef5812be Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 02:24:31 -0000 --047d7b5d2f88cefeed04ef5812be Content-Type: text/plain; charset=ISO-8859-1 Dear PERPASS, Stephen asked me to take a stab at a problem statement for PERPASS. With some help from Bruce, Cullen, and Ted, the results have just been published as draft-barnes-pervasive-problem-00. In general, this draft tries to outline at a technical level what we mean by pervasive attack, and what the high level mitigations are. Comments welcome! Thanks, --Richard ---------- Forwarded message ---------- From: Date: Mon, Jan 6, 2014 at 9:17 PM Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt To: Cullen Jennings , Ted Hardie , Bruce Schneier , Richard Barnes A new version of I-D, draft-barnes-pervasive-problem-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-pervasive-problem Revision: 00 Title: Pervasive Attack: A Threat Model and Problem Statement Document date: 2014-01-06 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt Status: https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ Htmlized: http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 Abstract: Documents published in 2013 have revealed several classes of "pervasive" attack on Internet communications. In this document, we review the main attacks that have been published, and develop a threat model that describes these pervasive attacks. Based on this threat model, we discuss the techniques that can be employed in Internet protocol design to increase the protocols robustness to pervasive attacks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b5d2f88cefeed04ef5812be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear PERPASS,

Stephen asked me to take = a stab at a problem statement for PERPASS. =A0With some help from Bruce, Cu= llen, and Ted, the results have just been published as draft-barnes-pervasi= ve-problem-00.

In general, this draft tries to outline at a technical = level what we mean by pervasive attack, and what the high level mitigations= are. =A0

Comments welcome!

Thanks,
--Richard
=A0


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for = draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Bruce Schneier &= lt;schneier@schneier.com>, = Richard Barnes <rlb@ipv.sx>



A new version of I-D, draft-barnes-pervasive-problem-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-barnes-pervasive-problem
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Pervasive Attack: A Threat Model and Problem Stat= ement
Document date: =A02014-01-06
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A023
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/internet-drafts/draft-barnes-pervasive-problem-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-barnes-pervasive-problem/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-barn= es-pervasive-problem-00


Abstract:
=A0 =A0Documents published in 2013 have revealed several classes of
=A0 =A0"pervasive" attack on Internet communications. =A0In this = document, we
=A0 =A0review the main attacks that have been published, and develop a
=A0 =A0threat model that describes these pervasive attacks. =A0Based on thi= s
=A0 =A0threat model, we discuss the techniques that can be employed in
=A0 =A0Internet protocol design to increase the protocols robustness to
=A0 =A0pervasive attacks.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b5d2f88cefeed04ef5812be-- From paul@marvell.com Mon Jan 6 18:49:54 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952E71AE3D3 for ; Mon, 6 Jan 2014 18:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAebXyLpezRZ for ; Mon, 6 Jan 2014 18:49:52 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB5C1AE3D2 for ; Mon, 6 Jan 2014 18:49:51 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s072nc7s012850; Mon, 6 Jan 2014 18:49:43 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1h887705rm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 06 Jan 2014 18:49:43 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Mon, 6 Jan 2014 18:49:42 -0800 From: Paul Lambert To: Richard Barnes , perpass Date: Mon, 6 Jan 2014 18:49:41 -0800 Thread-Topic: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt Thread-Index: Ac8LT5iC8oHhpOzzSG6cmYcNTnu5AwAAmdOA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4SCVEXCH2marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-07_01:2014-01-07,2014-01-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401060214 Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 02:49:54 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Comments welcome! Nice work! Minor comment - don't see any text on L2 wireless tracking. All of our wir= eless devices effectively beacon our location and identity (e.g 802.11 MAC = addresses and probing). While not strictly a IETF domain of work (L2), the = solutions to this class of problems do require changes in IETF protocols. Paul From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, January 06, 2014 6:24 PM To: perpass Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive= -problem-00.txt Dear PERPASS, Stephen asked me to take a stab at a problem statement for PERPASS. With s= ome help from Bruce, Cullen, and Ted, the results have just been published = as draft-barnes-pervasive-problem-00. In general, this draft tries to outline at a technical level what we mean b= y pervasive attack, and what the high level mitigations are. Comments welcome! Thanks, --Richard ---------- Forwarded message ---------- From: > Date: Mon, Jan 6, 2014 at 9:17 PM Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt To: Cullen Jennings >, Ted Hardie= >, Bruce Schneier >, Richard Barnes > A new version of I-D, draft-barnes-pervasive-problem-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-pervasive-problem Revision: 00 Title: Pervasive Attack: A Threat Model and Problem Statement Document date: 2014-01-06 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-barnes-pervasive-= problem-00.txt Status: https://datatracker.ietf.org/doc/draft-barnes-pervasive-pro= blem/ Htmlized: http://tools.ietf.org/html/draft-barnes-pervasive-problem-0= 0 Abstract: Documents published in 2013 have revealed several classes of "pervasive" attack on Internet communications. In this document, we review the main attacks that have been published, and develop a threat model that describes these pervasive attacks. Based on this threat model, we discuss the techniques that can be employed in Internet protocol design to increase the protocols robustness to pervasive attacks. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4SCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Comments welcome!

 

Nice work!

&= nbsp;

Minor comment – don’t see a= ny text on L2 wireless tracking.  All of our wireless devices effectiv= ely beacon our location and identity (e.g 802.11 MAC addresses and probing)= . While not strictly a IETF domain of work (L2), the solutions to this clas= s of problems do require changes in IETF protocols.

 

Paul

<= p class=3DMsoNormal> 

 

Fr= om: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richar= d Barnes
Sent: Monday, January 06, 2014 6:24 PM
To: per= pass
Subject: [perpass] Fwd: New Version Notification for draft-b= arnes-pervasive-problem-00.txt

 

Dear PERPASS,=

 

Stephen asked me to take a stab at a problem statement for PE= RPASS.  With some help from Bruce, Cullen, and Ted, the results have j= ust been published as draft-barnes-pervasive-problem-00.

 

In general, this draft tries to outline at a technical level what we = mean by pervasive attack, and what the high level mitigations are.  

 

Comments welcome!=

 

Thanks,

--Richard

 

 

-= --------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan 6, = 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-perva= sive-problem-00.txt
To: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Bruce Schneier <schneier@schneier.com>, Richard Barnes <= rlb@ipv.sx>



A new versi= on of I-D, draft-barnes-pervasive-problem-00.txt
has been successfully s= ubmitted by Richard Barnes and posted to the
IETF repository.

Nam= e:           draft-barnes-pervasive-problem
Rev= ision:       00
Title:          = Pervasive Attack: A Threat Model and Problem Statement
Document date: &n= bsp;2014-01-06
Group:          Individual Submi= ssion
Pages:          23
URL:     =        http://www.ietf.org= /internet-drafts/draft-barnes-pervasive-problem-00.txt
Status:  = ;       https://datatracker.ietf.org/doc= /draft-barnes-pervasive-problem/
Htmlized:       http://tools.ietf.org/html/draft-barnes-pervasive-problem-00


Abstract:
   Documents published in 2013 have rev= ealed several classes of
   "pervasive" attack on In= ternet communications.  In this document, we
   review th= e main attacks that have been published, and develop a
   thre= at model that describes these pervasive attacks.  Based on this
&nb= sp;  threat model, we discuss the techniques that can be employed in   Internet protocol design to increase the protocols robustnes= s to
   pervasive attacks.




Please note that= it may take a couple of minutes from the time of submission
until the h= tmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 

= --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4SCVEXCH2marve_-- From rlb@ipv.sx Mon Jan 6 19:01:14 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0461ADF5A for ; Mon, 6 Jan 2014 19:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ikoj-XuVO-J for ; Mon, 6 Jan 2014 19:01:12 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 36E161ADF35 for ; Mon, 6 Jan 2014 19:01:12 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so20109246oah.29 for ; Mon, 06 Jan 2014 19:01:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SiPfp+ZAAoCBcFfDLThWIYiC6pBxH/A9gBhH9Q4gf90=; b=hWtNeJtQUIOSIIYsIkLupCWL4J5HuWwGSwDMlKfOI32oj3NHITdjFrnE1sqCVtH2K4 QiPX0nMwKNaywC/UQd8gi0B3drHkeVsNplG+sY9zngQPLyNf9yL2pEjpo/mvs9eO+wP0 X3qFNnS9Ajgb8yqb2X4g58IiFSKuSmQlWzgZii94b58wGK9Ca9F4IiGuPhn99DUhwsK5 RmazSVUlQ6Z5naOKcYjrr86xh9dsGd8Y0mLYc8szCBPanShdo7vQV1Nc6sAP5TxJmGIx UB3rM5tZUMK6E11Oe/VtTRfWyr3QzejBBkhA1L//Q4SYGiwO82q71XsmXK/W3uIuqM1b LPvA== X-Gm-Message-State: ALoCoQmuAy2l6O4W3+z/5G9gBjRXa3/EKzuQrNSesJ4rChsEGA4FkJzhemGgSc/U356I3rUhfk0S MIME-Version: 1.0 X-Received: by 10.60.63.102 with SMTP id f6mr37758oes.76.1389063663281; Mon, 06 Jan 2014 19:01:03 -0800 (PST) Received: by 10.60.54.65 with HTTP; Mon, 6 Jan 2014 19:01:03 -0800 (PST) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> Date: Mon, 6 Jan 2014 22:01:03 -0500 Message-ID: From: Richard Barnes To: Paul Lambert Content-Type: multipart/alternative; boundary=001a11c2553239317504ef5896cb Cc: perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 03:01:14 -0000 --001a11c2553239317504ef5896cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jan 6, 2014 at 9:49 PM, Paul Lambert wrote: > > Comments welcome! > > > > Nice work! > > Thanks! Minor comment =96 don=92t see any text on L2 wireless tracking. All of our > wireless devices effectively beacon our location and identity (e.g 802.11 > MAC addresses and probing). While not strictly a IETF domain of work (L2)= , > the solutions to this class of problems do require changes in IETF > protocols. > I also wonder to what degree this is a "pervasive attack" issue. If the attack involves being physically close to the victim, it's hard to see how the attacker would achieve a pervasive scale. What sorts of changes to IETF protocols are you imagining? --Richard > > > Paul > > > > > > *From:* perpass [mailto:perpass-bounces@ietf.org] *On Behalf Of *Richard > Barnes > *Sent:* Monday, January 06, 2014 6:24 PM > *To:* perpass > *Subject:* [perpass] Fwd: New Version Notification for > draft-barnes-pervasive-problem-00.txt > > > > Dear PERPASS, > > > > Stephen asked me to take a stab at a problem statement for PERPASS. With > some help from Bruce, Cullen, and Ted, the results have just been publish= ed > as draft-barnes-pervasive-problem-00. > > > > In general, this draft tries to outline at a technical level what we mean > by pervasive attack, and what the high level mitigations are. > > > > Comments welcome! > > > > Thanks, > > --Richard > > > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 6, 2014 at 9:17 PM > Subject: New Version Notification for draft-barnes-pervasive-problem-00.t= xt > To: Cullen Jennings , Ted Hardie , > Bruce Schneier , Richard Barnes > > > > A new version of I-D, draft-barnes-pervasive-problem-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-pervasive-problem > Revision: 00 > Title: Pervasive Attack: A Threat Model and Problem Statement > Document date: 2014-01-06 > Group: Individual Submission > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ > Htmlized: > http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 > > > Abstract: > Documents published in 2013 have revealed several classes of > "pervasive" attack on Internet communications. In this document, we > review the main attacks that have been published, and develop a > threat model that describes these pervasive attacks. Based on this > threat model, we discuss the techniques that can be employed in > Internet protocol design to increase the protocols robustness to > pervasive attacks. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --001a11c2553239317504ef5896cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 6, 2014 at 9:49 PM, Paul Lambert <paul@marvell= .com> wrote:

> C= omments welcome!

=A0

Nice wor= k!


Thanks!
=A0

M= inor comment =96 don=92t see any text on L2 wireless tracking.=A0 All of ou= r wireless devices effectively beacon our location and identity (e.g 802.11= MAC addresses and probing). While not strictly a IETF domain of work (L2),= the solutions to this class of problems do require changes in IETF protoco= ls.


I also wonder to what degree this is= a "pervasive attack" issue. =A0If the attack involves being phys= ically close to the victim, it's hard to see how the attacker would ach= ieve a pervasive scale.

What sorts of changes to IETF protocols are you imagini= ng?

--Richard


<= div>=A0

<= u>

=A0

Paul

=A0

=A0<= /p>

From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, January 06, 2014 6:24 PM
To: perpass
S= ubject: [perpass] Fwd: New Version Notification for draft-barnes-pervas= ive-problem-00.txt

=A0

Dea= r PERPASS,

=A0

Stephen asked me to take a stab at a pr= oblem statement for PERPASS. =A0With some help from Bruce, Cullen, and Ted,= the results have just been published as draft-barnes-pervasive-problem-00.=

=A0

In general, this draft tries to outline at a technical level= what we mean by pervasive attack, and what the high level mitigations are.= =A0

=A0

Comments welcome!

=A0

Thanks,

--Richard=

=A0

=A0

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for= draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Bruce Schneier <schneier@schneier.c= om>, Richard Barnes <rlb@ipv.sx>



A new version of I-D, draft-barnes-pervasive-problem-00.txt
= has been successfully submitted by Richard Barnes and posted to the
IETF= repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-barnes-pervasive-proble= m
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Pervasive Attack: A Threat Model and Problem Stat= ement
Document date: =A02014-01-06
Group: =A0 =A0 =A0 =A0 =A0Individu= al Submission
Pages: =A0 =A0 =A0 =A0 =A023
URL: =A0 =A0 =A0 =A0 =A0 = =A0http://www.ietf.org/internet-drafts/draft-b= arnes-pervasive-problem-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-barnes-pervasive-problem/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-barnes-pervasive-problem-00


Abstract:
=A0 =A0Documents published in 2013 have revealed sever= al classes of
=A0 =A0"pervasive" attack on Internet communicat= ions. =A0In this document, we
=A0 =A0review the main attacks that have b= een published, and develop a
=A0 =A0threat model that describes these pervasive attacks. =A0Based on thi= s
=A0 =A0threat model, we discuss the techniques that can be employed in=
=A0 =A0Internet protocol design to increase the protocols robustness to=
=A0 =A0pervasive attacks.




Please note that it may take a couple of minutes from the t= ime of submission
until the htmlized version and diff are available at <= a href=3D"http://tools.ietf.org" target=3D"_blank">tools.ietf.org.
<= br> The IETF Secretariat

= =A0


--001a11c2553239317504ef5896cb-- From watsonbladd@gmail.com Mon Jan 6 19:08:35 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453051AE3E1 for ; Mon, 6 Jan 2014 19:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX8sl2Py8Q5o for ; Mon, 6 Jan 2014 19:08:32 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3171AE3E0 for ; Mon, 6 Jan 2014 19:08:32 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so16266507wgg.4 for ; Mon, 06 Jan 2014 19:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aiBQaJOjb7n6k2w3f1RiYQ36sUqvPvgsp/EGTY96CyM=; b=c1ZdeC3v60InWTFDkhsT5yKH8OdejY+SU5grY1k9qns1tPfTjod0N/bQquOWFoPGo+ XZp9TLB6Iko3j19F6xzdq1PE+arXb6uf5F2dE+ukZKVF3P9DS6bIMk34Zzt9gNXAw1pf /Nd81RTp9XJIhVmZEDEm+GWg3dn9fNg12C8V5QpMZWjIuEeSbcjsO/CtGk5Dn5nbxOPW avnkyb93kGcUz38FWAL4qpNyCihIsK/Ykt+JAayphOX1jj8V3bsdV6GMbkFPLwNPq0GY KJazhkoufUAzLpcj+qZwLNkeqxugCTJ70sYbd2dEjN1rLhqlz+Rn8RgvLm/B5eaPNgna PYaw== MIME-Version: 1.0 X-Received: by 10.195.13.234 with SMTP id fb10mr5913807wjd.50.1389064103029; Mon, 06 Jan 2014 19:08:23 -0800 (PST) Received: by 10.194.242.131 with HTTP; Mon, 6 Jan 2014 19:08:22 -0800 (PST) In-Reply-To: References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 19:08:22 -0800 Message-ID: From: Watson Ladd To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 03:08:35 -0000 On Mon, Jan 6, 2014 at 6:24 PM, Richard Barnes wrote: > Dear PERPASS, > > Stephen asked me to take a stab at a problem statement for PERPASS. With > some help from Bruce, Cullen, and Ted, the results have just been published > as draft-barnes-pervasive-problem-00. > > In general, this draft tries to outline at a technical level what we mean by > pervasive attack, and what the high level mitigations are. > > Comments welcome! Minor quibble: Intermediate nodes can also be active attackers, e.g. an ISP could insert fake email for its customers. At a higher level this draft feels overly removed from the real problem: users assumptions about what is public on the Internet have frequently been violated, even when technical measures to address these issues exist. This gets mentioned in passing, but should be front and centre. The NSA is not the only organisation doing this: Saudi Arabia, the UK, China, Ethiopia, France all have major monitoring systems in place that can only work because of how weak the core protocols of the internet are against manipulation. (And let's not forget the Pakistani ISP that accidentally knocked Youtube offline) Also, BGP tricks mean that anyone can be local. The point should be very simple: no more cleartext, authenticate everything, limit authority, and produce an audit trail for when things go wrong. Now let's see if we can do more about it than the CRYPTO '13 rump session accomplished.[1] Sincerely, Watson Ladd [1] For those who are unfamiliar: http://www.youtube.com/watch?v=cVUIk6nXVcw is the best statement of the issue and the solution. > > Thanks, > --Richard > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 6, 2014 at 9:17 PM > Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt > To: Cullen Jennings , Ted Hardie , > Bruce Schneier , Richard Barnes > > > > A new version of I-D, draft-barnes-pervasive-problem-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-pervasive-problem > Revision: 00 > Title: Pervasive Attack: A Threat Model and Problem Statement > Document date: 2014-01-06 > Group: Individual Submission > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ > Htmlized: http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 > > > Abstract: > Documents published in 2013 have revealed several classes of > "pervasive" attack on Internet communications. In this document, we > review the main attacks that have been published, and develop a > threat model that describes these pervasive attacks. Based on this > threat model, we discuss the techniques that can be employed in > Internet protocol design to increase the protocols robustness to > pervasive attacks. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From rlb@ipv.sx Mon Jan 6 19:42:00 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0DA1AE40D for ; Mon, 6 Jan 2014 19:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LViN9P11wGum for ; Mon, 6 Jan 2014 19:41:54 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7788D1AE40B for ; Mon, 6 Jan 2014 19:41:54 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wp4so19304917obc.41 for ; Mon, 06 Jan 2014 19:41:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GCqfV4H9XgJXSOoDfUOkF99l87vK1wdV8Ugzd/H0gYM=; b=eU+dSwUc+IuOrEWvLtVFNn2OZ7+kpCgkoNFNBmBiQl3at1DiTd4ISeu1jaGPVPb8Vf /cShSR7yJ98YP1sPiYzBbOidSQLu99WMdA81jc7CKBqIWm+oc6IbxSHb8JJuTdNg/O7E fFIoyrHcloZBWaW8Yex8MD0zxd6rsQElExYpkWE0wj/sTuMO43jWJm6TfJ4dGxCL9lEr AuC/0aqzsYp58vv1aQIejNuTnuQhGqlF0LvNQPA1HDdD4EYJ3hWkbtvIER267/OBpPxb xBMQDXN9N/wI+oMh9ZWq0eD5pNpWcArqzOuceLv/aOF3hI29Bh68qgiA9q2FJEfdzxcL C+dw== X-Gm-Message-State: ALoCoQnO0YXUUBN7Oymhb2er1Kls/a8/JH7c+FDJCqvXrdL/uCWAjeIXEjh5mKqMHnggOvAHOVmL MIME-Version: 1.0 X-Received: by 10.182.148.106 with SMTP id tr10mr239235obb.65.1389066105694; Mon, 06 Jan 2014 19:41:45 -0800 (PST) Received: by 10.60.54.65 with HTTP; Mon, 6 Jan 2014 19:41:45 -0800 (PST) In-Reply-To: References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 22:41:45 -0500 Message-ID: From: Richard Barnes To: Watson Ladd Content-Type: multipart/alternative; boundary=089e012940d8ccbfd204ef5927bf Cc: perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 03:42:01 -0000 --089e012940d8ccbfd204ef5927bf Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 6, 2014 at 10:08 PM, Watson Ladd wrote: > On Mon, Jan 6, 2014 at 6:24 PM, Richard Barnes wrote: > > Dear PERPASS, > > > > Stephen asked me to take a stab at a problem statement for PERPASS. With > > some help from Bruce, Cullen, and Ted, the results have just been > published > > as draft-barnes-pervasive-problem-00. > > > > In general, this draft tries to outline at a technical level what we > mean by > > pervasive attack, and what the high level mitigations are. > > > > Comments welcome! > > Minor quibble: > Intermediate nodes can also be active attackers, e.g. an ISP could > insert fake email for its customers. > Clearly, anyone on-path can be an active attacker. And, as some of the TOR-related revelations show, some off-path entities as well. > At a higher level this draft feels overly removed from the real > problem: users assumptions about what is > public on the Internet have frequently been violated, even when > technical measures to address these issues > exist. This gets mentioned in passing, but should be front and centre. > That seems like it might be a better topic for draft-farrell-perpass-attack. We're trying to stick to technical things in this draft, so "user assumptions" are kind of out of scope. > The NSA is not the only organisation doing this: Saudi Arabia, the UK, > China, Ethiopia, France all have major monitoring > systems in place that can only work because of how weak the core > protocols of the internet are against manipulation. (And let's not > forget the > Pakistani ISP that accidentally knocked Youtube offline) > Indeed. We cite the Great Firewall as an example. (And technically, that Pakistani ISP didn't accidentally knock YouTube offline; the only accident was knocking YouTube offline *outside* *of* *Pakistan*.) > Also, BGP tricks mean that anyone can be local. > s/local/on-path/ > The point should be very simple: no more cleartext, authenticate > everything, limit authority, and produce an audit trail for when > things go wrong. > That seems like a concise statement of the mitigations discussed in Section 5. We can try to make that message clearer in future versions, though. Thanks, --Richard > Now let's see if we can do more about it than the CRYPTO '13 rump > session accomplished.[1] > Sincerely, > Watson Ladd > [1] For those who are unfamiliar: > http://www.youtube.com/watch?v=cVUIk6nXVcw is the best statement of > the issue and the solution. > > > > Thanks, > > --Richard > > > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Mon, Jan 6, 2014 at 9:17 PM > > Subject: New Version Notification for > draft-barnes-pervasive-problem-00.txt > > To: Cullen Jennings , Ted Hardie , > > Bruce Schneier , Richard Barnes > > > > > > > > A new version of I-D, draft-barnes-pervasive-problem-00.txt > > has been successfully submitted by Richard Barnes and posted to the > > IETF repository. > > > > Name: draft-barnes-pervasive-problem > > Revision: 00 > > Title: Pervasive Attack: A Threat Model and Problem Statement > > Document date: 2014-01-06 > > Group: Individual Submission > > Pages: 23 > > URL: > > > http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ > > Htmlized: > http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 > > > > > > Abstract: > > Documents published in 2013 have revealed several classes of > > "pervasive" attack on Internet communications. In this document, we > > review the main attacks that have been published, and develop a > > threat model that describes these pervasive attacks. Based on this > > threat model, we discuss the techniques that can be employed in > > Internet protocol design to increase the protocols robustness to > > pervasive attacks. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --089e012940d8ccbfd204ef5927bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 6, 2014 at 10:08 PM= , Watson Ladd <watsonbladd@gmail.com> wrote:
On Mon, Jan 6, 2014 at 6:24 PM, Richard = Barnes <rlb@ipv.sx> wrote:
> Dear PERPASS,
>
> Stephen asked me to take a stab at a problem statement for PERPASS. = =A0With
> some help from Bruce, Cullen, and Ted, the results have just been publ= ished
> as draft-barnes-pervasive-problem-00.
>
> In general, this draft tries to outline at a technical level what we m= ean by
> pervasive attack, and what the high level mitigations are.
>
> Comments welcome!

Minor quibble:
Intermediate nodes can also be active attackers, e.g. an ISP could
insert fake email for its customers.

Clearly, anyone on-path can be an active attacker. =A0And, as some of t= he TOR-related revelations show, some off-path entities as well.

=A0
At a higher level this draft feels overly removed from the real
problem: users assumptions about what is
public on the Internet have frequently been violated, even when
technical measures to address these issues
exist. This gets mentioned in passing, but should be front and centre.
<= /blockquote>

That seems like it might be a better = topic for draft-farrell-perpass-attack. =A0We're trying to stick to tec= hnical things in this draft, so "user assumptions" are kind of ou= t of scope.

=A0
The NSA is not the only organisation doing this: Saudi Arabia, the UK,
China, Ethiopia, France all have major monitoring
systems in place that can only work because of how weak the core
protocols of the internet are against manipulation. (And let's not
forget the
Pakistani ISP that accidentally knocked Youtube offline)

Indeed. =A0We cite the Great Firewall as an example= . =A0

(And technically, that Pakistani= ISP didn't accidentally knock YouTube offline; the only accident was k= nocking YouTube offline *outside* *of* *Pakistan*.) =A0

=A0
Also, BGP tricks mean that anyone can be local.

s/local/on-path/

=A0
The point should be very simple: no more cleartext, authenticate
everything, limit authority, and produce an audit trail for when
things go wrong.

That seems like = a concise statement of the mitigations discussed in Section 5. =A0
<http://tools.ietf.org/html/draft-barnes-pervasive-probl= em-00#section-5>

We can try to make that message clearer in = future versions, though. =A0

Thanks,
--Richard

=A0
Now let's see if we can do more about it than the CRYPTO '13 rump session accomplished.[1]
Sincerely,
Watson Ladd
[1] For those who are unfamiliar:
= http://www.youtube.com/watch?v=3DcVUIk6nXVcw is the best statement of the issue and the solution.
>
> Thanks,
> --Richard
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Mon, Jan 6, 2014 at 9:17 PM
> Subject: New Version Notification for draft-barnes-pervasive-problem-0= 0.txt
> To: Cullen Jennings <fluffy@cis= co.com>, Ted Hardie <ted.ie= tf@gmail.com>,
> Bruce Schneier <schneier@s= chneier.com>, Richard Barnes <rlb@ipv.sx>
>
>
>
> A new version of I-D, draft-barnes-pervasive-problem-00.txt
> has been successfully submitted by Richard Barnes and posted to the > IETF repository.
>
> Name: =A0 =A0 =A0 =A0 =A0 draft-barnes-pervasive-problem
> Revision: =A0 =A0 =A0 00
> Title: =A0 =A0 =A0 =A0 =A0Pervasive Attack: A Threat Model and Problem= Statement
> Document date: =A02014-01-06
> Group: =A0 =A0 =A0 =A0 =A0Individual Submission
> Pages: =A0 =A0 =A0 =A0 =A023
> URL:
> http://www.ietf.org/internet-drafts/draft= -barnes-pervasive-problem-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-barnes-perv= asive-problem/
> Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft= -barnes-pervasive-problem-00
>
>
> Abstract:
> =A0 =A0Documents published in 2013 have revealed several classes of > =A0 =A0"pervasive" attack on Internet communications. =A0In = this document, we
> =A0 =A0review the main attacks that have been published, and develop a=
> =A0 =A0threat model that describes these pervasive attacks. =A0Based o= n this
> =A0 =A0threat model, we discuss the techniques that can be employed in=
> =A0 =A0Internet protocol design to increase the protocols robustness t= o
> =A0 =A0pervasive attacks.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither =A0Liberty nor Safety."
-- Benjamin Franklin

--089e012940d8ccbfd204ef5927bf-- From linus@nordberg.se Mon Jan 6 23:15:41 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7685B1ADFBD for ; Mon, 6 Jan 2014 23:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIqdHoDOPFSV for ; Mon, 6 Jan 2014 23:15:39 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id 394D81AE45D for ; Mon, 6 Jan 2014 23:15:39 -0800 (PST) Received: from tool.nordberg.se (h158n2-asp-a13.ias.bredband.telia.com [217.210.64.158]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 5F479116B4; Tue, 7 Jan 2014 08:15:29 +0100 (CET) From: Linus Nordberg To: Richard Barnes References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> Date: Tue, 07 Jan 2014 08:15:28 +0100 In-Reply-To: (Richard Barnes's message of "Mon, 6 Jan 2014 22:01:03 -0500") Message-ID: <87lhys1cvj.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Cc: Paul Lambert , perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 07:15:41 -0000 Richard Barnes wrote Mon, 6 Jan 2014 22:01:03 -0500: | I also wonder to what degree this is a "pervasive attack" issue. If the | attack involves being physically close to the victim, it's hard to see how | the attacker would achieve a pervasive scale. An attacker could control a large number of "home routers". Do we need stronger indications that's actually being done at a large scale before we consider strengthening L2 protocols and best practices? If so, what is "large scale" and "pervasive"? From chuck@eesst.org Tue Jan 7 02:46:29 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FBC1ADEB4 for ; Tue, 7 Jan 2014 02:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6z6TZAjk9RR for ; Tue, 7 Jan 2014 02:46:26 -0800 (PST) Received: from obermeyer.clearbearing.net (smtp.clearbearing.net [IPv6:2607:fc58:1004::9]) by ietfa.amsl.com (Postfix) with ESMTP id D18D11ACC81 for ; Tue, 7 Jan 2014 02:46:25 -0800 (PST) Received: from mail.nuleaf.com (unknown [32.143.157.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by obermeyer.clearbearing.net (Postfix) with ESMTPSA id 867BFEFD2B; Tue, 7 Jan 2014 05:45:53 -0500 (EST) Received: from [192.168.100.139] (IP139.NULEAF.COM [192.168.100.139]) by mail.nuleaf.com (Postfix) with ESMTP id 315CB4171E; Tue, 7 Jan 2014 05:45:49 -0500 (EST) From: Chuck Davin To: "Fred Baker (fred)" In-Reply-To: <686BDF23-A166-42DB-BB70-FD4E5C288E39@cisco.com> References: <1388788989.1552.30.camel@chuck> <686BDF23-A166-42DB-BB70-FD4E5C288E39@cisco.com> Content-Type: text/plain; charset="UTF-8" Organization: Rarely Date: Tue, 07 Jan 2014 05:45:47 -0500 Message-ID: <1389091547.1959.26.camel@chuck> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: quoted-printable X-ClearBearing-MailScanner-Information: Please contact ClearBearing (http://www.clearbearing.com) for more information on our anti-spam/anti-virus efforts. X-ClearBearing-MailScanner-ID: 867BFEFD2B.ABB15 X-ClearBearing-MailScanner: Found to be clean X-ClearBearing-MailScanner-IP-Protocol: IPv4 X-ClearBearing-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-7.002, required 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_20 -0.00, TLS_AUTH_NOSPAM -5.00) X-ClearBearing-MailScanner-From: chuck@eesst.org X-ClearBearing-MailScanner-Watermark: 1389696369.77561@9M1DDZAr4REWKKROVYZcsw Cc: perpass Subject: Re: [perpass] draft-davin-eesst X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chuck@eesst.org List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 10:46:29 -0000 Hi Fred, Thanks for clarifying. Whatever the terminology, your point is well made that end-to-end encryption is probably the only sufficient protection. I haven't quite yet given up on privacy or basic human rights, even for students. Better to light a candle and all that. Stay warm, Chuck On Sat, 2014-01-04 at 00:01 +0000, Fred Baker (fred) wrote: > On Jan 3, 2014, at 2:43 PM, Chuck Davin wrote: > > I may not have completely understood your second security concern. It > > seems to relate to the vulnerability of student information either at > > rest or in transit across MTAs. To me, these seem like different > > cases. > >=20 > > The information is "at rest" only when held by the originator, the > > student, or the recipient, but they are all authorized users. =20 >=20 > In that, I will disagree, or will ask you to accept two variants of "at r= est". I'm using the term in the sense of having the entire transmission in = one place in the application layer and a choice of what to do with it, as o= pposed to looking at it at the network layer or lower and simply passing th= e trash.=20 >=20 > Ask yourself, for example, what an Ironport or Barracuda Spam Barrier is;= to my mind, it is an MTA that analyzes an email message and applies a poli= cy to it. In some defined set of cases, it might observe that the message c= omes from a common business partner and is therefore likely to be OK, and p= asses it like any other MTA might. In another set of cases, it might summar= ily discard the message, and in a third set of cases, it might simply hold = it, or it might redirect it to somewhere else for further processing. In de= termining whether an email is viral, it might ask whether users receiving t= he message are marking it junk, and might as a result search for it in a he= ld database and "junk" it. And it might look through attachments for recogn= izable patterns of malware. >=20 > If a MIME object is encrypted, it is harder to poke through for malware s= tructures. Other analyses, such as looking for common names of objects carr= ied in MIME, can still be done. So for most of the purposes relevant to per= vasive monitoring, at least to my small mind, it is at rest. >=20 > But we agree that in the two MUAs, it is at rest. I will argue that it wi= ll spend most of its life at rest in the databases of at least some of the = institutions. My concern there is with the integrity and privacy of the dat= a itself. >=20 > Walking off into another world, consider automated billing such as is int= ended to be done in the smart grid. These are records that will have to be = reproduced and proven valid in the event of a billing dispute, and therefor= e must be retained. However, not everyone is authorized to have access to t= he data in the same form. The billing agent needs access that will support = billing, which may include how many KWH were transferred at each of several= billing rates. The electrical utility itself needs aggregate information f= or planning purposes. The homeowner, at least in California, is supposed to= be able to access their own data in real time (for some definition of that= term) in a manner that allows them to evaluate changes they make to their = homes. And a their that has access to the billing or real-time data might u= se it as a way to remotely case a break-in target. Data at rest becomes a m= eans not only for legitimate and authorized behavior, but inappropriate and= unauthorized behavior. >=20 > Data at rest in the medical world is notoriously used to investigate medi= cal conditions that an insurer would like to not have to cover. Data at res= t is sought by others for various purposes. Target recently had a problem w= ith its POS systems that captured credentials for some 40M credit card acco= unts.=20 >=20 > So yes, while the risks are probably not as high with high school transcr= ipts, I think the same fundamental issue is in play. I'm concerned about th= e transcript five years after the institution has received it. I'd like a h= acker to not be able to gain access to its contents. >=20 > > Your closing paragraph seems to sketch an alternative approach to the > > MTA transit problem (??) or other "casual access." I took its gist to > > be that, absent student encryption, the originator could control > > access to the student data using the originator's encryption keys. In > > common with other centralized approaches, it is, as you say, "not > > perfect security." In particular, the student is not really in control > > of her own data. >=20 > Well, I would submit that the student is still not in control of their ow= n data. Once they give it to someone else, that someone can give it to an a= dditional party without the student's knowledge. And the level of limits th= at can be placed on that are pretty low; the student could encrypt it in th= e public key of the institution s/he sends it to, meaning that only that pe= rson or institution can open it, but once decrypted, it is in the clear and= can be saved and transferred. So while I support the goal, I think it has = limits. >=20 > > I undertook this work less to innovate and more to address a real > > world problem. Although, to this community, the posted draft should > > seem pedestrian, to a broader audience, it clearly demonstrates that > > large centralized databases are not the only technical option for > > addressing school transcript distribution. The centralized approach > > permits students little real privacy and no real control over > > distribution of their own personal information. In contrast, the > > common format and distributed approach in the posting assign protocol > > roles to the various players that are appropriate to their proper > > rights and responsibilities. Review, support, and implementation > > within this community would counter the claim that a more > > paternalistic, centralized approach is the only one that is > > technically feasible. >=20 > Ah, yes, I have enrolled a kid in college as well, and has to specify the= set of schools that the student's transcripts would be sent to. I get this= . That said, what I suggested (that each institution have a public key and = distribute the keys to each other in some way) is only centralized if you c= onsider hkp://wwwkeys.pgp.net and its friends a centralized server. >=20 > > Thanks for your very thoughtful review and comments. > >=20 > > Best, > > Chuck > >=20 > > On Thu, 2014-01-02 at 18:06 +0000, Fred Baker (fred) wrote: > >> I scanned quickly through draft-davin-eesst with a few basic puzzlemen= ts in mind. The mechanism makes sense. I have two questions on security/pri= vacy considerations, one on the protocol involved, and one on scope. I am c= opying perpass, because I suspect that my considerations have bearing on th= e broader topic of pervasive monitoring of traffic. > >>=20 > >> If I understand correctly, the EESST specification is intended to faci= litate the secure transmission of data private to one party but originated = by a second party to a set of third parties with legitimate and authorized = interest. The specific case is a secondary school transcript, being sent by= a student, originated by an institution, and received by a set of other in= stitutions; the data is, of course, private to the the student, who is pres= umably applying to the receiving institutions.=20 > >>=20 > >> My question on scope is: "why so narrow a description?" I can think of= other cases in which data private to one party and originated by a second = party is sent to a set of third parties with legitimate and authorized inte= rest; medical records come quickly to mind. I could imagine the basic mecha= nism being described in generic terms and the transmission of transcripts d= escribed separately as a use case for the mechanism.=20 > >>=20 > >> My protocol question is "why spend so much time on the structure of th= e email message?" If the student has the files, they could be communicated = via http upload, IM, USB key, twitter, or any other application. Even if em= ail is used, the student is likely to simply attach them to an email messag= e using his or her favorite email tool without regard to the specifics of t= he EESST specification. In any case, the transmission will need context: un= less s/he is uploading them to an application web page at the receiving ins= titution (which is its own context), the student will likely include either= text or another file as a cover letter. Why not simply say that the files = are exchanged without reference to the protocol in question? > >>=20 > >> But now to what I consider the heart of the matter.=20 > >>=20 > >> The specification calls for a pair of files (XML and PDF) to be signed= by the originating institution, for purposes of authenticity and integrity= checking, and for the MIME object containing it to be optionally encrypted= , so that it cannot be inspected in an MTA. I understand that encryption be= ing optional, in that few mail tools make S/MIME or OpenPGP easy enough for= a non-expert to use - even in the IETF, few have PGP keys, and since our l= ists don't have keys, even this email is being sent in the clear. So the ca= ll for encryption is largely vacuous, and the very real possibility remains= for inspection of data while at rest in an MTA or captured in flight on a = traffic analyzer. Due to our failure to provide simple key creation and man= agement tools, this private and important data is accessible to a casual ey= e in flight. > >>=20 > >> However, in the use case, the transcript is likely to survive as a rec= ord for years, and perhaps forever, but only be in transit for a period of = seconds to minutes in the usual case. The specification leaves the data at = rest unencrypted, available for casual inspection. One could argue that thi= s is not an issue with a transcript; nobody is going to lose their job over= having gotten a bad grade decades earlier. In the medical record use case,= it can have dramatic effects. I think the primary threat is unauthorized o= r inappropriate access/use when the data is at rest.=20 > >>=20 > >> Why not have the originating institution encrypt the data using its pr= ivate key and make that key available to other institutions? In this or ano= ther specification, you could give them a naming guideline that would ident= ify the file as pertaining to an individual and an institution, and therefo= re a specified public key. This is not perfect security, of course; an unau= thorized party that obtained the public key of the originating institution = could read the file. But it at least forces them to do so, as opposed to le= aving the data open to hack or casual access. > >=20 > >=20 >=20 > =E2=80=A2 Make things as simple as possible, but not simpler. > Albert Einstein >=20 From stephen.farrell@cs.tcd.ie Tue Jan 7 06:05:38 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E091AE067 for ; Tue, 7 Jan 2014 06:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMg9NEv1mcwN for ; Tue, 7 Jan 2014 06:05:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2F1ADF98 for ; Tue, 7 Jan 2014 06:05:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8C90BDF9; Tue, 7 Jan 2014 14:05:26 +0000 (GMT) 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 umQ5f11hbDiC; Tue, 7 Jan 2014 14:05:23 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.45.52.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 45165BE56; Tue, 7 Jan 2014 14:05:23 +0000 (GMT) Message-ID: <52CC09A3.2080906@cs.tcd.ie> Date: Tue, 07 Jan 2014 14:05:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Richard Barnes , perpass References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 14:05:38 -0000 Richard et al. Many thanks for getting this out. I think its a fine start. I guess one thing to check is whether this captures all of the significant points from the various other "problem statement" contributions. Ta, S. On 01/07/2014 02:24 AM, Richard Barnes wrote: > Dear PERPASS, > > Stephen asked me to take a stab at a problem statement for PERPASS. With > some help from Bruce, Cullen, and Ted, the results have just been published > as draft-barnes-pervasive-problem-00. > > In general, this draft tries to outline at a technical level what we mean > by pervasive attack, and what the high level mitigations are. > > Comments welcome! > > Thanks, > --Richard > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 6, 2014 at 9:17 PM > Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt > To: Cullen Jennings , Ted Hardie , > Bruce Schneier , Richard Barnes > > > > A new version of I-D, draft-barnes-pervasive-problem-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-pervasive-problem > Revision: 00 > Title: Pervasive Attack: A Threat Model and Problem Statement > Document date: 2014-01-06 > Group: Individual Submission > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ > Htmlized: http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 > > > Abstract: > Documents published in 2013 have revealed several classes of > "pervasive" attack on Internet communications. In this document, we > review the main attacks that have been published, and develop a > threat model that describes these pervasive attacks. Based on this > threat model, we discuss the techniques that can be employed in > Internet protocol design to increase the protocols robustness to > pervasive attacks. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From lear@cisco.com Tue Jan 7 06:39:19 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFD71AD9B6 for ; Tue, 7 Jan 2014 06:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck2Cph5mUAq0 for ; Tue, 7 Jan 2014 06:39:17 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 70E221AD8EC for ; Tue, 7 Jan 2014 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11937; q=dns/txt; s=iport; t=1389105548; x=1390315148; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=UPR/hv1UMoS6nT1zVOpkKwlm8Ibv1oJJ1TgJIcyXdgo=; b=GhenhmWrfo3yC5b82Aq6CdtEcqSm3/k9ywE1AasFQH7oLTquhydqc+9H PzOCtsS0XC4yyVcUpqBTdxu8GzPu7rqlHztFd23Vz6EjNGgIRN41IEE2H muABcgAI1y0E1H1DqXlQ8ZlP6+ztvyJgrPGDhcK8zatl0cBEYgIxfJ3Cq Y=; X-IronPort-AV: E=Sophos;i="4.95,619,1384300800"; d="scan'208,217";a="3292844" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 07 Jan 2014 14:39:07 +0000 Received: from mctiny.local ([10.61.211.253]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s07Ed6DM026894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 14:39:06 GMT Message-ID: <52CC118A.7010008@cisco.com> Date: Tue, 07 Jan 2014 15:39:06 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Richard Barnes , perpass , Bruce Schneier , Cullen Jennings , Ted Hardie References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010809020406050802020004" Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 14:39:19 -0000 This is a multi-part message in MIME format. --------------010809020406050802020004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Richard, Bruce, Cullen, and Ted, Thanks for this draft. I wonder if it would be useful to create an additional table on what can be classified, and at what point. So for instance: Layer Field Risk ============================================================= L2 | src/dst | correlation of physical device | | and IP address | | IP Layer | src/dst | rough correlation with location | | and identity, with hints as to | | services being used | | (e.g., movies.example.com) Transport | port# | correlation of activity based on | | transport service field | | ============================================================ This makes it clear that it's not just the application data that is desired. You of course say as much in the draft. It's good that you talk about aggregation. There is an inherent tension between use of aggregation to blind or blur, and the risk of the aggregating device being managed by a witting or unwitting collaborator. We have at least some evidence that this has happened. And all of this must be put into the context of other threats against which it must be balanced (e.g., phishing, spam, etc) where encryption can defeat the existing remediations. Finally, several comments about overlay routing, such as TOR. As I think Bruce you yourself pointed out, if a small subset of people make use of it, they make themselves targets. Additionally bandwidth isn't free, and neither is delay. Stretch in the routing system matters. A fundamental issue here is who can do an effective job of anonymizing IP addresses at the size and scale of the Internet. Eliot On 1/7/14 3:24 AM, Richard Barnes wrote: > Dear PERPASS, > > Stephen asked me to take a stab at a problem statement for PERPASS. > With some help from Bruce, Cullen, and Ted, the results have just > been published as draft-barnes-pervasive-problem-00. > > In general, this draft tries to outline at a technical level what we > mean by pervasive attack, and what the high level mitigations are. > > Comments welcome! > > Thanks, > --Richard > > > > ---------- Forwarded message ---------- > From: > > Date: Mon, Jan 6, 2014 at 9:17 PM > Subject: New Version Notification for > draft-barnes-pervasive-problem-00.txt > To: Cullen Jennings >, Ted > Hardie >, Bruce > Schneier >, > Richard Barnes > > > > A new version of I-D, draft-barnes-pervasive-problem-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-pervasive-problem > Revision: 00 > Title: Pervasive Attack: A Threat Model and Problem Statement > Document date: 2014-01-06 > Group: Individual Submission > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/ > Htmlized: > http://tools.ietf.org/html/draft-barnes-pervasive-problem-00 > > > Abstract: > Documents published in 2013 have revealed several classes of > "pervasive" attack on Internet communications. In this document, we > review the main attacks that have been published, and develop a > threat model that describes these pervasive attacks. Based on this > threat model, we discuss the techniques that can be employed in > Internet protocol design to increase the protocols robustness to > pervasive attacks. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------010809020406050802020004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Richard, Bruce, Cullen, and Ted,

Thanks for this draft.  I wonder if it would be useful to create an additional table on what can be classified, and at what point.  So for instance:
     Layer         Field        Risk
   =============================================================
          L2    |  src/dst |  correlation of physical device
                |          |  and IP address
                |          |	
     IP Layer   |  src/dst |  rough correlation with location
                |          |  and identity, with hints as to
      	      	|          |  services being used
              	|          |  (e.g., movies.example.com)
     Transport  |  port#   |  correlation of activity based on
                |          |  transport	service	field
                |          |	
   ============================================================

This makes it clear that it's not just the application data that is desired.  You of course say as much in the draft.

It's good that you talk about aggregation.  There is an inherent tension between use of aggregation to blind or blur, and the risk of the aggregating device being managed by a witting or unwitting collaborator.  We have at least some evidence that this has happened.

And all of this must be put into the context of other threats against which it must be balanced (e.g., phishing, spam, etc) where encryption can defeat the existing remediations.

Finally, several comments about overlay routing, such as TOR.  As I think Bruce you yourself pointed out, if a small subset of people make use of it, they make themselves targets.  Additionally bandwidth isn't free, and neither is delay.  Stretch in the routing system matters.  A fundamental issue here is who can do an effective job of anonymizing IP addresses at the size and scale of the Internet.

Eliot


On 1/7/14 3:24 AM, Richard Barnes wrote:
Dear PERPASS,

Stephen asked me to take a stab at a problem statement for PERPASS.  With some help from Bruce, Cullen, and Ted, the results have just been published as draft-barnes-pervasive-problem-00.

In general, this draft tries to outline at a technical level what we mean by pervasive attack, and what the high level mitigations are.  

Comments welcome!

Thanks,
--Richard
 


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Bruce Schneier <schneier@schneier.com>, Richard Barnes <rlb@ipv.sx>



A new version of I-D, draft-barnes-pervasive-problem-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-pervasive-problem
Revision:       00
Title:          Pervasive Attack: A Threat Model and Problem Statement
Document date:  2014-01-06
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt
Status:         https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/
Htmlized:       http://tools.ietf.org/html/draft-barnes-pervasive-problem-00


Abstract:
   Documents published in 2013 have revealed several classes of
   "pervasive" attack on Internet communications.  In this document, we
   review the main attacks that have been published, and develop a
   threat model that describes these pervasive attacks.  Based on this
   threat model, we discuss the techniques that can be employed in
   Internet protocol design to increase the protocols robustness to
   pervasive attacks.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

--------------010809020406050802020004-- From benl@google.com Tue Jan 7 08:11:01 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7F1AE024 for ; Tue, 7 Jan 2014 08:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfNNRRHTzOfk for ; Tue, 7 Jan 2014 08:10:59 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A06DC1AE015 for ; Tue, 7 Jan 2014 08:10:59 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id x11so244495vbb.8 for ; Tue, 07 Jan 2014 08:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3wl0bX04bkjoZ4lBKXPSwNdJHyr7go1Li7etc6/vNZI=; b=CbMqsC/nUsYuKtdBqZffkFP6dwGhZ1pcxhREmhSkxffc9OF+SpMAlHZBDrBd4WAEJC 00P6mcXGzT+iwzddlXCxdGLutCBGI9TYj3OCS2xYRLK3AC9JakYVPIZ6ycfkudWjPxBg HWmYQrGzI2AW+cK0IoPxz/0kW98QqBzUXLyGmXDUwzahcxOHn5AcvCD+aDClotopaQ/u j3MRt3BfYKgYG0QywCL0ar7OrE6y/cYPgGfQimXgFikt5jnlmzvy6vaM0V18xii84yXJ cF4WNty50EqpHZMLdkCoMmDitE0hcGbZ4qN/Jl2YBo7TvDA2nrF3V93T+uctkoCEpA3v cJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3wl0bX04bkjoZ4lBKXPSwNdJHyr7go1Li7etc6/vNZI=; b=g2wxqS8PQDiU+4zL58/oCsGfxxXnRurajqbIay3yrWVd3fzcs1dvVryyEMfNh7t4ma kQbpZky5WDg1mu30POxLnxiOrbf3RJrh77FwOc8QdNfEvgJEmchz3Zyz5Zg5HpGkkZXu JywzBYOpJp6/Fh9ipvftPz4Qp89Vn1F8023EUFyGRRrZ9vbEOvjrHIdS8OMz2QKAMDXB uvVkNfxeEUp9j2M/bHSc7CNG/gG/yiAsSZ81gY7KMaLESmgrsObUmw6TySymtgnzPFVs H9CMCwtinY1jtIbZNxB/OlsygSbnxEwtEzkyQaV0LWmb+L4ZUqOxIr9V++/vSsy96s0M jOnQ== X-Gm-Message-State: ALoCoQnPZSk0UzK5O+pcbGN5D41JtAhkL+bMHMCgeYn+kHADD9v5PvUhl5BRXtdVLCUCzdxEh2vhJCtToJqWVX5mZ0HQkQsQcHMflWGGdmTTsDMwYbl5trAUdPZilX3WeqN3hHBozl7aujvYr69pf13QxrjOIs/E4LttCTbOeV1flxLVBa+u7fAaKMwiS4n92xyelKD69G+H MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr2694862vdb.37.1389111050471; Tue, 07 Jan 2014 08:10:50 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 08:10:50 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> <52C19300.3050201@bbn.com> Date: Tue, 7 Jan 2014 16:10:50 +0000 Message-ID: From: Ben Laurie To: Robin Wilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: perpass , Stephen Kent , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:11:01 -0000 On 6 January 2014 17:20, Robin Wilton wrote: > Hi all - > > A further suggestion inline. One motivation for my suggesting a change is > that I am instinctively uneasy when the word "proof" crops up in this kin= d > of context. I think what we're doing is providing the means to accrue > evidence, on the basis of which someone can make an inference as to wheth= er > correct log behaviour has been recorded. My suggestion already eliminated the word "proof". But I quite like your suggestion, too. Note, however, we are on the wrong lists. I will post a revised draft charter to therightkey shortly. > > R > > > On 6 Jan 2014, at 17:02, Ben Laurie wrote: > > On 30 December 2013 15:36, Stephen Kent wrote: > > Ben, > > > How's this? > > > [1] A cryptographically verifiable log is an append-only log of hashes > > of more-or-less anything that can prove its own correctness > > cryptographically. > > > For example, from RFC 6962: =E2=80=9CThe append-only property of each log= is > > technically achieved using Merkle Trees, which can be used to show > > that any particular version of the log is a superset of any particular > > previous version. Likewise, Merkle Trees avoid the need to blindly > > trust logs: if a log attempts to show different things to different > > people, this can be efficiently detected by comparing tree roots and > > consistency proofs. Similarly, other misbehaviours of any log (e.g., > > issuing signed timestamps for certificates they then don't log) can be > > efficiently detected and proved to the world at large.=E2=80=9D > > > See RFC 6962, > > http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf > > and http://www.links.org/files/RevocationTransparency.pdf for > > background. > > > Sorry to be so late in responding; holidays ... > > > Likewise. > > The text describing how 6962 uses Merkle trees is good. I think the > > phrase "prove its own correctness" is way too broad. The example > > you cite shows how to demonstrate internal consistency for a log, > > and to enable third parties to verify certain lob properties. That > > is much narrower than what the term "correctness" implies. > > > How about, instead of "can prove its own correctness > cryptographically", we say "allows efficient verification of > behaviour"? > > > "A cryptographically verifiable log is an append-only log of hashes, > structured in such a way as to provide efficiently-accessible, > cryptographically-supported evidence of correct [log] behaviour". > > That way, you capture the following: > > - use of hashing/cryptographic mechanisms to maintain the integrity of th= e > evidence trail > - reference to the relevance of structure (Merkle trees) > - de-coupling of the evidence (signed records) from what it is that the > evidence is intended to show (correct behaviour) > > Hope this helps - > > Robin > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From kent@bbn.com Tue Jan 7 10:19:53 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D11AE0E8; Tue, 7 Jan 2014 10:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKL24BQ2WaEW; Tue, 7 Jan 2014 10:19:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6101AE04B; Tue, 7 Jan 2014 10:19:51 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50604) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W0bFa-000Auu-5k; Tue, 07 Jan 2014 13:19:38 -0500 Message-ID: <52CC453A.8040508@bbn.com> Date: Tue, 07 Jan 2014 13:19:38 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> <52C19300.3050201@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:19:53 -0000 Ben, >> The text describing how 6962 uses Merkle trees is good. I think the >> phrase "prove its own correctness" is way too broad. The example >> you cite shows how to demonstrate internal consistency for a log, >> and to enable third parties to verify certain lob properties. That >> is much narrower than what the term "correctness" implies. > How about, instead of "can prove its own correctness > cryptographically", we say "allows efficient verification of > behaviour"? > I still find that phase vague. What sort of behavior is being verified? Isn't the behavior amenable to verification a function of the context details? For example, a self-signed cert is an example of a crypto construct that allows an RP to verify a few aspect of its "behavior" - the public key contained within the cert is matched to the private key used to sign it. - the cert content was not modified after it was signed But most of the other semantics of CA-issued certs are not verified by this construct. Steve From benl@google.com Tue Jan 7 10:28:56 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41131AE06D for ; Tue, 7 Jan 2014 10:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7YaxWTfqyAJ for ; Tue, 7 Jan 2014 10:28:54 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3E1AE0FF for ; Tue, 7 Jan 2014 10:28:54 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so426888veb.8 for ; Tue, 07 Jan 2014 10:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ysbyXLDt4lI76KkIz9CyHsegwvYmeup8jnwZl/1IENA=; b=h//vbjvwy5x4wf0JPHH9I+CZr5/CqcrwdcURQfeQQpQHSWgsAtex2YW+yflwKlKLnl nrDjZyDuuN3khI5h5wndn1iSfLJxlYWwcIMHrtyOrqZC0We0b71Mb8MYjIPDvwv+1+r9 DdxLFsWYlIGHDpEe3vpTRX4ksQ4fKO06cKyu8194PlWlrJvUiywW2y58aO2vj/hPVmjD q8DKB3wx7LHvW/ckQOVuw56doHgBDSVYAngTh339FFwBw/wymDvBxN0OdLgdiB+hl8o6 srchuPvPpdFLptrG7s9NhwWfuLS4M2SvEszfB/PavFi8N27f/SfIS3WVX34C7Gu/JXuq SX0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ysbyXLDt4lI76KkIz9CyHsegwvYmeup8jnwZl/1IENA=; b=icv7ImtAzTdlHe2SS/sPNx/lklEgWD7wvU6rou5Y7MAhqHww0wvc0bbXYm3ABGLIl7 v8BOBxJ1sdyoCpWxnwFtbU0y670f83d+kLf/GjAPAkiOR2kMvLJgbR9B6dMipNqO+FqI Pwmts8iTlQKhu+bQYEeEh4J4cbOgjsW3q9HPMS91SFooQXVzyokOvLRC2Amj4YGeudjI d+fTA+Et8yTHItf2JQQ9anFfGytO288NGXUSeoAFexM6htcXp2zRBcl7jpyJ8N2jsSr0 2GI1HVk8w0KlYe3mS3KvcgB6rkwfPwjNL/mcQAELSv/EDvC3P8sIX5dzdk3gdt6tCvwe Ik7Q== X-Gm-Message-State: ALoCoQktEhq1GJfYy1qWecBrtV10EbMNi5hVsqYjY1Ob/0VHSFsfSCKbw/hqqne+80Jbqo+RZdjdALXkeKg7fa9V1cBUcBBev5Gwm0s7yk7As4+z55A+f7Hybt695JC7uxIw7FnwtFX6kwUViRF9vllL8GHRHq9LmrjcC2K79Odj6UD9eSc586Ih29oTswOglpws/C5GV1go MIME-Version: 1.0 X-Received: by 10.52.229.195 with SMTP id ss3mr3682651vdc.45.1389119325438; Tue, 07 Jan 2014 10:28:45 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 10:28:45 -0800 (PST) In-Reply-To: <52CC453A.8040508@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> <52C19300.3050201@bbn.com> <52CC453A.8040508@bbn.com> Date: Tue, 7 Jan 2014 18:28:45 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:28:56 -0000 On 7 January 2014 18:19, Stephen Kent wrote: > Ben, > > >>> The text describing how 6962 uses Merkle trees is good. I think the >>> phrase "prove its own correctness" is way too broad. The example >>> you cite shows how to demonstrate internal consistency for a log, >>> and to enable third parties to verify certain lob properties. That >>> is much narrower than what the term "correctness" implies. >> >> How about, instead of "can prove its own correctness >> cryptographically", we say "allows efficient verification of >> behaviour"? >> > I still find that phase vague. What sort of behavior is being > verified? Isn't the behavior amenable to verification a function > of the context details? For example, a self-signed cert is > an example of a crypto construct that allows an RP to verify a few > aspect of its "behavior" > - the public key contained within the cert is matched to the > private key used to sign it. > - the cert content was not modified after it was signed > > But most of the other semantics of CA-issued certs are not > verified by this construct. As Stephen Farrell has pointed out, therightkey is the correct list for discussion. I have posted a revised charter there which phrases this in yet another way. See if you prefer that version. > > Steve From paul@marvell.com Tue Jan 7 13:53:07 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231FF1AE207 for ; Tue, 7 Jan 2014 13:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVThioLA4See for ; Tue, 7 Jan 2014 13:53:02 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id D21021AE1F5 for ; Tue, 7 Jan 2014 13:53:02 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s07Lqr3J010680; Tue, 7 Jan 2014 13:52:53 -0800 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0a-0016f401.pphosted.com with ESMTP id 1h8877379f-9 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 07 Jan 2014 13:52:53 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 7 Jan 2014 13:52:52 -0800 From: Paul Lambert To: Richard Barnes Date: Tue, 7 Jan 2014 13:52:50 -0800 Thread-Topic: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt Thread-Index: Ac8L8tAJZ7zncbfITvq1eHVe6iCP+Q== Message-ID: References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CEF1B2052BC2Apaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-07_07:2014-01-07,2014-01-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401070141 Cc: perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 21:53:07 -0000 --_000_CEF1B2052BC2Apaulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Richard, Minor comment =96 don=92t see any text on L2 wireless tracking. All of our= wireless devices effectively beacon our location and identity (e.g 802.11 = MAC addresses and probing). While not strictly a IETF domain of work (L2), = the solutions to this class of problems do require changes in IETF protocol= s. I also wonder to what degree this is a "pervasive attack" issue. If the at= tack involves being physically close to the victim, it's hard to see how th= e attacker would achieve a pervasive scale. MAC address are readily picked up by any hotspot, mobile device, or by spec= ial monitoring devices. Commercial systems already exist to aggregate, tra= ck and identify people based on unique identifiers in our radio transmissio= ns. A fun example is the Renew Orb (a trash can that tracks people): http://renewlondon.com/2013/06/renew-release-results-of-smartphone-data-= capture/ In one week, 7 trash cans were able to track 530M devices. I=92ve seen larger system solutions for sale suitable for country-wide anal= ysis at a security conference in Singapore a few years back =85 What sorts of changes to IETF protocols are you imagining? Most of the work is IEEE related. Impacts to IETF protocols might include: - IP address assignment and IPv6 usage of MAC address - authentication protocols/framework to bind ephemeral MAC address to longer term identity - RADIUS/EAP usage changes Paul --Richard Paul From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, January 06, 2014 6:24 PM To: perpass Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive= -problem-00.txt Dear PERPASS, Stephen asked me to take a stab at a problem statement for PERPASS. With s= ome help from Bruce, Cullen, and Ted, the results have just been published = as draft-barnes-pervasive-problem-00. In general, this draft tries to outline at a technical level what we mean b= y pervasive attack, and what the high level mitigations are. Comments welcome! Thanks, --Richard ---------- Forwarded message ---------- From: > Date: Mon, Jan 6, 2014 at 9:17 PM Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt To: Cullen Jennings >, Ted Hardie= >, Bruce Schneier >, Richard Barnes > A new version of I-D, draft-barnes-pervasive-problem-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-pervasive-problem Revision: 00 Title: Pervasive Attack: A Threat Model and Problem Statement Document date: 2014-01-06 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-barnes-pervasive-= problem-00.txt Status: https://datatracker.ietf.org/doc/draft-barnes-pervasive-pro= blem/ Htmlized: http://tools.ietf.org/html/draft-barnes-pervasive-problem-0= 0 Abstract: Documents published in 2013 have revealed several classes of "pervasive" attack on Internet communications. In this document, we review the main attacks that have been published, and develop a threat model that describes these pervasive attacks. Based on this threat model, we discuss the techniques that can be employed in Internet protocol design to increase the protocols robustness to pervasive attacks. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_CEF1B2052BC2Apaulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Richard,

Minor comment =96 don=92t se= e any text on L2 wireless tracking.  All of our wireless devices effec= tively beacon our location and identity (e.g 802.11 MAC addresses and probi= ng). While not strictly a IETF domain of work (L2), the solutions to this class of problems do require changes in IETF protocols.

=
I also wonder to what degree this is a "pervasive attack" issue.=  If the attack involves being physically close to the victim, it's ha= rd to see how the attacker would achieve a pervasive scale.
MAC address are readily picked up by any h= otspot, mobile device, or by special monitoring devices.  Commercial s= ystems already exist to aggregate, track and identify people based on uniqu= e identifiers in our radio transmissions.  

A= fun example is the Renew Orb (a trash can that tracks people):
In one week, 7 trash cans = were able to track 530M devices.  

I=92ve see= n larger system solutions for sale suitable for country-wide analysis at a = security conference in Singapore a few years back =85

<= span id=3D"OLK_SRC_BODY_SECTION">
W= hat sorts of changes to IETF protocols are you imagining?
=
Most of the work is IEEE related.  Impa= cts to IETF protocols might include:
 - IP address assignmen= t and IPv6 usage of MAC address
 - authentication protocols/= framework to bind ephemeral MAC address to 
   lon= ger term identity
 - RADIUS/EAP usage changes

=
Paul


--Richard


 

 

= Paul

 =

 <= /u>

From: perpass [mailto= :perpass-boun= ces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, January 06, 2014= 6:24 PM
To: perpass
Subject: [perpass] Fwd: New Versio= n Notification for draft-barnes-pervasive-problem-00.txt

&nbs= p;

Dear PERPASS,

 

Stephen asked me to take a stab at a problem statement for PERPASS.=  With some help from Bruce, Cullen, and Ted, the results have just be= en published as draft-barnes-pervasive-problem-00.

<= div>

 

In general, this draft tries to outline at a technical level what= we mean by pervasive attack, and what the high level mitigations are. &nbs= p;

 <= /p>

Comments welcome!

=  

Thanks,

--Richard

 

 

---------- Forwarded message ---= -------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt=
To: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Bruce Schneier <schneier@schneier.c= om>, Richard Barnes <rlb@ipv= .sx>



A new version of I-D, draft-barnes-pervasive-problem-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-pervasive-problem
Revision:       00
Title:          Pervasive Attack: A Threat Model a= nd Problem Statement
Document date:  2014-01-06
Group:          Individual Submission
Pages:          23
URL:            = http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt
Status:         https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/
Htmlized:       http://tools.ietf.org/html/draft-barnes-pervasive-problem-00

Abstract:
   Documents published in 2013 have revealed several classes of    "pervasive" attack on Internet communications.  = ;In this document, we
   review the main attacks that have been published, and develop = a
   threat model that describes these pervasive attacks.  Bas= ed on this
   threat model, we discuss the techniques that can be employed i= n
   Internet protocol design to increase the protocols robustness = to
   pervasive attacks.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

&= nbsp;


=


--_000_CEF1B2052BC2Apaulmarvellcom_-- From stefan.winter@restena.lu Tue Jan 7 22:52:28 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0961AE2F8 for ; Tue, 7 Jan 2014 22:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBURGHZK3dL6 for ; Tue, 7 Jan 2014 22:52:25 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2174E1AE2F5 for ; Tue, 7 Jan 2014 22:52:25 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 42B3510583 for ; Wed, 8 Jan 2014 07:52:15 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 318EE10580 for ; Wed, 8 Jan 2014 07:52:15 +0100 (CET) Message-ID: <52CCF598.3000605@restena.lu> Date: Wed, 08 Jan 2014 07:52:08 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rrG2DHdMLNfFradH5jBwvJUuhSgE7kNJc" X-Virus-Scanned: ClamAV Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 06:52:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rrG2DHdMLNfFradH5jBwvJUuhSgE7kNJc Content-Type: multipart/mixed; boundary="------------080506020901070405070303" This is a multi-part message in MIME format. --------------080506020901070405070303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I also wonder to what degree this is a "pervasive attack" issue. I= f > the attack involves being physically close to the victim, it's hard= > to see how the attacker would achieve a pervasive scale. >=20 > MAC address are readily picked up by any hotspot, mobile device, or by > special monitoring devices. Commercial systems already exist to > aggregate, track and identify people based on unique identifiers in our= > radio transmissions. =20 Another attack vector is the routing of RADIUS authentication requests for enterprise WiFi. The client device's MAC address is transported in the clear inside the RADIUS attribute Calling-Station-Id; so if your RADIUS server is "somewhere on the internet" (e.g. if you are part of a roaming consortium and send your authentication traffic via a off-site clearing house) then anybody who happens to listen on the wire learns about those MAC addresses and the associated user identity (or at least the realm he comes from, if the end user was mindful enough to configure identity privacy on his device). Partial mitigations for that are possible; RADIUS/TLS for example makes the clear-text transmission on IP level go away; but the fact that the clearinghouse gets to see all traffic does not go away with that. You should read https://tools.ietf.org/html/draft-wierenga-ietf-eduroam-01 section 3.5 - this issue is discussed in some detail there. A partial solution that may make some clearing houses go away is direct dynamic discovery of RADIUS servers as per https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ which can (but does not necessarily always) bypass central clearing house= s. In short: MAC addresses are NOT necessarily local to the LAN; if they leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols that transport information about MAC addresses on the layers above are most certainly IETF work. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------080506020901070405070303 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080506020901070405070303-- --rrG2DHdMLNfFradH5jBwvJUuhSgE7kNJc 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSzPWfAAoJEMDeajWKOdxmBDoP/2SQO/GPc85HDw9/3qXnZqZ5 pf/tTQbf7f/xQPYXFO3kv3FqVWejOFgzIyYf8o+6J0Hq7FhKKES1t5XwogczREEv U/6PyDNm15qMdwsIGsUYPNIlMtZNJvoc5hYR87VAM5jxjh52y+NDHd4Fml9jS9Sz WXA02sA8BaqVQBczEfiJZJ3c6THkfuurZYa2KjEWE1drMjhVdZp773dJtmyPulEy SFec7WBNqVuulw4iaTivlYDWDURvqKvSbJGs6ofMKHmAsbA4gSFaFQ5DO8Qph3rC oQvFg5pxhvr45nhBGUUI+cT/JynzOvKyGG5RkXwE8ZrKug5OZVsnEYtm6gqCVx9t AJKKYPaMqpAFZ+a2zijOOVWsEEnjDmgtGrwyucH8ecRuHEqiHGJx3icvAz96NVCf jo1AvRdINOMKXaWu/CGM0dTj/rPZNS4PnDSWyxWyLpCphW2EL8DXft2W51wsoV32 iKb2BKhjTVCpQyRKPFFU02HVPUecy2ifb5FKv5wkNsdy+PI9fxagViqx0SGGKyFr tal4BJ32gII+W+oCCp3GQG8sWhqhdn0GaE+eFhp9RFuaCbye6SRmMEg3SlEjfQci ZZw+SNgfc6Q+zBsH1i/HHi58ApjW+JGKLjBfWRsKjpZ0Auz7qUGwDEqp6nfrv1wz oJ9o+w7rYsDv4XylvJn/ =8pyN -----END PGP SIGNATURE----- --rrG2DHdMLNfFradH5jBwvJUuhSgE7kNJc-- From lear@cisco.com Tue Jan 7 23:00:24 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4921AE2F5 for ; Tue, 7 Jan 2014 23:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfzR1FP6OF3L for ; Tue, 7 Jan 2014 23:00:23 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF5D1AE2FB for ; Tue, 7 Jan 2014 23:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=399; q=dns/txt; s=iport; t=1389164414; x=1390374014; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0LdV6P2Pro81jGoepL7Q3dgbbKx07HvKtmPXPAWR4h4=; b=hM7kxKtJmDN0jy0UVzXTDRqN+Id9VP/2SUIM+WvtJR1qOHT2gV5VZBT1 Eo+tL/5+phP87Xza7PbMvk6Xc/0jhLUrTPst1J9mKqzCoxVVLBr6Xd0Do WrbhRL9f4NtVhb9vKfWLbegUEyU/xtWYwr8JhPAl9wy/jzcNP72Ffwj37 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEH3zFKQ/khL/2dsb2JhbABZgwuEC7Z5gQ8WdIIlAQEBAwEjVAEGCwsaAgUWCwICCQMCAQIBKxoGAQwIAQGHeAipcJpcF4EpjWOCb4FIAQOYF5IVgW+BPzs X-IronPort-AV: E=Sophos;i="4.95,622,1384300800"; d="scan'208";a="3320694" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 08 Jan 2014 06:59:54 +0000 Received: from mctiny.local ([10.61.211.253]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s086xrMA020454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 06:59:54 GMT Message-ID: <52CCF769.9080303@cisco.com> Date: Wed, 08 Jan 2014 07:59:53 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Winter , perpass@ietf.org References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> In-Reply-To: <52CCF598.3000605@restena.lu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 07:00:25 -0000 On 1/8/14 7:52 AM, Stefan Winter wrote: > In short: MAC addresses are NOT necessarily local to the LAN; if they > leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols > that transport information about MAC addresses on the layers above are > most certainly IETF work. > > Indeed. Mac addresses are also found in location registrations for some services. Eliot From TurnerS@ieca.com Wed Jan 8 00:08:39 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E85C1AE31C for ; Wed, 8 Jan 2014 00:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgNwAY5_Ypd6 for ; Wed, 8 Jan 2014 00:08:38 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.164.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A41AE321 for ; Wed, 8 Jan 2014 00:08:38 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 319843C29AC78; Wed, 8 Jan 2014 02:08:29 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 196933C29AC31 for ; Wed, 8 Jan 2014 02:08:29 -0600 (CST) Received: from [173.73.130.192] (port=53195 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W0oBg-0006dj-8z; Wed, 08 Jan 2014 02:08:28 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_BD7C77BE-2DB2-4125-98CC-FD9D9C0207DD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sean Turner In-Reply-To: <87lhys1cvj.fsf@nordberg.se> Date: Wed, 8 Jan 2014 03:08:25 -0500 Message-Id: References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <87lhys1cvj.fsf@nordberg.se> To: Linus Nordberg X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.130.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [173.73.130.192]:53195 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: Richard Barnes , Paul Lambert , perpass Subject: Re: [perpass] New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 08:08:39 -0000 --Apple-Mail=_BD7C77BE-2DB2-4125-98CC-FD9D9C0207DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 07, 2014, at 02:15, Linus Nordberg wrote: > Richard Barnes wrote > Mon, 6 Jan 2014 22:01:03 -0500: >=20 > | I also wonder to what degree this is a "pervasive attack" issue. If = the > | attack involves being physically close to the victim, it's hard to = see how > | the attacker would achieve a pervasive scale. >=20 > An attacker could control a large number of "home routers". >=20 > Do we need stronger indications that's actually being done at a large > scale before we consider strengthening L2 protocols and best = practices? > If so, what is "large scale" and "pervasive=94? I=92m in the camp that we don=92t. spt --Apple-Mail=_BD7C77BE-2DB2-4125-98CC-FD9D9C0207DD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDEwODA4MDgyNlowIwYJKoZIhvcNAQkEMRYEFCR6i4i8BmRaTsw/fw2e71P7 2X8FMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBXMb0M1Pvr3e8X7yffCm4ROkTG srX5LrMtZbciapJm6LUeWNddnt/nyELuwp7x5S6vBlitEdQvsndqc3daBMLalrF0wd86ZNctsZGK DQ/KtrcdKoIjJad+aGkj7oNyOXbDsQdRHHfL+TrCu8WzO5I6OtXK8F+AloN+tibyCr9D3w6z0arE VwGOSw0YRzbEDS1XcKxmFmefhE85yZF/uHdRKrn3CEglnKb5fGh5WYMUlfZfChw7KCyHqYWU2e4i PhD7KrZGMw70sTm5s81oIlaocl3Hs9Mzp7ZrAWf+UmO9Y90fha5yla7OwOy+gkeSDZOljrW8VkwC WoBF0oYplSJtAAAAAAAA --Apple-Mail=_BD7C77BE-2DB2-4125-98CC-FD9D9C0207DD-- From stephen.farrell@cs.tcd.ie Wed Jan 8 03:32:36 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E240B1AE1D7 for ; Wed, 8 Jan 2014 03:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX_xOo7_hNOR for ; Wed, 8 Jan 2014 03:32:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2D1AE2DC for ; Wed, 8 Jan 2014 03:32:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86238BE49; Wed, 8 Jan 2014 11:32:07 +0000 (GMT) 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 LQjkg19Wvg4w; Wed, 8 Jan 2014 11:32:07 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 67E62BE3F; Wed, 8 Jan 2014 11:32:07 +0000 (GMT) Message-ID: <52CD3737.7090903@cs.tcd.ie> Date: Wed, 08 Jan 2014 11:32:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eliot Lear , Stefan Winter , perpass@ietf.org References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> <52CCF769.9080303@cisco.com> In-Reply-To: <52CCF769.9080303@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:32:37 -0000 On 01/08/2014 06:59 AM, Eliot Lear wrote: > > On 1/8/14 7:52 AM, Stefan Winter wrote: > >> In short: MAC addresses are NOT necessarily local to the LAN; if they >> leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols >> that transport information about MAC addresses on the layers above are >> most certainly IETF work. >> >> > > Indeed. Mac addresses are also found in location registrations for some > services. And even, horribly, in the DNS [1] - which is one of those "better to document than ignore" things. S. [1] http://tools.ietf.org/html/rfc7043 > > Eliot > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From joelja@bogus.com Wed Jan 8 09:05:18 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736CD1AE005 for ; Wed, 8 Jan 2014 09:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0qX5AGJbUsA for ; Wed, 8 Jan 2014 09:05:17 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9EC1ADBD7 for ; Wed, 8 Jan 2014 09:05:17 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s08H4hpV055014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 17:04:44 GMT (envelope-from joelja@bogus.com) Message-ID: <52CD8528.9050704@bogus.com> Date: Wed, 08 Jan 2014 09:04:40 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Stephen Farrell , Eliot Lear , Stefan Winter , perpass@ietf.org References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> <52CCF769.9080303@cisco.com> <52CD3737.7090903@cs.tcd.ie> In-Reply-To: <52CD3737.7090903@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Aka1A8cSqXUJTxjiwN156FPOEPWg9ffGk" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Jan 2014 17:04:45 +0000 (UTC) Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:05:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Aka1A8cSqXUJTxjiwN156FPOEPWg9ffGk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/8/14, 3:32 AM, Stephen Farrell wrote: >=20 >=20 > On 01/08/2014 06:59 AM, Eliot Lear wrote: >> >> On 1/8/14 7:52 AM, Stefan Winter wrote: >> >>> In short: MAC addresses are NOT necessarily local to the LAN; if they= >>> leak beyond, privacy is at risk. The LAN may be IEEE's domain; protoc= ols >>> that transport information about MAC addresses on the layers above ar= e >>> most certainly IETF work. >>> >>> >> >> Indeed. Mac addresses are also found in location registrations for so= me >> services. >=20 > And even, horribly, in the DNS [1] - which is one of > those "better to document than ignore" things. In both cases the scope in which their appropriate to use is germaine. If you do layer-2 authentication or resource allocation it would seems likely that you would collect and store layer-2 identifiers for future use. DHCP servers do this also. Should this information (L2 binding to some upper layer information) be exposed to applications that don't need the L2 binding? I don't think so.= > S. >=20 > [1] http://tools.ietf.org/html/rfc7043 >=20 >> >> Eliot >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 --Aka1A8cSqXUJTxjiwN156FPOEPWg9ffGk 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLNhSgACgkQ8AA1q7Z/VrJfYQCfeFZsMfT8aoOR2Q5/cWCeaVpF 4tEAn0miU1owu4n+ZIORCdSsvtW1wrLB =mPiX -----END PGP SIGNATURE----- --Aka1A8cSqXUJTxjiwN156FPOEPWg9ffGk-- From martin.thomson@gmail.com Wed Jan 8 09:05:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48671ADFA0 for ; Wed, 8 Jan 2014 09:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgYjZNNvhp_U for ; Wed, 8 Jan 2014 09:05:23 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA71AE509 for ; Wed, 8 Jan 2014 09:05:22 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so1738406wes.31 for ; Wed, 08 Jan 2014 09:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rvFPThkjH/aahkn9q/yTDcN812W/1+nhYu5npTD6sAU=; b=UYvevpXmOFsT0lp0xIbxRCH+EIpVvo28eS0hA+xBKPuda24EeBS1diGnnrxpz/Vqcx qv7lkcrOtbUKIUL9zOHYFQdEL2i0VLwgluzAwkJLL2HygUTkf2W4s5FzJEI9ztXhXGh3 TcVdjB0zcUjatdcKCw7CLTO8OY+FqXZrlx4U4PTvTk0jxoASGkUppblWMh55U/7MWW4F liMPtOGRY3e84udpRBni1pdvD2vaKtC4hV7RQpE9S7iIxqSUlp/4pYRy8c5ON8RWNArb xExPd5rFIWq2JTVDDdKQk3IfgqplF+qw4s5Bqe9J4DKG7x5glAinUFj5TVi3L05huSIG g75Q== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr16628791wjb.28.1389200713165; Wed, 08 Jan 2014 09:05:13 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 8 Jan 2014 09:05:13 -0800 (PST) In-Reply-To: <52CCF769.9080303@cisco.com> References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> <52CCF769.9080303@cisco.com> Date: Wed, 8 Jan 2014 09:05:13 -0800 Message-ID: From: Martin Thomson To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Cc: Stefan Winter , perpass Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:05:26 -0000 On 7 January 2014 22:59, Eliot Lear wrote: > Indeed. Mac addresses are also found in location registrations for some > services. Some? Virtually all in fact. It's mostly due to the prevailing attitude in that community (likely others), that not sending something could represent a lost opportunity in the future where the cost of doing so is considered trivial. That cost assessment is one we need to influence if we're going to make any sort of real impact on this problem. And by we, I don't think that this is something the IETF can realistically do anything about, except by a sort of osmosis. Technically, there are no measures that can be deployed against that sort of meme. From paul@marvell.com Wed Jan 8 10:03:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F201ADFCA for ; Wed, 8 Jan 2014 10:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKHe7BlbNZQ4 for ; Wed, 8 Jan 2014 10:03:08 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC81AE088 for ; Wed, 8 Jan 2014 10:03:08 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s08I2wO4030759; Wed, 8 Jan 2014 10:02:58 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1h919r9qdw-47 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jan 2014 10:02:58 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 8 Jan 2014 10:02:57 -0800 From: Paul Lambert To: Eliot Lear , Stefan Winter , "perpass@ietf.org" Date: Wed, 8 Jan 2014 10:02:56 -0800 Thread-Topic: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt Thread-Index: Ac8Mm9xPGXGBnqaCQZyMehqtqIQYzA== Message-ID: References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> <52CCF769.9080303@cisco.com> In-Reply-To: <52CCF769.9080303@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-08_07:2014-01-07,2014-01-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080094 Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:03:09 -0000 On 1/7/14, 10:59 PM, "Eliot Lear" wrote: > >On 1/8/14 7:52 AM, Stefan Winter wrote: > >> In short: MAC addresses are NOT necessarily local to the LAN; if they >> leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols >> that transport information about MAC addresses on the layers above are >> most certainly IETF work. So =8A this year as we introduce =8Cephemeral MAC addresses=B9 into 802.11. The IETF should be prepared to fix upper layers as they break :-) The simplest change is for hourly or daily changes of a link local MAC address. This breaks the long term tracking and any usage of MAC address for authentication. Longer term, the ephemeral address could be bound to an authentication process. My favored key centric approach would be mac_address =3D h(pk, nonce)[:6] | 0x800000000000 # upper 6 octets with bitwise to set link local Paul >> >> > >Indeed. Mac addresses are also found in location registrations for some >services. > >Eliot >_______________________________________________ >perpass mailing list >perpass@ietf.org >https://www.ietf.org/mailman/listinfo/perpass From stefan.winter@restena.lu Wed Jan 8 22:53:47 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119F61AC862 for ; Wed, 8 Jan 2014 22:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7vyFlWp4a6h for ; Wed, 8 Jan 2014 22:53:44 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 456061A1F61 for ; Wed, 8 Jan 2014 22:53:44 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7112210583; Thu, 9 Jan 2014 07:53:34 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5EF131057E; Thu, 9 Jan 2014 07:53:34 +0100 (CET) Message-ID: <52CE4767.6000303@restena.lu> Date: Thu, 09 Jan 2014 07:53:27 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Lambert , Eliot Lear , "perpass@ietf.org" References: <20140107021702.7140.81609.idtracker@ietfa.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E1E4@SC-VEXCH2.marvell.com> <52CCF598.3000605@restena.lu> <52CCF769.9080303@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MO0J9b9o5HwcMux45jhnk4IElW6trwlvK" X-Virus-Scanned: ClamAV Subject: Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MO0J9b9o5HwcMux45jhnk4IElW6trwlvK Content-Type: multipart/mixed; boundary="------------070508030505030004020706" This is a multi-part message in MIME format. --------------070508030505030004020706 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > So =8A this year as we introduce =8Cephemeral MAC addresses=B9 into 802= =2E11. > The IETF should be prepared to fix upper layers as they break :-) >=20 > The simplest change is for hourly or daily changes of a link local MAC > address. What a wonderful idea. IEEE 802.1X authenticates sessions by MAC address. If you change it while you are in an authenticated session, you'll be kicked off the net instantly. > This breaks the long term tracking and any usage of MAC address for > authentication. >=20 > Longer term, the ephemeral address could be bound to an authentication > process. That is what IEEE 802.1X does today. It binds the current session, identified by MAC address, to a user identity, identified by an EAP credential. Its only requirement is that the MAC address remains unchanged during the session. However ephemeral the MAC address may be, it should survive a session, independent of the session duration. > My favored key centric approach would be >=20 > mac_address =3D h(pk, nonce)[:6] | 0x800000000000 # upper 6 octets with= > bitwise to set link local In eduroam, we do see people changing their MAC address *between* sessions, and that's know to work. I don't know or care about their algorithms. Their motivation is to get around "fair use" capping which some hotspots may have in place. Change MAC, change outer EAP identity, and you'll appear as a "brand new" user. That is one of the reasons why we introduced the use of Chargeable-User-Identity (CUI, RFC4372) for our authentications. CUI can be implemented in a way which prevents tracking (by hashing the CUI including the Operator-Name attribute, so that different hotspots get different CUIs for the same user). I think I can say with some confidence that RADIUS and EAP won't "break" if MAC addresses change. The change should happen in a sane moment though to avoid session disruption. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070508030505030004020706 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------070508030505030004020706-- --MO0J9b9o5HwcMux45jhnk4IElW6trwlvK 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSzkduAAoJEMDeajWKOdxmX3MQAICADL1jsfhp0QJqKOLIbYAt T2mGNPTQffvQ0heaTywnQ2orDVFre2r6XmrMFLqoXz0Rc+CGpb12SYvPNq9i98RO DNB1ZUFnhsY6siBbdoQGVvoeMcq2qHOW8nPfmvWXDEufkYrfnd92CXN32w/DNbCa Usr5200Pkfd3NfSrx9rR5QYq1SOEQVCKVoOeIgDuSJxUsdlcZx2maZAgtNaZ1gRA hZMHWKFGT0P/GG69IsOo+OMmVgJsbsqYwTI2EwTn63YBfmJ9D1KnoqqVO84I4YTm uUSaKSXWvJ/8sSuD9daxNkvhswvrQrcS+dgZP+salQ7D9WCWqLIFIB2CJFjPxG4/ PvI3COPFTa39ScQDT1aQJrtcereDFCXvLcgsru1j1NQhn7wfUrTVmEpDppmGttHJ YwxZl4bl35VvwP1PdRxEVIWuQ4n8aAHr0lgWpJS60nV4+IwIVRjOtObuzFkt9I0W QF+LOhIDV6sBbN0Ppvww+Ws0sl/Esrkpb4GT+9RAvAaQBtxSfs9FS+jbbvaYar+l UMrnCfYylLDqcojSWGkkUqJfh9RePwORFibJKMeOMjBIgfNKAtmr8o4UjmfE/DtK 3JDK/iKP8Ch/Cc37T5hrFHn+FSs4t85GSsxWwxGG1QvTRnWQ7lxt4NFGh6wK3P2Z kARj/4Oao/+v5WIi37At =/qpD -----END PGP SIGNATURE----- --MO0J9b9o5HwcMux45jhnk4IElW6trwlvK-- From stephen.farrell@cs.tcd.ie Thu Jan 9 04:18:25 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE281AE29C for ; Thu, 9 Jan 2014 04:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i5zCfS7bAGC for ; Thu, 9 Jan 2014 04:18:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC0181AE247 for ; Thu, 9 Jan 2014 04:18:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93D7CBE33; Thu, 9 Jan 2014 12:18:12 +0000 (GMT) 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 ip+nEduq-viv; Thu, 9 Jan 2014 12:18:12 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B379DBE51; Thu, 9 Jan 2014 12:18:11 +0000 (GMT) Message-ID: <52CE9383.8050006@cs.tcd.ie> Date: Thu, 09 Jan 2014 12:18:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass References: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> In-Reply-To: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel Subject: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:18:25 -0000 Hiya, See below. Adrian and I (the Farrelll twins, he seemingly can't spell it right:-) have cooked up an idea for MPLS opportunistic encryption. As he says, its very early days, but if this was something that MPLS folk wanted to implement, I think that'd be a fine thing. As of now, I've no real clue if they would or not, but Adrian I'm sure knows better. And as you can also see from the mail below, Adrian has already posted to the MPLS WG list, so comments about whether this is good or bad for MPLS etc are probably better handled on that list rather than here. So my question for this list is mainly to look for comments on how we've handled the opportunistic crypto thing, especially from the pov of whether that's something that could be copied in other protocols. The meaty bit of that is really section 4.2 of the draft which is quite short. One particular question to consider is whether or not a generic MITM-detection protocol for OE-using protocols might be interesting or better/worse than the idea of having each protocol define ways in which you might post-facto catch a MITM. Section 2 of the draft has some introductory text about OE. I'd also be interested in comments on that but as our draft says, we expect that to be superseded by a more generic OE draft. (I know that Steve Kent is working on one like that, and maybe others are too.) So your comments on that might really end up improving some other draft and not this one, but that's fine. Thanks, S. -------- Original Message -------- Subject: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt Date: Thu, 9 Jan 2014 11:51:03 -0000 From: Adrian Farrel Reply-To: To: CC: Hi MPLS working group, Stephen and I have been looking at MPLS data plane security and wondering whether anything could be done to help protect against various types of bulk surveillance achieved by tapping entire links without requiring full and management-heavy establishment of security associations. This I-D is very rough! it is a first attempt to show what might be achieved. We are confident that there are problems with what we have suggested both from a security and an MPLS perspective. Your thoughts and comments are encouraged. Thanks, The Farrel twins. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 09 January 2014 11:44 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Opportunistic Encryption in MPLS Networks > Authors : Adrian Farrel > Stephen Farrell > Filename : draft-farrelll-mpls-opportunistic-encrypt-00.txt > Pages : 22 > Date : 2014-01-09 > > Abstract: > This document describes a way to apply opportunistic encryption > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be exchanged > to enable the encryption, and indicates how key identifiers are > exchanged in encrypted MPLS packets. Finally, this document > describes the applicability of opportunistic encryption in MPLS > networks with an indication of the level of improved security as well > as the continued vulnerabilities. > > This document does not describe security for MPLS control plane > protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-encrypt/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stephen.farrell@cs.tcd.ie Thu Jan 9 05:56:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11671AE303 for ; Thu, 9 Jan 2014 05:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.438 X-Spam-Level: X-Spam-Status: No, score=-4.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxjqGDC6GrYk for ; Thu, 9 Jan 2014 05:56:08 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96F1AE2F8 for ; Thu, 9 Jan 2014 05:56:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52648BE47 for ; Thu, 9 Jan 2014 13:55:58 +0000 (GMT) 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 airW37K3aW5T for ; Thu, 9 Jan 2014 13:55:58 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8CF31BE51 for ; Thu, 9 Jan 2014 13:55:57 +0000 (GMT) Message-ID: <52CEAA6D.6020207@cs.tcd.ie> Date: Thu, 09 Jan 2014 13:55:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass References: <2CD9CC27-4F4E-4BBF-B428-768A23D82B79@iab.org> In-Reply-To: <2CD9CC27-4F4E-4BBF-B428-768A23D82B79@iab.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:56:10 -0000 Folks, submissions are starting to roll in so this is a reminder to send yours by Jan 15. We'll be posting more logistics next week(-ish) as well in case you're wondering. Thanks, S. -------- Original Message -------- Subject: W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT) Date: Sun, 1 Dec 2013 10:48:15 -0500 From: IAB Chair To: IETF Announce CC: IAB , IETF W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT) ====================================== Logistics/Dates: Submissions due: Jan 15 2014 Invitations issued: Jan 31 2014 Workshop Date: Feb 28 (pm) & Mar 1 (am) 2014 To be Confirmed - could be all day Mar 1 Location: Central London, UK. IETF Hotel or nearby (TBC) For queries, contact: stephen.farrell@cs.tcd.ie, tech@strews.eu Send submissions to: group-strint-submission@w3.org Workshop web site: http://www.w3.org/2014/strint/ The Vancouver IETF plenary concluded that pervasive monitoring represents an attack on the Internet, and the IETF has begun to carry out various of the more obvious actions [1] required to try to handle this attack. However, there are additional much more complex questions arising that need further consideration before any additional concrete plans can be made. The W3C and IAB will therefore host a one-day workshop on the topic of "Strengthening the Internet Against Pervasive Monitoring" before IETF-89 in London in March 2014, with support from the EU FP7 STREWS [2] project. Pervasive monitoring targets protocol data that we also need for network manageability and security. This data is captured and correlated with other data. There is an open problem as to how to enhance protocols so as to maintain network manageability and security but still limit data capture and correlation. The overall goal of the workshop is to steer IETF and W3C work so as to be able to improve or "strengthen" the Internet in the face of pervasive monitoring. A workshop report in the form of an IAB RFC will be produced after the event. Technical questions for the workshop include: - What are the pervasive monitoring threat models, and what is their effect on web and Internet protocol security and privacy? - What is needed so that web developers can better consider the pervasive monitoring context? - How are WebRTC and IoT impacted, and how can they be better protected? Are other key Internet and web technologies potentially impacted? - What gaps exist in current tool sets and operational best practices that could address some of these potential impacts? - What trade-offs exist between strengthening measures, (e.g. more encryption) and performance, operational or network management issues? - How do we guard against pervasive monitoring while maintaining network manageability? - Can lower layer changes (e.g., to IPv6, LISP, MPLS) or additions to overlay networks help? - How realistic is it to not be fingerprintable on the web and Internet? - How can W3C, the IETF and the IRTF better deal with new cryptographic algorithm proposals in future? - What are the practical benefits and limits of "opportunistic encryption"? - Can we deploy end-to-end crypto for email, SIP, the web, all TCP applications or other applications so that we mitigate pervasive monitoring usefully? - How might pervasive monitoring take form or be addressed in embedded systems or different industrial verticals? - How do we reconcile caching, proxies and other intermediaries with end-to-end encryption? - Can we obfuscate metadata with less overhead than TOR? - Considering meta-data: are there relevant differences between protocol artefacts, message sizes and patterns and payloads? Position papers (maximum of 5 pages using 10pt font or any length Internet-Drafts) from academia, industry and others that focus on the broader picture and that warrant the kind of extended discussion that a full day workshop offers are the most welcome. Papers that reflect experience based on running code and deployed services are also very welcome. Papers that are proposals for point-solutions are less useful in this context, and can simply be submitted as Internet-Drafts and discussed on relevant IETF or W3C lists, e.g. the IETF perpass list. [3] The workshop will be by invitation only. Those wishing to attend should submit a position paper or Internet-Draft. All inputs submitted and considered relevant will be published on the workshop web page. The organisers (STREWS project participants, IAB and W3C staff) will decide whom to invite based on the submissions received. Sessions will be organized according to content, and not every accepted submission or invited attendee will have an opportunity to present as the intent is to foster discussion and not simply to have a sequence of presentations. [1] http://down.dsg.cs.tcd.ie/misc/perpass.txt [2] http://www.strews.eu/ [3] https://www.ietf.org/mailman/listinfo/perpass From watsonbladd@gmail.com Fri Jan 10 08:42:52 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0911AE0D9 for ; Fri, 10 Jan 2014 08:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZPyOAxujtHl for ; Fri, 10 Jan 2014 08:42:49 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 72FED1ACCE2 for ; Fri, 10 Jan 2014 08:42:49 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bz8so5083917wib.11 for ; Fri, 10 Jan 2014 08:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+oSKtuqJVFMVJm3OOo3Qs7JXh/lnI0MZq/K3r4GA6cs=; b=xBM6E1F57i9xVwOOlZMaQAESOrA6MMQO5en8kc5mRBgBtthPXKsGLk5Ah2Tcj8mG1S 7w2U91261rLSTYFamvhZg9u25YM1bHw4wSISagt/ODD0+D9qX0lDvfnDuZOdyF6xs1fG +gDvs7nEw3iLMA68foACdnknLANh4ATynVR5FzYm38q9cYEKl5gjys2mggTNTzfp0G0T a0FK8mHnjSJOcjomeOZt8LgxGFZbkyAfbdtsaVhffBbhj2E7PUgibCd2+Mi4Mi0CYgIc wKh3ug9WimrCBtT9RERtTldJalrpyNT394uKWI09qU/OpMbMqtuqQppTMh1DAxfEUnm6 WzAQ== MIME-Version: 1.0 X-Received: by 10.180.149.175 with SMTP id ub15mr3652202wib.44.1389372158985; Fri, 10 Jan 2014 08:42:38 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 10 Jan 2014 08:42:38 -0800 (PST) In-Reply-To: <52CE9383.8050006@cs.tcd.ie> References: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> <52CE9383.8050006@cs.tcd.ie> Date: Fri, 10 Jan 2014 08:42:38 -0800 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: Adrian Farrel , perpass Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:42:52 -0000 On Thu, Jan 9, 2014 at 4:18 AM, Stephen Farrell wrote: > > Hiya, > > See below. Adrian and I (the Farrelll twins, he seemingly can't > spell it right:-) have cooked up an idea for MPLS opportunistic > encryption. As he says, its very early days, but if this was > something that MPLS folk wanted to implement, I think that'd be > a fine thing. As of now, I've no real clue if they would or not, > but Adrian I'm sure knows better. And as you can also see from > the mail below, Adrian has already posted to the MPLS WG list, > so comments about whether this is good or bad for MPLS etc are > probably better handled on that list rather than here. > > So my question for this list is mainly to look for comments > on how we've handled the opportunistic crypto thing, especially > from the pov of whether that's something that could be copied > in other protocols. The meaty bit of that is really section > 4.2 of the draft which is quite short. I think prime field elliptic curves would be more amenable to implementation in restricted router hardware. How the receiver computes the nonce that goes with the packet is not obvious to me from what is written. Otherwise this seems reasonable: it might be worth considering if this can be extended to authenticate both sides cleanly if some large networks want to be safe against that. > > One particular question to consider is whether or not a > generic MITM-detection protocol for OE-using protocols might > be interesting or better/worse than the idea of having each > protocol define ways in which you might post-facto catch a MITM. > > Section 2 of the draft has some introductory text about OE. I'd > also be interested in comments on that but as our draft says, we > expect that to be superseded by a more generic OE draft. (I know > that Steve Kent is working on one like that, and maybe others are > too.) So your comments on that might really end up improving > some other draft and not this one, but that's fine. > > Thanks, > S. > > > > -------- Original Message -------- > Subject: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt > Date: Thu, 9 Jan 2014 11:51:03 -0000 > From: Adrian Farrel > Reply-To: > To: > CC: > > Hi MPLS working group, > > Stephen and I have been looking at MPLS data plane security and wondering > whether anything could be done to help protect against various types of bulk > surveillance achieved by tapping entire links without requiring full and > management-heavy establishment of security associations. > > This I-D is very rough! it is a first attempt to show what might be > achieved. We > are confident that there are problems with what we have suggested both > from a > security and an MPLS perspective. Your thoughts and comments are encouraged. > > Thanks, > The Farrel twins. > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: 09 January 2014 11:44 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : Opportunistic Encryption in MPLS Networks >> Authors : Adrian Farrel >> Stephen Farrell >> Filename : draft-farrelll-mpls-opportunistic-encrypt-00.txt >> Pages : 22 >> Date : 2014-01-09 >> >> Abstract: >> This document describes a way to apply opportunistic encryption >> between adjacent nodes on an MPLS Label Switched Path (LSP) or >> between end points of an LSP. It explains how keys may be exchanged >> to enable the encryption, and indicates how key identifiers are >> exchanged in encrypted MPLS packets. Finally, this document >> describes the applicability of opportunistic encryption in MPLS >> networks with an indication of the level of improved security as well >> as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-encrypt/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From stephen.farrell@cs.tcd.ie Fri Jan 10 09:21:56 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA551ADF30 for ; Fri, 10 Jan 2014 09:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X84Qb0x9OV3s for ; Fri, 10 Jan 2014 09:21:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 460D61AE143 for ; Fri, 10 Jan 2014 09:21:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5CFDBE5F; Fri, 10 Jan 2014 17:21:43 +0000 (GMT) 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 iJUFFO-JmAb1; Fri, 10 Jan 2014 17:21:43 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5253ABE5C; Fri, 10 Jan 2014 17:21:43 +0000 (GMT) Message-ID: <52D02C27.8050009@cs.tcd.ie> Date: Fri, 10 Jan 2014 17:21:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Watson Ladd References: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> <52CE9383.8050006@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , perpass Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:21:57 -0000 Hiya, On 01/10/2014 04:42 PM, Watson Ladd wrote: > I think prime field elliptic curves would be more amenable to > implementation in restricted router > hardware. Could be. If this doesn't turn out to be DOA then I'd fully expect a bunch of discussion on that. For now, we just picked MODP to avoid having to worry about IPR FUDdiness. > How the receiver computes the nonce that goes with the packet is not > obvious to me from > what is written. Oops. Needs a fix:-) > Otherwise this seems reasonable: it might be worth considering if this > can be extended to > authenticate both sides cleanly if some large networks want to be safe > against that. Not sure what you mean by cleanly? Thanks for the comments, S. From watsonbladd@gmail.com Fri Jan 10 09:27:48 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D71ADFB9 for ; Fri, 10 Jan 2014 09:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-oIaxiO0SY for ; Fri, 10 Jan 2014 09:27:47 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B77D31ADF7D for ; Fri, 10 Jan 2014 09:27:46 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so4438976wes.27 for ; Fri, 10 Jan 2014 09:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=usXwnaoxGLgC+mVAM09tpWk4TZsPMgaxyV1YSrAD5dM=; b=F7iTrxYQ2QmnQAArFABCd9xOprd22KlztKFSfE1ZF+sZE1oj259thawnqf+tltO6Uu pN3WL3+2HU2buXpW/N5lcdGRM91hWVZ0/orPZ+ktdlzw6sKD29aRt9QBdw/DCCyBGjbH LBacq7NKwBqxPjIa5TkFH5Ja6XsW9OpWSC5CY/t/IL2voLTaOnJdbn3FQxUG6J/10h4x nBNW+7b/uz2oVvWriojqC88DxqGJl+/8wg5E8dcvf+YaGvVdxrPkHXIHW67KqczaPlBr cuZrc61lenWFQCzens3v7nJjQu76A0uEkuPYZG0XSgiXxtJWxg3GAw0E05gNSS0qQrDQ vh1A== MIME-Version: 1.0 X-Received: by 10.194.189.132 with SMTP id gi4mr9730386wjc.5.1389374856259; Fri, 10 Jan 2014 09:27:36 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 10 Jan 2014 09:27:36 -0800 (PST) In-Reply-To: <52D02C27.8050009@cs.tcd.ie> References: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> <52CE9383.8050006@cs.tcd.ie> <52D02C27.8050009@cs.tcd.ie> Date: Fri, 10 Jan 2014 09:27:36 -0800 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: Adrian Farrel , perpass Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:27:48 -0000 On Fri, Jan 10, 2014 at 9:21 AM, Stephen Farrell wrote: > > Hiya, > > >> Otherwise this seems reasonable: it might be worth considering if this >> can be extended to >> authenticate both sides cleanly if some large networks want to be safe >> against that. > > Not sure what you mean by cleanly? By cleanly I mean if authentication is configured, it works, if not, we wind up with OE without too much in the way of complexity. This might be a bridge too far, but I wouldn't be surprised if some people were concerned about false termination in the middle of their MLPS networks induced by malicious configuration. > > Thanks for the comments, > S. > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From yaronf.ietf@gmail.com Fri Jan 10 13:14:50 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416B1AE12A for ; Fri, 10 Jan 2014 13:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbvIuN_J7GvM for ; Fri, 10 Jan 2014 13:14:48 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE831AE1BC for ; Fri, 10 Jan 2014 13:14:48 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id b57so2139285eek.40 for ; Fri, 10 Jan 2014 13:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UB4bt2jVr1qebXBiR2FgYjr0tFEIPVWjz4VEVeUF5HA=; b=BjhFZ3oAweAOWTk7uJlvDLBpd8U+kJSWhmXmY4ViQvU0tqfdgDTOp66b5ENhfALxeI oZynpEa24tapNL3EIeP1cSi8N4+5pSrh7FE8jpJhfvN11HWNAc+QNyQWYQpYcmM8Nzxs eFLkHOee7DMfCf2kKraAVf3wab+bdvf3Oxv3phMEalqMxIIdGcCRnZtVf7OD5A906bXW VSPOOdj8KlEYVR4RUYIXyoaXB28LGeLWuptMOo1XRWtA13dhOm6MBlFShsikZEHPtyAW J1Ixu8j6gD2DK2vgQGQvgJKc6M7q+UYE/VOb2f4b27zqxfSJ2FLFcnL7NXG+Bg2w8GOn G4Jw== X-Received: by 10.15.31.196 with SMTP id y44mr12101459eeu.96.1389388478097; Fri, 10 Jan 2014 13:14:38 -0800 (PST) Received: from [10.0.0.6] (bzq-79-183-21-20.red.bezeqint.net. [79.183.21.20]) by mx.google.com with ESMTPSA id l4sm17632860een.13.2014.01.10.13.14.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 13:14:37 -0800 (PST) Message-ID: <52D062BB.1030906@gmail.com> Date: Fri, 10 Jan 2014 23:14:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org, Stephen Farrell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:14:50 -0000 Hi Stephen, I haven't read the protocol yet (although I must say Sec. 4.3 worries me, it reminds me of the renegotiation vulnerability), but: - I understand MPLS traffic is often protected at a higher layer by IPsec. If we had a good opportunistic solution for IKE/IPsec, it could also cover this use case. And we know people are working on such solutions. [Here, that's me and my little turf war]. - But even at layer 2, there are existing solutions like WPA or MacSec. Can none of them be used (or extended) for this use case and do we really have to develop both the bulk encryption and key exchange from scratch? Sorry to be such a spoilsport. Thanks, Yaron From stephen.farrell@cs.tcd.ie Fri Jan 10 14:00:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8861AE20D for ; Fri, 10 Jan 2014 14:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC89R7TML2kP for ; Fri, 10 Jan 2014 14:00:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 95D3E1AE20B for ; Fri, 10 Jan 2014 14:00:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9E6E0BE47; Fri, 10 Jan 2014 22:00:04 +0000 (GMT) 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 jJkawGsfdzAl; Fri, 10 Jan 2014 22:00:03 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.44.74.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 331F1BE3F; Fri, 10 Jan 2014 22:00:03 +0000 (GMT) Message-ID: <52D06D63.7070900@cs.tcd.ie> Date: Fri, 10 Jan 2014 22:00:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yaron Sheffer , perpass@ietf.org References: <52D062BB.1030906@gmail.com> In-Reply-To: <52D062BB.1030906@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:00:17 -0000 Hiya, On 01/10/2014 09:14 PM, Yaron Sheffer wrote: > Hi Stephen, > > I haven't read the protocol yet (although I must say Sec. 4.3 worries > me, it reminds me of the renegotiation vulnerability), but: > > - I understand MPLS traffic is often protected at a higher layer by > IPsec. If we had a good opportunistic solution for IKE/IPsec, it could > also cover this use case. And we know people are working on such > solutions. [Here, that's me and my little turf war]. I think opportunistic IPsec could certainly help yes. I'm not sure if this use-case is being considered in that work. > - But even at layer 2, there are existing solutions like WPA or MacSec. > Can none of them be used (or extended) for this use case and do we > really have to develop both the bulk encryption and key exchange from > scratch? And that too. However, my understanding of MPLS is that basically neither IPsec nor layer 2 crypto are used in many or possibly most cases. My hope, (and I'd not put it stronger than that for now), is that this might be a another useful tool in the tool-box that could have a better chance of being deployed if we develop it with together with MPLS folks who'd like such a tool. Though I'm sure there'll be MPLS and other folks who hate the idea as well, we'll see. Overall, my goal is to get some crypto that's deployable for protecting MPLS traffic and I'm not fussed whether that means re-using a flavour of IPsec nor some L2 stuff from elsewhere, nor whether it turns out that we need to re-do some things in a way that works better for our "customers" as in the proposal here. Separately, if we (being the IETF as a whole), are going to end up adding opportunistic crypto to various protocols then I think we could do with some practice, and I'm happy to get beaten up offering up the 1st instance of text like that. But each time someone does that the questions you ask should also be asked. > Sorry to be such a spoilsport. You're not. Those are good questions and it'd not be the first time I'd barked up the wrong tree, if that's the case here which is quite possible. Cheers, S. > > Thanks, > Yaron > From paul@cypherpunks.ca Fri Jan 10 15:48:36 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40FB1ACC8A for ; Fri, 10 Jan 2014 15:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUt35V5cy-bJ for ; Fri, 10 Jan 2014 15:48:35 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF11AD8C4 for ; Fri, 10 Jan 2014 15:48:33 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D73A0800A1; Fri, 10 Jan 2014 18:48:22 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0ANmLbU020857; Fri, 10 Jan 2014 18:48:22 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 10 Jan 2014 18:48:21 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Stephen Farrell In-Reply-To: <52D06D63.7070900@cs.tcd.ie> Message-ID: References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Yaron Sheffer , perpass@ietf.org Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 23:48:37 -0000 On Fri, 10 Jan 2014, Stephen Farrell wrote: >> - I understand MPLS traffic is often protected at a higher layer by >> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could >> also cover this use case. And we know people are working on such >> solutions. [Here, that's me and my little turf war]. > > I think opportunistic IPsec could certainly help yes. I'm not > sure if this use-case is being considered in that work. Any non host-host case is very hard, as there is no way to verify any claims for random subnets of the internet. AFAIK, no good methods exist that any OE IPsec could use for auto-configuration. There is quite a difference between "here is plaintext from you to Bob, encrypt it" and "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory". > However, my understanding of MPLS is that basically neither IPsec > nor layer 2 crypto are used in many or possibly most cases. I was probably naively hoping that people would consider MPLS as much "outside" their network as the rest of the internet, and already have deployed static IPsec between those networks. But I guess not.... Paul From leifj@mnt.se Fri Jan 10 16:32:36 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55721A8034 for ; Fri, 10 Jan 2014 16:32:36 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCR-YOui-jNa for ; Fri, 10 Jan 2014 16:32:33 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31B1A1F4C for ; Fri, 10 Jan 2014 16:32:32 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so2017365lan.32 for ; Fri, 10 Jan 2014 16:32:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rFghg4tL39Y/N0yAjbynB8aDdf2sQqnexYhebNBXbdU=; b=QIbLD7Utwm4TzUK8k2CKoSVXDHyJ3nDURVSmlW6mPc9jl2UufPpoUdBRqCtZcGHXt4 UTBiPzUyFo48Wc/Iy7qEyjFSg2Af7ast5ShEIIiUL+BsXkvzhlef8pU6UNiY5OSXMc65 riEsnr2StbFRZxOjLd5tp1aykqhz7wCz3XMioCq7nCom452iTtVGACi7aIRitn1dRNt7 l/mrEaEgbIjZ/Xzng8FZdBHOI4/dJY/N8Q43pCHciTfxBEFzEwq8StuKnesDDmGir5Dw UnaGK9JPCwZllZGlnq7fwRB1ms8pYYJUikdhpicOopCsHgSBgeBtiNkWYZWsmM6P55CX UR9A== X-Gm-Message-State: ALoCoQmLAE7VygicLyCmPjKTGeBd6PVvNTGCgueMuShJ9EzWveCNWQPSgiBqm0shGQJOohgnsagA X-Received: by 10.112.180.37 with SMTP id dl5mr4706368lbc.58.1389400339532; Fri, 10 Jan 2014 16:32:19 -0800 (PST) Received: from [10.0.0.159] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id c15sm4385263lbq.11.2014.01.10.16.32.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 16:32:18 -0800 (PST) Message-ID: <52D09111.7010009@mnt.se> Date: Sat, 11 Jan 2014 01:32:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52D062BB.1030906@gmail.com> In-Reply-To: <52D062BB.1030906@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 00:32:36 -0000 On 2014-01-10 22:14, Yaron Sheffer wrote: > Hi Stephen, > > I haven't read the protocol yet (although I must say Sec. 4.3 worries > me, it reminds me of the renegotiation vulnerability), but: > > - I understand MPLS traffic is often protected at a higher layer by > IPsec. If we had a good opportunistic I don't think that’s true at all in real-world deployments. > solution for IKE/IPsec, it could also cover this use case. And we know > people are working on such solutions. [Here, that's me and my little > turf war]. > > - But even at layer 2, there are existing solutions like WPA or > MacSec. Can none of them be used (or extended) for this use case and > do we really have to develop both the bulk encryption and key exchange > from scratch? Sorry to be such a spoilsport. > > Thanks, > Yaron > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From yaronf.ietf@gmail.com Sat Jan 11 10:19:30 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391171AE0C0 for ; Sat, 11 Jan 2014 10:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmeXhwjUecMh for ; Sat, 11 Jan 2014 10:19:28 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6431AE0BB for ; Sat, 11 Jan 2014 10:19:28 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id e51so2021381eek.41 for ; Sat, 11 Jan 2014 10:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gpPzal2/LOld2nt5k7TGafqBQH5mcAB+XnmzRQzrYRo=; b=mK7KHwc1zqv0C+MfSPfrjJ6vnRcTMlzjSsSG+ol0gKNX43en+BW6Q5E5HjxSv1XZCk yJYK56GMrNiPOB2QQBF7Xe1ujqVe6txgHpwmJchKdKBJjix82wGpua9i559kWOxeHANX 7mnNf3Dnuz2L2yKBSLI2psP5hYKVi9BXkxPLECZKXCzy8ZjUMtVPFb3NNPUYytbE9xIH gHosN9ZA+uRSfCPzzFkWvM0C3fCdf2A7HPpgZ9PkhX7rEKThTR/EmWw9/qtWW83iJOUd iVFONXftx4/Jb7o/DpqsAb+kQpjCIN5hQtPZL1qTbyD9PmrJeOyRRuAue7DN7GKG/vE9 3LGw== X-Received: by 10.14.32.132 with SMTP id o4mr17566409eea.14.1389464322798; Sat, 11 Jan 2014 10:18:42 -0800 (PST) Received: from [10.0.0.9] (cablep-219-63-169.cablep.bezeqint.net. [62.219.63.169]) by mx.google.com with ESMTPSA id j46sm24775519eew.18.2014.01.11.10.18.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 10:18:42 -0800 (PST) Message-ID: <52D18B01.4040903@gmail.com> Date: Sat, 11 Jan 2014 20:18:41 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Wouters , Stephen Farrell References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 18:19:30 -0000 > On Fri, 10 Jan 2014, Stephen Farrell wrote: > >>> - I understand MPLS traffic is often protected at a higher layer by >>> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could >>> also cover this use case. And we know people are working on such >>> solutions. [Here, that's me and my little turf war]. >> >> I think opportunistic IPsec could certainly help yes. I'm not >> sure if this use-case is being considered in that work. > > Any non host-host case is very hard, as there is no way to verify any > claims for random subnets of the internet. AFAIK, no good methods exist > that any OE IPsec could use for auto-configuration. There is quite a > difference between "here is plaintext from you to Bob, encrypt it" and > "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory". > This is different from the normal IPsec OE scenario, and as a result may be easier to solve: - The MPLS peer is already willing to send any traffic from the private network to the other peer, which it sincerely hopes is not a MITM. - Each peer is typically running on an edge router (I believe) and so has much more awareness of the network than your typical IPsec OE peer. They will actually have the BGP information. Thanks, Yaron From kent@bbn.com Mon Jan 13 07:58:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9023F1AE04F for ; Mon, 13 Jan 2014 07:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqCbjBe3m9-X for ; Mon, 13 Jan 2014 07:58:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 965FA1ADF53 for ; Mon, 13 Jan 2014 07:58:26 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:59479 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W2ju3-000NPa-3L for perpass@ietf.org; Mon, 13 Jan 2014 10:58:15 -0500 Message-ID: <52D40D16.7060307@bbn.com> Date: Mon, 13 Jan 2014 10:58:14 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> In-Reply-To: <52D06D63.7070900@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:58:27 -0000 Stephen, > I think opportunistic IPsec could certainly help yes. I'm not sure if > this use-case is being considered in that work. I think it out to be. Experience has shown that getting all of the details right for a layer 3 security protocol is hard. BTW, MPLS is (lower) layer 3, not layer 2. >> - But even at layer 2, there are existing solutions like WPA or MacSec. >> Can none of them be used (or extended) for this use case and do we >> really have to develop both the bulk encryption and key exchange from >> scratch? > And that too. > > However, my understanding of MPLS is that basically neither IPsec > nor layer 2 crypto are used in many or possibly most cases. My hope, > (and I'd not put it stronger than that for now), is that this might > be a another useful tool in the tool-box that could have a better > chance of being deployed if we develop it with together with MPLS > folks who'd like such a tool. Though I'm sure there'll be MPLS > and other folks who hate the idea as well, we'll see. I suspect you're right that IPsec is not used often in this context. The use of MPLS would be qualitatively different, because it would be offered by an ISP, not by a subscriber. Maybe that would result in more encrypted traffic because ISPs would offer it as a low cost service. > Overall, my goal is to get some crypto that's deployable for > protecting MPLS traffic and I'm not fussed whether that means > re-using a flavour of IPsec nor some L2 stuff from elsewhere, nor > whether it turns out that we need to re-do some things in a way that > works better for our "customers" as in the proposal here. L2 stuff won't work across AS boundaries, unless the MPLS tunnel crosses those boundaries. From tytso@thunk.org Mon Jan 13 08:14:06 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D91AC4A7 for ; Mon, 13 Jan 2014 08:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv5_jgOynp3j for ; Mon, 13 Jan 2014 08:14:04 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id B56BB1ADF78 for ; Mon, 13 Jan 2014 08:14:03 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1W2k98-0006Yt-ED; Mon, 13 Jan 2014 16:13:50 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id BD2BE5801DE; Mon, 13 Jan 2014 11:13:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1389629629; bh=Ebpc5MtmVYiwVMRaploCjYGTq9dNeOdXyaG/DDNJsgY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BFKjtesHiPgP7Jmjocf5iZlEeeRWZPDRi6D/2/w2en2GgkwgtaKcaY8FjXQFMA0gk MSa7knPbgM0EKdEYH7gPkv+wovtxnMvvOlwdvMYHEg/nirSuMsqQ7tA/8j/QFX/fL5 nRoFNOWa3A0cUy/tRa1fRcTu06zeJwn0uuyZbqUI= Date: Mon, 13 Jan 2014 11:13:49 -0500 From: Theodore Ts'o To: Stephen Kent Message-ID: <20140113161349.GA22541@thunk.org> References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D40D16.7060307@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D40D16.7060307@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: perpass@ietf.org Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:14:06 -0000 On Mon, Jan 13, 2014 at 10:58:14AM -0500, Stephen Kent wrote: > I suspect you're right that IPsec is not used often in this context. > The use of MPLS would be qualitatively different, because it would > be offered by an ISP, not by a subscriber. Maybe that would result > in more encrypted traffic because ISPs would offer it as a low > cost service. It helps against some attacks, but it doesn't help for others, right? After all, if you are a US national, you might not trust that the Chinese Telecom won't pass your traffic to the MSS. (Or if you are a German national, that AT&T won't decrypto your traffic and then pass it off to the NSA...) - Ted From kent@bbn.com Mon Jan 13 08:53:49 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4001ADFDD for ; Mon, 13 Jan 2014 08:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGVkzLU8Rid2 for ; Mon, 13 Jan 2014 08:53:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06F7E1ADFD4 for ; Mon, 13 Jan 2014 08:53:48 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41106 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W2klX-0005dT-Cn; Mon, 13 Jan 2014 11:53:31 -0500 Message-ID: <52D41A06.2000008@bbn.com> Date: Mon, 13 Jan 2014 11:53:26 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Theodore Ts'o References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D40D16.7060307@bbn.com> <20140113161349.GA22541@thunk.org> In-Reply-To: <20140113161349.GA22541@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:53:50 -0000 Ted, > On Mon, Jan 13, 2014 at 10:58:14AM -0500, Stephen Kent wrote: >> I suspect you're right that IPsec is not used often in this context. >> The use of MPLS would be qualitatively different, because it would >> be offered by an ISP, not by a subscriber. Maybe that would result >> in more encrypted traffic because ISPs would offer it as a low >> cost service. > It helps against some attacks, but it doesn't help for others, right? > After all, if you are a US national, you might not trust that the > Chinese Telecom won't pass your traffic to the MSS. (Or if you are a > German national, that AT&T won't decrypto your traffic and then pass > it off to the NSA...) yep. IPsec, under the control of a subscriber, offers more protection, in princple. Steve From tytso@thunk.org Mon Jan 13 14:39:34 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71901A1F4E for ; Mon, 13 Jan 2014 14:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enq6Hut6ZmYN for ; Mon, 13 Jan 2014 14:39:33 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 735BF1A1F1B for ; Mon, 13 Jan 2014 14:39:33 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1W2qAD-0000jQ-8u; Mon, 13 Jan 2014 22:39:21 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 02604580309; Mon, 13 Jan 2014 13:53:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1389639231; bh=ngg93BS0E0g6JaVtJnw+iDl/rXosNupWwyjE1JdXXdM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qx1DAkHvfyPpfVb7bde+oQI7I/TJRY6ITKv+i0ijcB0lTUGkahHp/8uT/QqbkgJMQ cGKnIGu0EoFiGWqEc4mT2bxBCSGwx9dYwQBsLFEF5coK9n0DzOTk2A3rTkxvdzU1nZ j4N9fypn2XG6SP79PJt08xa0X+9HrLGVQxaAIMhc= Date: Mon, 13 Jan 2014 13:53:50 -0500 From: Theodore Ts'o To: Stephen Kent Message-ID: <20140113185350.GA23463@thunk.org> References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D40D16.7060307@bbn.com> <20140113161349.GA22541@thunk.org> <52D41A06.2000008@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D41A06.2000008@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: perpass@ietf.org Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:39:35 -0000 On Mon, Jan 13, 2014 at 11:53:26AM -0500, Stephen Kent wrote: > >It helps against some attacks, but it doesn't help for others, right? > >After all, if you are a US national, you might not trust that the > >Chinese Telecom won't pass your traffic to the MSS. (Or if you are a > >German national, that AT&T won't decrypto your traffic and then pass > >it off to the NSA...) > yep. IPsec, under the control of a subscriber, offers more protection, > in princple. Or put another way, MPLS-mediated encryption violates the end-to-end principle. It also allows ISP's to violate net neutrality principles as well (i.e., by allowing them to do deep packet inspection and then prioritizing some traffic over others). - Ted From kent@bbn.com Mon Jan 13 16:19:12 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93A91AE1DB for ; Mon, 13 Jan 2014 16:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkfs9Bsz-Q6s for ; Mon, 13 Jan 2014 16:19:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3E21A8033 for ; Mon, 13 Jan 2014 16:19:09 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:44962 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W2rib-000D0L-HR for perpass@ietf.org; Mon, 13 Jan 2014 19:18:57 -0500 Message-ID: <52D48271.8060007@bbn.com> Date: Mon, 13 Jan 2014 19:18:57 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D18B01.4040903@gmail.com> In-Reply-To: <52D18B01.4040903@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 00:19:12 -0000 Folks, >> On Fri, 10 Jan 2014, Stephen Farrell wrote: >> >>>> - I understand MPLS traffic is often protected at a higher layer by >>>> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could >>>> also cover this use case. And we know people are working on such >>>> solutions. [Here, that's me and my little turf war]. >>> >>> I think opportunistic IPsec could certainly help yes. I'm not >>> sure if this use-case is being considered in that work. >> >> Any non host-host case is very hard, as there is no way to verify any >> claims for random subnets of the internet. AFAIK, no good methods exist >> that any OE IPsec could use for auto-configuration. There is quite a >> difference between "here is plaintext from you to Bob, encrypt it" and >> "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory". >> > This is different from the normal IPsec OE scenario, and as a result > may be easier to solve: because it is different, I suggest that we not call it OE, which is clearly defined in RFC 4322. I suggest opportunistic keying (OK). > - The MPLS peer is already willing to send any traffic from the > private network to the other peer, which it sincerely hopes is not a > MITM. > - Each peer is typically running on an edge router (I believe) and so > has much more awareness of the network than your typical IPsec OE > peer. They will actually have the BGP information. I believe that the MPLS peers, as edge routers, are not under the control of the end users, as would more likely be the case for IPsec gateways operating at about the same point in the path. So, an important part of this discussion is that the administrative entities managing the encryption are ISPs, not subscribers. Thus the confidentiality afforded here is more of an ISP service than a subscriber-controlled service. Also, unless the MPLS path crosses AS boundaries (not yet common, I believe) this offers less protection than IPsec could. Steve From stephen.farrell@cs.tcd.ie Mon Jan 13 16:31:58 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B291D1ACC83 for ; Mon, 13 Jan 2014 16:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PSFVtOqHtI9 for ; Mon, 13 Jan 2014 16:31:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7391A8033 for ; Mon, 13 Jan 2014 16:31:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D513ABE4D; Tue, 14 Jan 2014 00:31:44 +0000 (GMT) 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 QRuk31YIg8eA; Tue, 14 Jan 2014 00:31:42 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.41.60.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B740EBE3E; Tue, 14 Jan 2014 00:31:42 +0000 (GMT) Message-ID: <52D4856E.5020801@cs.tcd.ie> Date: Tue, 14 Jan 2014 00:31:42 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Kent , perpass@ietf.org, Adrian Farrel References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D18B01.4040903@gmail.com> <52D48271.8060007@bbn.com> In-Reply-To: <52D48271.8060007@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 00:31:58 -0000 On 01/14/2014 12:18 AM, Stephen Kent wrote: > Folks, >>> On Fri, 10 Jan 2014, Stephen Farrell wrote: >>> >>>>> - I understand MPLS traffic is often protected at a higher layer by >>>>> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could >>>>> also cover this use case. And we know people are working on such >>>>> solutions. [Here, that's me and my little turf war]. >>>> >>>> I think opportunistic IPsec could certainly help yes. I'm not >>>> sure if this use-case is being considered in that work. >>> >>> Any non host-host case is very hard, as there is no way to verify any >>> claims for random subnets of the internet. AFAIK, no good methods exist >>> that any OE IPsec could use for auto-configuration. There is quite a >>> difference between "here is plaintext from you to Bob, encrypt it" and >>> "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory". >>> >> This is different from the normal IPsec OE scenario, and as a result >> may be easier to solve: > because it is different, I suggest that we not call it OE, which is > clearly defined in RFC 4322. > I suggest opportunistic keying (OK). I agree that we need to discuss terminology here and would be fine with OK instead of OE if that's where land. (We mentioned that terminology may change in the draft for this reason.) >> - The MPLS peer is already willing to send any traffic from the >> private network to the other peer, which it sincerely hopes is not a >> MITM. >> - Each peer is typically running on an edge router (I believe) and so >> has much more awareness of the network than your typical IPsec OE >> peer. They will actually have the BGP information. > I believe that the MPLS peers, as edge routers, are not under the > control of the end users, > as would more likely be the case for IPsec gateways operating at about > the same point in > the path. So, an important part of this discussion is that the > administrative entities managing > the encryption are ISPs, not subscribers. Thus the confidentiality > afforded here is more of > an ISP service than a subscriber-controlled service. Also, unless the > MPLS path crosses AS > boundaries (not yet common, I believe) this offers less protection than > IPsec could. There are apparently some kinds of MPLS deployments where nodes are under the customer's control. But yes, I agree that this potential mechanism would be of most benefit where >1 administrative entity is involved and might be of little benefit if that remains very rare. I am told however that such deployments exist. I think there may also be cases where MPLS is not carrying IP and where a (non-collaborative) fibre tap might be a concern. I think that the meta-point is that we should be chatting with the MPLS folk to see what they want and are interested in deploying. Then we can probably figure if some flavour of IPsec will be just fine or if more (like our draft) is needed. S. > > Steve > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From adrian@olddog.co.uk Tue Jan 14 04:24:13 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155981ADED5 for ; Tue, 14 Jan 2014 04:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg-Z6ZCLpnoM for ; Tue, 14 Jan 2014 04:24:11 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2A1AE081 for ; Tue, 14 Jan 2014 04:24:10 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECNsfc002019; Tue, 14 Jan 2014 12:23:54 GMT Received: from 950129200 ([62.205.119.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECNoEe002002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 12:23:51 GMT From: "Adrian Farrel" To: "'Theodore Ts'o'" , "'Stephen Kent'" Date: Tue, 14 Jan 2014 12:23:52 -0000 Message-ID: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8RI3uQd/KgxOxTTEC64YuTCdHoyQ== Content-Language: en-gb Cc: perpass@ietf.org Subject: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:24:13 -0000 > > >It helps against some attacks, but it doesn't help for others, right? > > >After all, if you are a US national, you might not trust that the > > >Chinese Telecom won't pass your traffic to the MSS. (Or if you are a > > >German national, that AT&T won't decrypto your traffic and then pass > > >it off to the NSA...) > > yep. IPsec, under the control of a subscriber, offers more protection, > > in princple. > > Or put another way, MPLS-mediated encryption violates the end-to-end > principle. It also allows ISP's to violate net neutrality principles > as well (i.e., by allowing them to do deep packet inspection and then > prioritizing some traffic over others). Two things here (probably wandering into a minefield, but that's my ball that rolled in): 1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regulators, morals, or encryption of the pieces that might be deeply inspected. You might as well say that not shooting elephants allows ISPs to do DPI! So, I think what you are saying is that not doing IPsec on your (IP) traffic allows the ISP to do DPI. But doing MPLS encryption also stops transit nodes from doing DPI, but it does not stop edge (i.e., MPLS end) nodes from doing DPI. In some deployments (carrier's carrier, MPLS-based enterprise over ISP) the traffic may already be MPLS, and so MPLS encryption might be what is available. 2. I think the end-to-end principle may already have been somewhat diluted by the introduction of edges, and the deployment of tunnels. I am guessing that you mean that the responsibility for securing traffic lies with the originator/consumer of the traffic. And that is largely fine, but again runs into VPN type discussions. Adrian From adrian@olddog.co.uk Tue Jan 14 04:38:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15961AE0C9 for ; Tue, 14 Jan 2014 04:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DLjeaGsPEOP for ; Tue, 14 Jan 2014 04:38:25 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7211B1AE0C8 for ; Tue, 14 Jan 2014 04:38:25 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECc92b014146; Tue, 14 Jan 2014 12:38:09 GMT Received: from 950129200 ([62.205.119.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECc8oM014122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 12:38:09 GMT From: "Adrian Farrel" To: "'Stephen Kent'" , Date: Tue, 14 Jan 2014 12:38:10 -0000 Message-ID: <04c101cf1125$7c249c70$746dd550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8RJKIb1yQF8wNoTd6PLccAS8lByQ== Content-Language: en-gb Subject: [perpass] Who manages the encryption: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:38:27 -0000 Steve (and Stephen) > > - The MPLS peer is already willing to send any traffic from the > > private network to the other peer, which it sincerely hopes is not a > > MITM. > > - Each peer is typically running on an edge router (I believe) and so > > has much more awareness of the network than your typical IPsec OE > > peer. They will actually have the BGP information. > I believe that the MPLS peers, as edge routers, are not under the > control of the end users, as would more likely be the case for > IPsec gateways operating at about the same point in > the path. So, an important part of this discussion is that the > administrative entities managing the encryption are ISPs, not > subscribers. Thus the confidentiality afforded here is more of > an ISP service than a subscriber-controlled service. Also, unless the > MPLS path crosses AS boundaries (not yet common, I believe) this > offers less protection than IPsec could. I think you are right on all points, and you raise some important qualifications that should be included. But that is to not discount MPLS keying. Not all traffic in an MPLS LSP is IP. Some MPLS traffic is originated outside the provider (cf. enterprises, carrier's carrier, ...) Sometimes the traffic belongs to the provider (look at all those content distribution companies, and the email providers, and the "cloud" companies, etc.) But you main point remains, and I have been asking a number of carriers lately why they don't use L2 security. A whole range of answers from manageability, through reduced capacity, to the fact that it doesn't protect against subverted/misconfigured transit nodes. The message seems to be that the higher up (or further out) we can run our SAs the more secure our data (and the more under our control the fact of security is), but the less metadata is protected and the more complex the SAs are to manage. Adrian (still musing) From stephen.farrell@cs.tcd.ie Tue Jan 14 06:48:25 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4781ADFA9 for ; Tue, 14 Jan 2014 06:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_OZAQ8OXwjf for ; Tue, 14 Jan 2014 06:48:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 766811ADFA0 for ; Tue, 14 Jan 2014 06:48:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C7E6BE47 for ; Tue, 14 Jan 2014 14:48:09 +0000 (GMT) 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 CBEaiPXf0NYu for ; Tue, 14 Jan 2014 14:48:09 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5167ABE33 for ; Tue, 14 Jan 2014 14:48:09 +0000 (GMT) Message-ID: <52D54E29.2090606@cs.tcd.ie> Date: Tue, 14 Jan 2014 14:48:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] IETF-89 perpass discussions X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:48:25 -0000 Hiya, Was just chatting with Sean about scheduling for London. Given that we have the STRINT workshop before the meeting (and hey, you've a full day left to submit your position paper [1]) we felt that we could report on that and also allocate some time for drafts (e.g. [2]) being discussed on this list at the saag session and that'd be enough. So we're not planning on having a separate perpass slot during the meeting week but have requested a 2.5 hour saag slot which is 30 minutes longer than usual. But if lots of you yell at us before Friday that that's a bad plan we can request a perpass slot. (You can yell off list or on, whatever:-) Cheers, S. [1] https://www.w3.org/2014/strint/ [2] http://tools.ietf.org/html/draft-barnes-pervasive-problem From mcr@sandelman.ca Tue Jan 14 12:24:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1581AE0D5 for ; Tue, 14 Jan 2014 12:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWvfKxRCDxkW for ; Tue, 14 Jan 2014 12:24:16 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id BB8641ADF83 for ; Tue, 14 Jan 2014 12:24:15 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E1BE2002C; Tue, 14 Jan 2014 16:39:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 76CC364647; Tue, 14 Jan 2014 15:24:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6212963B88; Tue, 14 Jan 2014 15:24:03 -0500 (EST) From: Michael Richardson To: perpass@ietf.org In-Reply-To: <52D48271.8060007@bbn.com> References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D18B01.4040903@gmail.com> <52D48271.8060007@bbn.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Stephen Kent Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:24:17 -0000 --=-=-= Stephen Kent wrote: > because it is different, I suggest that we not call it OE, which is > clearly defined in RFC 4322. I suggest opportunistic keying (OK). I just want to say that rfc4322 (an *Informational*) rfc, defines: Opportunistic Encryption using the Internet Key Exchange which might be best called "OEIKEv1" key thing about OEIKEv1 is that it binds end points to IP addresses using reverse DNS, with some weakening where a node may speak for itself (only). It does *not* mandate that the phase2/CHILDSA be IPsec ESP. So, if you want to call it OEMPLS or something like that, I'd say it's just fine. Further if someone wants to write a mechanism for IKE(v2) that lets you key MPLS flows, and there is some way to bind MPLS flows to an IPv4 or IPv6 end point, then I think that one could leverage much of the work. I think that one could quite easily insert something in at the MPLS layer that would provide some token that could be cryptographically bound by IKE to prove that the two MPLS end points are connected to each other below the IP layer. What, exactly, I don't know.... I never built MPLS pusher/popper hardware, just parsing/switching ASIC. (14 years ago) I personally see no value in doing MPLS hop-by-hop encryption. Where MPLS is used within a single AS, whether one does hop-by-hop or label-push/label-pop encryption, it's all within the AS, and what is protecting against bent fiber attacks. Since it's all subject to national order to the ISP, so, in my opinion, what's the point. Where it would have value is to the end enterprise customer who is linking multiple sites together in a layer-2 fashion. In my experience, MPLS CPE equipment is not under the control (i.e. not trusted) by the end customer, so even doing entry/exit this way is suspect, since it's the ISP again. Further, many of the MPLS deployments to "enterprises" have often not even been about layer-2 connectivity --- they see layer-3 routers at each site, (usually two or three of them, with different VLAN tags). The MPLS part is pretty much just up-sale marketing... All of this effort would be better spent pushing IKEv1 and L2TP off the map, and making IPv6 + IPsec easier to setup. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUtWc4YqHRg3pndX9AQKKVQP8CjIoLIxrPRbOxkbtRmWoAju6sVMz938R OiQA6FsWggrj8XED7Y/vH25x/8mV+FU1zAn39OrGTTLoJhtBomdLBpy2QbLFPiJD MZnz4QrgclT3EGTszwS/yedHkfb2bPVdaiPSjCAwVplwJB1LT0LNUDmAuzlN/AoD rytvYv0+irY= =BcVS -----END PGP SIGNATURE----- --=-=-=-- From dhc@dcrocker.net Tue Jan 14 12:37:50 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5CE1AE19D for ; Tue, 14 Jan 2014 12:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5wU0WKtHIy0 for ; Tue, 14 Jan 2014 12:37:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4161AE133 for ; Tue, 14 Jan 2014 12:37:49 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0EKbQpf000955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jan 2014 12:37:29 -0800 Message-ID: <52D59FFF.4000308@dcrocker.net> Date: Tue, 14 Jan 2014 12:37:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <52D54E29.2090606@cs.tcd.ie> In-Reply-To: <52D54E29.2090606@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 14 Jan 2014 12:37:29 -0800 (PST) Subject: Re: [perpass] IETF-89 perpass discussions X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:37:51 -0000 On 1/14/2014 6:48 AM, Stephen Farrell wrote: > But if lots of you yell at us before Friday that that's > a bad plan we can request a perpass slot. (You can yell > off list or on, whatever:-) On the average, the f2f meeting isn't very efficient or productive for dealing with broad group discussion questions. Perpass might be an exception. I suggest having a session to discuss one or two basic issues. Better community clarity about some of the basic might improve our ability to discuss technical issues. For example, what is in scope for perpass and what is not? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim@gmail.com Tue Jan 14 12:45:40 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CA51AE210 for ; Tue, 14 Jan 2014 12:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx-uJjm93evl for ; Tue, 14 Jan 2014 12:45:39 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 344C61AE246 for ; Tue, 14 Jan 2014 12:45:39 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wp4so177499obc.10 for ; Tue, 14 Jan 2014 12:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qTPac7K4A5XeosISmW8wCmQLw0VppBQ6Xs3SFqHTk94=; b=XiJgFBBGXoZMzeFZCbJe+uGkRZzS+yMPFzUSXvwSMJTzuVk5suXP8NiovilQiT3/zM +autyytSPE7mAHvMO7kf3ZWv6Zuy4SaMF1Cv9Gievm1BarG4Kc9G5xvTaYEEWu9C6ykm gKXAT2e6inDdmOyqilP5GmvParxSuPPUEAq5O+/PEb9u/eJn3IcGYB1SSSz9RVtJsyr6 kLF9A2KUCzdrqkv+boOWSs6OpneCKyX+E0YOwBcNk/CBOLVTVGUA8B4rdnPs1q3aWjOr sHmR8s557IELCPW9VF2VcINY0meKzchBhUjQ2jBJL+DBH2gLeXL1nNq35SAPM3DeHEES s9tA== X-Received: by 10.182.129.201 with SMTP id ny9mr2976677obb.0.1389732327681; Tue, 14 Jan 2014 12:45:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 12:45:07 -0800 (PST) In-Reply-To: <52D59FFF.4000308@dcrocker.net> References: <52D54E29.2090606@cs.tcd.ie> <52D59FFF.4000308@dcrocker.net> From: Scott Brim Date: Tue, 14 Jan 2014 15:45:07 -0500 Message-ID: To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Stephen Farrell Subject: Re: [perpass] IETF-89 perpass discussions X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:45:41 -0000 On Tue, Jan 14, 2014 at 3:37 PM, Dave Crocker wrote: > I suggest having a session to discuss one or two basic issues. Better > community clarity about some of the basic might improve our ability to > discuss technical issues. > > For example, what is in scope for perpass and what is not? Sounds like either SAAG or a segment in a Plenary following up from last meeting. From dcrocker@bbiw.net Tue Jan 14 12:51:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A471AE170 for ; Tue, 14 Jan 2014 12:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGYJE2nQafZK for ; Tue, 14 Jan 2014 12:51:56 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6663C1ADF99 for ; Tue, 14 Jan 2014 12:51:56 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0EKpZJd001370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jan 2014 12:51:39 -0800 Message-ID: <52D5A351.1000404@bbiw.net> Date: Tue, 14 Jan 2014 12:51:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim References: <52D54E29.2090606@cs.tcd.ie> <52D59FFF.4000308@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Tue, 14 Jan 2014 12:51:39 -0800 (PST) Cc: perpass , Stephen Farrell Subject: Re: [perpass] IETF-89 perpass discussions X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:51:57 -0000 On 1/14/2014 12:45 PM, Scott Brim wrote: > On Tue, Jan 14, 2014 at 3:37 PM, Dave Crocker wrote: >> I suggest having a session to discuss one or two basic issues. Better >> community clarity about some of the basic might improve our ability to >> discuss technical issues. >> >> For example, what is in scope for perpass and what is not? > > Sounds like either SAAG or a segment in a Plenary following up from > last meeting. I thought the point of this group was to move discussions out of those generic venues. Besides that, neither of those venues is very good for "discussion". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fred@cisco.com Tue Jan 14 13:45:48 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52B01AE245; Tue, 14 Jan 2014 13:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.039 X-Spam-Level: X-Spam-Status: No, score=-115.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88hM5Z4Nua3j; Tue, 14 Jan 2014 13:45:46 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 121491AE18B; Tue, 14 Jan 2014 13:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2669; q=dns/txt; s=iport; t=1389735933; x=1390945533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qztm/aaC677/65pQk8xped+U/y5kMvSpUwAwuWy4l+8=; b=CL1V1M+7BQz7L3D2ZibQeM6f3iYhc4qpODz/QrH6Hxw+7NpwWaS9yLtG W7shJstyqYL9GpUrhQD5UxdOtSsQ8JKgJXCUzhe50D9w7eEm3tzFLiNfi hTrRVNU8IfxIzbK+Mzuz4SrU4+OyykfoRZpmMxi/xjFNR7mLww+4556iB U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAFiv1VKtJV2Y/2dsb2JhbABRCYMLOFa6bIEYFnSCJQEBAQMBZxIFCwIBCBIcARcyFw4CBA4FDgyHYggNw3gXjixbBxIBgxGBEwSQN4ExAoY0gTCQZYMtgWoHFyI X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="asc'?scan'208";a="297305395" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jan 2014 21:45:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0ELjWSp008760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 21:45:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 15:45:32 -0600 From: "Fred Baker (fred)" To: Stephen Farrell Thread-Topic: draft-farrell-perpass-attack architecture issue Thread-Index: AQHPEJW1zBILpAAtaEWpS3JElCG6BZqFJ00A Date: Tue, 14 Jan 2014 21:45:31 +0000 Message-ID: References: <52D43E69.6090001@cs.tcd.ie> In-Reply-To: <52D43E69.6090001@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_BC463148-3AF9-4C49-A696-21C2858FD9E8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass , IETF-Discussion Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:45:48 -0000 --Apple-Mail=_BC463148-3AF9-4C49-A696-21C2858FD9E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 13, 2014, at 11:28 AM, Stephen Farrell = wrote: > It means > that, if asked, there needs to be a good answer to the question "is > pervasive monitoring relevant to this work and if so how has it been > considered?" Just a thought - that might be a good question to add to the shepherd's = report. In that case, I might suggest a minor change, however. We discuss = "Pervasive monitoring" in a "big brother is watching" sense, and (at = least in perpass) concern ourselves with data that could have been = hidden had encryption or some other code used. I'll argue that, however = dreadful Big Brother might be, location-based services can be a lot = scarier. = http://online.wsj.com/news/articles/SB100014240527023034530045792906321289= 29194?mg=3Dreno64-wsj&url=3Dhttp%3A%2F%2Fonline.wsj.com%2Farticle%2FSB1000= 1424052702303453004579290632128929194.html Data point: a lot of these operate without specific knowledge of an = individual, but can. For example, the article talks a lot about = aggregating information and providing it without identifying = information. However, it goes on to say that if someone logs into a = service using, for example, a Facebook identifier, they can remain = identified to the system as they wander around in it. The messages = themselves contain no identifying information per se, but they contain = information that can be correlated back to that login. And the login = wasn't "data in flight", it was "creating state with a service at rest". So the question in the shepherd's report should not be "tell me you = thought about the EU Data Retention Initiative and whether your = protocol's data identifies an individual". It should be "what personal, = equipment, or session identifiers, encrypted or otherwise, are carried = in your protocol? How might they be correlated with offline data or = otherwise used to infer the identity or behavior of an individual?" --Apple-Mail=_BC463148-3AF9-4C49-A696-21C2858FD9E8 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 - http://gpgtools.org iD8DBQFS1a/6bjEdbHIsm0MRAhurAKDtvxj9XPvF4VngGVR9vledpu7tDwCcCxCV dL1riZJE7BKAAqskTxsRilU= =VIWb -----END PGP SIGNATURE----- --Apple-Mail=_BC463148-3AF9-4C49-A696-21C2858FD9E8-- From melinda.shore@gmail.com Tue Jan 14 14:00:29 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769E71AE2AC for ; Tue, 14 Jan 2014 14:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oEKKmCKbi03 for ; Tue, 14 Jan 2014 14:00:28 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4958A1AE2AF for ; Tue, 14 Jan 2014 14:00:28 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so223361pbc.11 for ; Tue, 14 Jan 2014 14:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=M9XoMcS9pdmvgxipA/fU8UdTx784WkQWbO/zP3sE8T8=; b=CzUiFmZNa5tdxD9hfvj4PQjVgC3ZuTSK0ZQVk7DwxMKdMBMJkcSKaT012LWZ+j89O8 n06I3KTZcThkf6eom7hLVQKmUFtC9xznyjBBS6B35NuhN0vxVL0m4CnWRR3i+rBj/Ga+ RD0aDZApfkqe5JKTcJceQ+UqcShWQpI8WEwTE1Ltxe8ZexHAyb/C1Ea9sFMQGQtnB7UQ 8AV+RUDPzIUEAyeFOAh04JHEPJFzg5gmgHjfQ5Ai/7NysHaXdj0mf8SC1LW0s+VH21rL LJBdoyGFoi88JGkhFPH6Cti8d7By+IBNGIxLnGSCPwFlzLgf6hL5HflSE3Eg67GEqXOb qcIg== X-Received: by 10.66.139.8 with SMTP id qu8mr4321801pab.157.1389736816975; Tue, 14 Jan 2014 14:00:16 -0800 (PST) Received: from spandex.local (209-112-136-197-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.136.197]) by mx.google.com with ESMTPSA id qq5sm3421812pbb.24.2014.01.14.14.00.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jan 2014 14:00:15 -0800 (PST) Message-ID: <52D5B36D.1020405@gmail.com> Date: Tue, 14 Jan 2014 13:00:13 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: perpass@ietf.org References: <52D43E69.6090001@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:00:29 -0000 On 1/14/14 12:45 PM, Fred Baker (fred) wrote: > So the question in the shepherd's report should not be "tell me you > thought about the EU Data Retention Initiative and whether your > protocol's data identifies an individual". It should be "what > personal, equipment, or session identifiers, encrypted or otherwise, > are carried in your protocol? How might they be correlated with > offline data or otherwise used to infer the identity or behavior of > an individual?" I agree - I think this is a useful framing, beyond the question of actual traffic inspection. It's pretty clear that there's been a lot of data mining, as well, and we haven't thought very carefully about what we may be leaking inadvertently. This is particularly a concern as efforts like geonet start to ramp up. Melinda From scott.brim@gmail.com Tue Jan 14 14:10:10 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8E11AE2BA; Tue, 14 Jan 2014 14:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo2H1UrCaKu6; Tue, 14 Jan 2014 14:10:08 -0800 (PST) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9CB1AE2AA; Tue, 14 Jan 2014 14:10:07 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id i7so286809oag.26 for ; Tue, 14 Jan 2014 14:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MHIWFAi9eUIgZBDzwRJ533ehtjlZCRvtuR3Bb3pPAjw=; b=ZmyfUx77OBGiBoOp+p1OKu6mpwMyhQx4cGkBdEq19iy+5E2+JW/0F6dpqfAoNCjA6z 173EEs1dF83/t4uKUKApo6tMRtgSshe014bg2bQy1i2sfSI4BiL+mV3pH5SgP/C2OK5m C0yq9dFVuL+p+8TrnSNPfMgWcSAvlNmsDbYz4hEoaqg2gCz/n66+OgQxXCbTgPSFoRg1 4ujnkUjNlkup74tfbUrBvAkE5I49VH/i3O3t4cpexZXOwL9Ej0P0YIVrNSrLI/TJ1vNe dJy97O8Rj76uNe+NFKPeF/b8TlIVXMktq7i361Mbanvz6ig6Aw9up3/UjqKDxg42XBEu K+pA== X-Received: by 10.60.174.167 with SMTP id bt7mr3178714oec.54.1389737396354; Tue, 14 Jan 2014 14:09:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 14:09:36 -0800 (PST) In-Reply-To: References: <52D43E69.6090001@cs.tcd.ie> From: Scott Brim Date: Tue, 14 Jan 2014 17:09:36 -0500 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perpass , IETF-Discussion , Stephen Farrell Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:10:10 -0000 On Tue, Jan 14, 2014 at 4:45 PM, Fred Baker (fred) wrote: > So the question in the shepherd's report should not be "tell me you thoug= ht about the EU Data Retention Initiative and whether your protocol's data = identifies an individual". It should be "what personal, equipment, or sessi= on identifiers, encrypted or otherwise, are carried in your protocol? How m= ight they be correlated with offline data or otherwise used to infer the id= entity or behavior of an individual?" The main problem is that: privacy issues are deeper than that, the question could be misunderstood without a larger context, and there's already a set of documents discussing most of that larger context (RFC 6973, the perpass problem statement draft, etc.). The Document Shepherd Write-Up currently doesn't reference security guidelines directly. Instead of asking a few specific questions in the shepherd's writeup as you suggest, consider adding the privacy/perpass docs to BCP 72 (which already includes RFC 3552) as they are approved, and then optionally add a question to the shepherd's writeup that refers to it, in order to emphasize the increased attention to the issue. Scott From fred@cisco.com Wed Jan 15 00:01:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400B91AE31D; Wed, 15 Jan 2014 00:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4LYxEZu0Syy; Wed, 15 Jan 2014 00:01:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 09F921AE317; Wed, 15 Jan 2014 00:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1113; q=dns/txt; s=iport; t=1389772856; x=1390982456; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+qt8Wp8e3tnGjyXs5z30MckuWJ3rOqZie71mdJ/+jtc=; b=Dz/DSWC0m1spxmljGaLJeW7/xl2kxZYKQNj3tJ/jgJqaZZ5FDHvRd7Pf 1QAhvz6n1tXP2T9sW2Mc4KB/zfWQnb4NqcExvFvqlUPi25nMn+NXKTxEy SsBL35XzgXJNOZufpKYWyM2jMQoUfSgvtJGUvWHOZKYUwvbUUMKDC4iI0 s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAP8+1lKtJV2b/2dsb2JhbABagwuBDrp+gRUWdIIlAQEBBHkQAgEIEgYuIREXDgIEDgUOh2IDEb4ADYVhF4x0ghMHgySBEwSQN4ExhEqBbIxahTuDLYIq X-IronPort-AV: E=Sophos;i="4.95,661,1384300800"; d="asc'?scan'208";a="12965277" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 15 Jan 2014 08:00:56 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0F80uTa025058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jan 2014 08:00:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.230]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 15 Jan 2014 02:00:56 -0600 From: "Fred Baker (fred)" To: Abdussalam Baryun Thread-Topic: draft-farrell-perpass-attack architecture issue Thread-Index: AQHPEJW1zBILpAAtaEWpS3JElCG6BZqFJ00AgACGcgCAACV9gA== Date: Wed, 15 Jan 2014 08:00:55 +0000 Message-ID: <6F7415D3-E58B-46F4-BF51-9E139AD0FDC1@cisco.com> References: <52D43E69.6090001@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_E2B94636-9C25-4B4E-992B-0ABB04F57931"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass , IETF-Discussion , Stephen Farrell Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 08:01:09 -0000 --Apple-Mail=_E2B94636-9C25-4B4E-992B-0ABB04F57931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 14, 2014, at 9:46 PM, Abdussalam Baryun = wrote: > The draft must include your questions, so that it can become a clear = initial-BCP, or a clear plan draft. IMHO, the initial-BCP draft is not = clear or not direct if it does not mention your questions, I'm just one. But from my perspective, it must not only ask them, but = answer them or outline how the answers might be arrived at. --Apple-Mail=_E2B94636-9C25-4B4E-992B-0ABB04F57931 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 - http://gpgtools.org iD8DBQFS1kA1bjEdbHIsm0MRAn4kAJ4tDfNlopnuO0fH9gdHAmlVx7/sCwCgluoe LB39jyXptfH/B2NJAY1Cqog= =nDUX -----END PGP SIGNATURE----- --Apple-Mail=_E2B94636-9C25-4B4E-992B-0ABB04F57931-- From stephen.farrell@cs.tcd.ie Wed Jan 15 05:10:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8111AE1A4 for ; Wed, 15 Jan 2014 05:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80vTKhYKXmix for ; Wed, 15 Jan 2014 05:10:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1F71AE0CB for ; Wed, 15 Jan 2014 05:10:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6430FBE38; Wed, 15 Jan 2014 13:10:12 +0000 (GMT) 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 td9wbgj-vMbj; Wed, 15 Jan 2014 13:10:12 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4226BBE25; Wed, 15 Jan 2014 13:10:12 +0000 (GMT) Message-ID: <52D688B3.3040907@cs.tcd.ie> Date: Wed, 15 Jan 2014 13:10:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Melinda Shore , perpass@ietf.org References: <52D43E69.6090001@cs.tcd.ie> <52D5B36D.1020405@gmail.com> In-Reply-To: <52D5B36D.1020405@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:10:27 -0000 On 01/14/2014 10:00 PM, Melinda Shore wrote: > On 1/14/14 12:45 PM, Fred Baker (fred) wrote: >> So the question in the shepherd's report should not be "tell me you >> thought about the EU Data Retention Initiative and whether your >> protocol's data identifies an individual". It should be "what >> personal, equipment, or session identifiers, encrypted or otherwise, >> are carried in your protocol? How might they be correlated with >> offline data or otherwise used to infer the identity or behavior of >> an individual?" > > I agree - I think this is a useful framing, beyond the question > of actual traffic inspection. It's pretty clear that there's > been a lot of data mining, as well, and we haven't thought very > carefully about what we may be leaking inadvertently. This is > particularly a concern as efforts like geonet start to ramp > up. I do like the idea that shepherds would report on this topic (or more generally on security and privacy) in their write-ups, but have a genetic dislike of the way we used to have a 1000-point questionnaire for shepherds to fill in. And a lot of the current shepherd write-ups we get tend to be out of date wrt e.g. IPR so I'm pretty convinced that we shouldn't hardcode shepherd write-ups into RFCs on this topic, since that level of process is liable to change relatively often. OTOH, as a "new" thing for WGs to consider, it might be quite useful if shepherds are prompted to not forget about pervasive monitoring. So I'm in two minds here really. I figure that this is something where we'll have to learn as we go. Maybe we should look at a tool that randomly (but not uniformly randomly) picks a small number of hard questions from a long list and asks the shepherd to answer those. Sort of a write-up bingo;-) I'd be interested if someone wanted to start work on some WG-chair/shepherd guidance for how to consider pervasive monitoring. That'd likely take a while to get baked, and would maybe end up not (just) as an RFC, but as training material and/or an IESG statement or something, but could easily start as an I-D. Any takers? S From scott.brim@gmail.com Wed Jan 15 06:28:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2211AE0F4 for ; Wed, 15 Jan 2014 06:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiJY_9ih44oe for ; Wed, 15 Jan 2014 06:28:14 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE91AE0D2 for ; Wed, 15 Jan 2014 06:28:14 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so1207760obc.23 for ; Wed, 15 Jan 2014 06:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DQhM/JqLSNZaF8O23vwpxO/xCUWiBkzV5rhtSqS9UCU=; b=jzyHRkffsHMfu6EuHUQGUdVpPwFq7+Zc86TdV2l3b2AbDFbGKHiiFFNkpb50X17R/e a+N/2hQ5hPWLWC1KVRQr7/tgmF+Ymt6QTaxrjXJ4Pkl2IJNhiyckPE+PySqRSsFff102 4SwODF/wMztrzGH06vteg6X45ze5H3YrvoGSvvPxHKCOyZbl1puZ/prS+8umOKPQft3c Ekw7Kfd1NhBnR4deqa4EtNDKURsppnmchSPA09Y0E9Rrd1uM0zwk12cigd0hrh2sfOUx 35lRUCYavTf+S0pU8hvgzRuHHJEs9uD6xMB7CUMhBMGLMPJ/zoPBc3kT2bemYVPMg9oH Bvkg== X-Received: by 10.60.174.167 with SMTP id bt7mr2005401oec.54.1389796082964; Wed, 15 Jan 2014 06:28:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 15 Jan 2014 06:27:42 -0800 (PST) In-Reply-To: <52D688B3.3040907@cs.tcd.ie> References: <52D43E69.6090001@cs.tcd.ie> <52D5B36D.1020405@gmail.com> <52D688B3.3040907@cs.tcd.ie> From: Scott Brim Date: Wed, 15 Jan 2014 09:27:42 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Melinda Shore Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:28:16 -0000 On Wed, Jan 15, 2014 at 8:10 AM, Stephen Farrell wrote: > I'd be interested if someone wanted to start work on some > WG-chair/shepherd guidance for how to consider pervasive > monitoring. That'd likely take a while to get baked, and > would maybe end up not (just) as an RFC, but as training > material and/or an IESG statement or something, but could > easily start as an I-D. Any takers? I think we already have a lot of it. (1) Add RFC6973 to BCP72. (2) Keep moving the perpass-related drafts forward, and add them as they become mature. (3) In the shepherds writeup template, have a question such as "(18) Describe the Document Shepherd's review of the security considerations section (see BCP 72 for guidelines), especially with regard to its consistency with the body of the document." Scott From lear@cisco.com Wed Jan 15 06:33:22 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609B91AE37A for ; Wed, 15 Jan 2014 06:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkywODrhd6ta for ; Wed, 15 Jan 2014 06:33:20 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 162C41AE0F4 for ; Wed, 15 Jan 2014 06:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2582; q=dns/txt; s=iport; t=1389796388; x=1391005988; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LoJc+zjAwAlBDxFLEH6UPPiovlEjjP7+D8PawMCYctY=; b=By5NbtEViVflPoOMD8MDcqHdWlRj6jOJUe9UmRbsWdZCBY3ZMxxasq3F Vr1vRGlYbmaEJIH/urOrMbT3KZCbe7zwc5+dTkMQoO/jk77m1PR7WDJsx QPvFw2c+Nat0xnSfVPN8JnpThFaO3NeANHH8IhY+f28EMNr2zHX3GQzTg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOSa1lKQ/khR/2dsb2JhbABQCYMLOINUtzJPgRUWdIIlAQEBBAEBASBEBwoRCxIGAgIFFgsCAgkDAgECARUWDA4GAQwGAgEBGIdoDagdm20TBIEpjHtigm+BSASFK5J1jDeFXoMuOw X-IronPort-AV: E=Sophos;i="4.95,663,1384300800"; d="scan'208";a="2995499" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 14:33:07 +0000 Received: from mctiny.local ([10.61.166.90]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0FEX60Q015182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 14:33:07 GMT Message-ID: <52D69C22.1010900@cisco.com> Date: Wed, 15 Jan 2014 15:33:06 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , Melinda Shore , perpass@ietf.org References: <52D43E69.6090001@cs.tcd.ie> <52D5B36D.1020405@gmail.com> <52D688B3.3040907@cs.tcd.ie> In-Reply-To: <52D688B3.3040907@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:33:22 -0000 Yeah, I think it's quite reasonable for a shepherd to ask the developers of a spec how they have considered PM, and see if it at least passes a sniff test. Eliot On 1/15/14 2:10 PM, Stephen Farrell wrote: > > On 01/14/2014 10:00 PM, Melinda Shore wrote: >> On 1/14/14 12:45 PM, Fred Baker (fred) wrote: >>> So the question in the shepherd's report should not be "tell me you >>> thought about the EU Data Retention Initiative and whether your >>> protocol's data identifies an individual". It should be "what >>> personal, equipment, or session identifiers, encrypted or otherwise, >>> are carried in your protocol? How might they be correlated with >>> offline data or otherwise used to infer the identity or behavior of >>> an individual?" >> I agree - I think this is a useful framing, beyond the question >> of actual traffic inspection. It's pretty clear that there's >> been a lot of data mining, as well, and we haven't thought very >> carefully about what we may be leaking inadvertently. This is >> particularly a concern as efforts like geonet start to ramp >> up. > I do like the idea that shepherds would report on this topic > (or more generally on security and privacy) in their write-ups, > but have a genetic dislike of the way we used to have a > 1000-point questionnaire for shepherds to fill in. And a lot > of the current shepherd write-ups we get tend to be out of > date wrt e.g. IPR so I'm pretty convinced that we shouldn't > hardcode shepherd write-ups into RFCs on this topic, since > that level of process is liable to change relatively often. > OTOH, as a "new" thing for WGs to consider, it might be > quite useful if shepherds are prompted to not forget about > pervasive monitoring. > > So I'm in two minds here really. > > I figure that this is something where we'll have to learn as > we go. Maybe we should look at a tool that randomly (but > not uniformly randomly) picks a small number of hard questions > from a long list and asks the shepherd to answer those. Sort > of a write-up bingo;-) > > I'd be interested if someone wanted to start work on some > WG-chair/shepherd guidance for how to consider pervasive > monitoring. That'd likely take a while to get baked, and > would maybe end up not (just) as an RFC, but as training > material and/or an IESG statement or something, but could > easily start as an I-D. Any takers? > > S > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From kent@bbn.com Wed Jan 15 07:18:48 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84E1AE38A for ; Wed, 15 Jan 2014 07:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-cJ7HldxG2C for ; Wed, 15 Jan 2014 07:18:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCAB1AE37B for ; Wed, 15 Jan 2014 07:18:46 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40593 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W3SEk-000C5v-2B; Wed, 15 Jan 2014 10:18:34 -0500 Message-ID: <52D6A6C9.9030401@bbn.com> Date: Wed, 15 Jan 2014 10:18:33 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, perpass@ietf.org References: <04c101cf1125$7c249c70$746dd550$@olddog.co.uk> In-Reply-To: <04c101cf1125$7c249c70$746dd550$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Who manages the encryption: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 15:18:48 -0000 Adrian, ... > But you main point remains, and I have been asking a number of carriers lately > why they don't use L2 security. A whole range of answers from manageability, > through reduced capacity, to the fact that it doesn't protect against > subverted/misconfigured transit nodes. These seem like reasonable responses, and there is the fact that any L2 security mechanism will not play well with any intermediate L3 switching/routing devices. > The message seems to be that the higher up (or further out) we can run our SAs > the more secure our data (and the more under our control the fact of security > is), but the less metadata is protected and the more complex the SAs are to > manage. The tradeoffs are not trivial. E-t-e security (confidentiality, authentication, integrity, etc.) is "best" but it is also the most costly to deploy and manage in many contexts. Deploying security at an administrative boundary for an enterprise makes sense for most environments, as it is less expensive and much, much easier to manage. That's why a firewall at the interface to an ISP is generally more attractive than per-user device firewalls in an enterprise. This argues for IPsec gateways, vs. per-user device IPsec, in such environments. One can view MPLS encryption as analogous, but if the MPLS encryption is provided by an ISP, vs. an enterprise, the analogy is not quite the same. Traditionally, the security community has felt that the tradeoff between traffic flow confidentiality and e-t-e confidentiality should be skewed toward the latter. In part this is because there may be many other ways to acquire the protocol metadata, and because the extra costs associated with providing good TFC are viewed as too high. In the 80's I recall that the US DoD didn't feel that it was worth the cost of providing TFS for traffic at the SECRET level or below, and they were worried about nation state adversaries. So it's a hard sell, in my mind, to emphasize TFC for the vast majority of Internet traffic, unless the costs (capital, recurring, and user impact) are essentially zero. Steve From joe@cdt.org Thu Jan 16 04:10:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC57E1AE312 for ; Thu, 16 Jan 2014 04:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Fy00H6lQnG for ; Thu, 16 Jan 2014 04:10:25 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F61AE31D for ; Thu, 16 Jan 2014 04:10:24 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for perpass@ietf.org; Thu, 16 Jan 2014 07:10:10 -0500 Message-ID: <52D7CC22.7060700@cdt.org> Date: Thu, 16 Jan 2014 07:10:10 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] STRINT position paper deadline extended to 20 Jan... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 12:10:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The organizers of the STRINT workshop right before IETF 89 extended the deadline for position papers last night: https://www.w3.org/2014/strint/ And I hear that this is the "anywhere on Earth" midnight timezone (so 12:00 UTC 21 January 2014). best, Joe - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS18wiAAoJEF+GaYdAqahxuBYP/iL3nvvLzPLBZWOwtZTuXPUh c/9xWoLWMPwUwfW3jh4Jif6VEss/fVLFcDiU5eVw2BfKIXLCZdPLOPgQcZoNNtWE PDde6uzeEKTs94cArMXMm8uOJyQQwCO7TvlzvN3VJzmAMgeUiaY62sFbWsGG/Lhz 8vw1n361mFI27cFp+TpcHHomj+GIQNY6fLJL2x81RgWle2o5R8IGMiC+pSCGcU3g 8tN+rPWEbILk9SqYBsc1eA6x6j9vaXFUIC/jR5eT+QwcQDKA4dC1FRhC46SIPjrC IOpmYPB9zzbL2BlljIh1Q4dw0/phIxWb7F7pzS46jgeOSPrOTEI+J9XBK/7pXBi5 FaTtWbrmFNepN/3yZW2KRDdG30M757Y4hS/7wOjDL0ZOBjFtOBGB5azo/VIrtIZQ Bk8RHKXCo01+Hqw4lj43BW6/S/c6xZTa8PhD8AJXK6z1O0j/F5uw+Iupkr/9PQjG +NmRZowfy6q1CX0wKt98NjKsYmG6VtWFzNnhYKnDVdfNgbuyVw/1ZoKuLJ0CmZiA dBHJv3PZIOD2rvogTwEXxL2qQo8YKWRf7plXb7/XIMZOjrQWUux+9NQMw8/uWXhA bYYBg/QBQoD2qTDIiFGokgOCzDJRez8EG1f6sT0246qUvnFdKlp/WJ9pg/C7Hl9Y AefMIcvVVuRmX3NMH0T7 =FiQb -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Thu Jan 16 04:24:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321471AE312 for ; Thu, 16 Jan 2014 04:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHNiPqP0dE_e for ; Thu, 16 Jan 2014 04:24:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 104211AE31A for ; Thu, 16 Jan 2014 04:24:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 511BFBE1C; Thu, 16 Jan 2014 12:24:08 +0000 (GMT) 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 i7vx3ZJ8MEXj; Thu, 16 Jan 2014 12:24:08 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3242CBDF9; Thu, 16 Jan 2014 12:24:08 +0000 (GMT) Message-ID: <52D7CF68.7080905@cs.tcd.ie> Date: Thu, 16 Jan 2014 12:24:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joseph Lorenzo Hall , perpass References: <52D7CC22.7060700@cdt.org> In-Reply-To: <52D7CC22.7060700@cdt.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] STRINT position paper deadline extended to 20 Jan... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 12:24:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Joe, You beat me to it! S. PS: We got 43 submissions so far and I know of a few more that are expected by the extended deadline, which is why we extended. The TPC will have work to do:-) On 01/16/2014 12:10 PM, Joseph Lorenzo Hall wrote: > The organizers of the STRINT workshop right before IETF 89 > extended the deadline for position papers last night: > > https://www.w3.org/2014/strint/ > > And I hear that this is the "anywhere on Earth" midnight timezone > (so 12:00 UTC 21 January 2014). > > best, Joe > > > _______________________________________________ perpass mailing > list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJS189oAAoJEC88hzaAX42icpkH/3eFfIzolw2j3lTTOCgylFUk rz6FEegpEoP3nmRFtsVjy3xz/WdXaJSVkQxD5i590yTPBfN4EvG9NFQ2HwZMk8Lj OPGXHODv/Nfgz7Ihvp5M12E6Ix+eRrWM3wBp1AJGN8geHIEFfLephJllAscUYJIa vRbSGquuTJReZ41Jp7VRD+uZd7WCZYIbMeVg4ablCF3lauNqf98uUGFurVwAgs0j oVV6zyvVyHYm/P4OYV1Q022wgqoATJIb9n8eqpz0FL1mfbPPCLM4Z1fmBCGJzzEh /9+OsvuHaihV7zSOlHqIE1nkGijLVYpg/qLU+tY+JBukWpjbdd3PD3KCEVY95WY= =iS/H -----END PGP SIGNATURE----- From hallam@gmail.com Thu Jan 16 06:57:23 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553D1AE35D for ; Thu, 16 Jan 2014 06:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi6esnrOFuVb for ; Thu, 16 Jan 2014 06:57:21 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E22521AE349 for ; Thu, 16 Jan 2014 06:57:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so2004616lbj.31 for ; Thu, 16 Jan 2014 06:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NzFAtQ+EPbUVEdkusV2DaO/8kk/vS0PAfBC4zyVosyU=; b=jjqg31Cf87SJQKXfMmnE0Z/KGKgw5uPzez3oR4Rhla9dzDH7kin6YvUjOTQDG6A/P2 F9+zOpzC0ZdyUAAH81aQayDIATKxKpAaikd1vxVNom/gnMq7cKyHS8lORau9MvfTsLyi kKGDfO0DL0GC9Hjw1SwiHpp+6m2RYQebTcdMsIT27VmVWP+LnLpyvUSg3HsOO0i5+YFQ j9w2cO7FU/dcIP4u5tLyg/+7q7wyrMkMvQQMgSUJEJm06JTpyG6m5YxjfjcNj3P/KSDk BV6SPABAsAWt7KDtddWLgf5SxiTar+F5DDKFFbTe1IEZbif9VIW4tut7chkhoaUPG35P uMYA== MIME-Version: 1.0 X-Received: by 10.152.1.197 with SMTP id 5mr5447547lao.0.1389884228013; Thu, 16 Jan 2014 06:57:08 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 16 Jan 2014 06:57:07 -0800 (PST) In-Reply-To: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> Date: Thu, 16 Jan 2014 09:57:07 -0500 Message-ID: From: Phillip Hallam-Baker To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e0112bfceb094d704f017a3d6 Cc: perpass , Theodore Ts'o , Stephen Kent Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:57:23 -0000 --089e0112bfceb094d704f017a3d6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 14, 2014 at 7:23 AM, Adrian Farrel wrote: > > > >It helps against some attacks, but it doesn't help for others, right? > > > >After all, if you are a US national, you might not trust that the > > > >Chinese Telecom won't pass your traffic to the MSS. (Or if you are a > > > >German national, that AT&T won't decrypto your traffic and then pass > > > >it off to the NSA...) > > > yep. IPsec, under the control of a subscriber, offers more protection, > > > in princple. > > > > Or put another way, MPLS-mediated encryption violates the end-to-end > > principle. It also allows ISP's to violate net neutrality principles > > as well (i.e., by allowing them to do deep packet inspection and then > > prioritizing some traffic over others). > > Two things here (probably wandering into a minefield, but that's my ball > that > rolled in): > > 1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regulators, > morals, > or encryption of the pieces that might be deeply inspected. > You might as well say that not shooting elephants allows ISPs to do DPI! > So, I think what you are saying is that not doing IPsec on your (IP) > traffic > allows the ISP to do DPI. > But doing MPLS encryption also stops transit nodes from doing DPI, but it > does > not stop edge (i.e., MPLS end) nodes from doing DPI. > In some deployments (carrier's carrier, MPLS-based enterprise over ISP) the > traffic may already be MPLS, and so MPLS encryption might be what is > available. > > 2. I think the end-to-end principle may already have been somewhat diluted > by > the introduction of edges, and the deployment of tunnels. I am guessing > that you > mean that the responsibility for securing traffic lies with the > originator/consumer of the traffic. And that is largely fine, but again > runs > into VPN type discussions. > People should read the end-to-end paper before they recite it as holy lore. End to end is an argument about the consequences of where a design places complexity. It only considers the end and the center of the network. The edge is not really acknowledged as an option because it didn't exist when the paper was written. Mail has not been end-to-end for at least 20 years. It turned into an end-to-edge-to-end protocol in the mid 90s and it has been an edge-to-edge affair since SUBMIT and IMAP became the norm. The end to end argument is useful but end-to-end ideology is positively harmful. End to end ideology in security is particularly harmful because there are some security controls that are simply not compatible with end-to-end approaches. You cannot protect against traffic or meta-data analysis end-to-end. Rather than contrast S/MIME and PGP being 'end-to-end' protocols against STARTTLS being transport, it is rather more useful to recognize that S/MIME and PGP are data level security rather than transport layer. S/MIME provides end-to-end security but not metadata security. But people seem to have largely missed the fact that S/MIME is actually capable of providing data level security as a superset of end-to-end. Why don't Word and Excel etc. just save all their documents in encrypted CMS envelopes by default? Shouldn't this be a priority now we are moving to the cloud? -- Website: http://hallambaker.com/ --089e0112bfceb094d704f017a3d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 14, 2014 at 7:23 AM, Adrian Farrel &l= t;adrian@olddog.co= .uk> wrote:
> > >It helps against some attacks,= but it doesn't help for others, right?
> > >After all, if you are a US national, you might not trust that= the
> > >Chinese Telecom won't pass your traffic to the MSS. =A0(O= r if you are a
> > >German national, that AT&T won't decrypto your traffi= c and then pass
> > >it off to the NSA...)
> > yep. IPsec, under the control of a subscriber, offers more protec= tion,
> > in princple.
>
> Or put another way, MPLS-mediated encryption violates the end-to-end > principle. =A0It also allows ISP's to violate net neutrality princ= iples
> as well (i.e., by allowing them to do deep packet inspection and then<= br> > prioritizing some traffic over others).

Two things here (probably wandering into a minefield, but that's my bal= l that
rolled in):

1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regu= lators, morals,
or encryption of the pieces that might be deeply inspected.
You might as well say that not shooting elephants allows ISPs to do DPI! So, I think what you are saying is that not doing IPsec on your (IP) traffi= c
allows the ISP to do DPI.
But doing MPLS encryption also stops transit nodes from doing DPI, but it d= oes
not stop edge (i.e., MPLS end) nodes from doing DPI.
In some deployments (carrier's carrier, MPLS-based enterprise over ISP)= the
traffic may already be MPLS, and so MPLS encryption might be what is availa= ble.

2. I think the end-to-end principle may already have been somewhat diluted = by
the introduction of edges, and the deployment of tunnels. I am guessing tha= t you
mean that the responsibility for securing traffic lies with the
originator/consumer of the traffic. And that is largely fine, but again run= s
into VPN type discussions.

People shoul= d read the end-to-end paper before they recite it as holy lore.
<= br>
End to end is an argument about the consequences of where a d= esign places complexity. It only considers the end and the center of the ne= twork. The edge is not really acknowledged as an option because it didn'= ;t exist when the paper was written.

Mail has not been end-to-end for at least 20 years. It = turned into an end-to-edge-to-end protocol in the mid 90s and it has been a= n edge-to-edge affair since SUBMIT and IMAP became the norm.=A0

The end to end argument is useful but end-to-end ideology is= positively harmful.


End to end ide= ology in security is particularly harmful because there are some security c= ontrols that are simply not compatible with end-to-end approaches. You cann= ot protect against traffic or meta-data analysis end-to-end.

Rather than contrast S/MIME and PGP being 'end-to-e= nd' protocols against STARTTLS being transport, it is rather more usefu= l to recognize that S/MIME and PGP are data level security rather than tran= sport layer.=A0

S/MIME provides end-to-end security but not metadata se= curity. But people seem to have largely missed the fact that S/MIME is actu= ally capable of providing data level security as a superset of end-to-end.<= /div>

Why don't Word and Excel etc. just save all their d= ocuments in encrypted CMS envelopes by default? Shouldn't this be a pri= ority now we are moving to the cloud?

--
Website: http://hallambaker.com/
--089e0112bfceb094d704f017a3d6-- From joe@cdt.org Thu Jan 16 08:39:07 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35B61AE3A4 for ; Thu, 16 Jan 2014 08:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgs4e5fmvHEX for ; Thu, 16 Jan 2014 08:39:05 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 466AA1AE39A for ; Thu, 16 Jan 2014 08:39:05 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for perpass@ietf.org; Thu, 16 Jan 2014 11:38:51 -0500 Message-ID: <52D80B1A.8060100@cdt.org> Date: Thu, 16 Jan 2014 11:38:50 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:39:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/16/14, 9:57 AM, Phillip Hallam-Baker wrote: > Rather than contrast S/MIME and PGP being 'end-to-end' protocols > against STARTTLS being transport, it is rather more useful to > recognize that S/MIME and PGP are data level security rather than > transport layer. I like how the recent Barnes et al. draft refers to this as "object encryption." best, joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS2AsaAAoJEF+GaYdAqahx7Q0P/3Tvemqhj7Q+R9tjSFqOA7pn 4JtaWThJEPjVGXgPnx+kSts0p6x6c4cfgdKV2GMYT/88djC5SS1VAx+Xa/dMWuID 0bao6mzLV5x08GQFNWqbtypf9loOVXc7vKqf1f4GHt+SY3ihzVX7lxEEZldYOg1q SCT8s6LA5BHudtyyFG3Fo/Qoi7jrDCM6ees4nDy0CbjnWFvgBNYp0ZPmNfIhBkSz 5Pc8+Jw4oT2EeWZO5PXvVD54hkmDhGeWJLoCx+7FGY9fbDixzxl1pir1t+1WWllj 6EP8uh+dhWs9pmJEROR+TESyZP1j3+0hfpDm/4YDQbBSFeo3mTRVmGyLAQuA/GxU xOZEYwTduRY94YC5Cp6VYH3dqAzGcgED21CiKg26fokI7/gJS6xKkbX905PDKfzk xVq3CIm9cnJHWtpeZjeNs3tzPH4Nb2ol2fU5dTllUuT/coDJrDxkAyCbeMeYoELC TcKnyodlpz7Cwvtm205Kcj32FRChfsqceGr/KtYD4UUNazp0iZUP7ibb6EXG/Emb MuQTicry8oKulNPqcjytkF70iFFzlUKNAKngQVajJsFD/thc78k9p1C6rbBg2TMH iq+2Vk62x6hKSVpTZb7CrlBUXz0aQIhWx6pEvx53Ha7lAz5ve7C6pl3u4LMYxF8E zaiMEHxd7SVscEUWOLoC =yDWx -----END PGP SIGNATURE----- From tytso@thunk.org Thu Jan 16 11:23:39 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54131AC49D for ; Thu, 16 Jan 2014 11:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1950UtnlO9d for ; Thu, 16 Jan 2014 11:23:38 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id DE6C41AC499 for ; Thu, 16 Jan 2014 11:23:37 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1W3sXB-0005oY-IL; Thu, 16 Jan 2014 19:23:21 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id CB847580688; Thu, 16 Jan 2014 14:23:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1389900200; bh=r6KqxRDUgSIXgDKKE98p7pEAZ99BWdEWs96pZKTWnds=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fXULcEKjAYk7zNsyUEM78zRkWtBIfKoMJ05tU0O8BUNHiIKYUr5h7meV3/DyEFFzx odtVn/od5Y+jf61LRJHS0rklwyPnYXj8y1aRzGY9Qq/uPXOZ66gcujDfP/K41f3M9m 2Bm/CazdwRYnbtQLkW2FGDfZ4At188Vv9/fb4IUg= Date: Thu, 16 Jan 2014 14:23:20 -0500 From: Theodore Ts'o To: Phillip Hallam-Baker Message-ID: <20140116192320.GD32098@thunk.org> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: Adrian Farrel , perpass , Stephen Kent Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:23:39 -0000 On Thu, Jan 16, 2014 at 09:57:07AM -0500, Phillip Hallam-Baker wrote: > End to end ideology in security is particularly harmful because there are > some security controls that are simply not compatible with end-to-end > approaches. You cannot protect against traffic or meta-data analysis > end-to-end. That may be true, but the alternative of edge-to-edge security is even worse. Edge-to-edge security also doesn't protect against traffic or meta-data analysis, and upon receipt of a National Security Letter to your IMAP provider, doesn't protect the contents of your e-mail, either. So I don't see how claiming that striving for end-to-end security is "harmful". Best, - Ted From dhc@dcrocker.net Thu Jan 16 12:29:01 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D331ABBB1 for ; Thu, 16 Jan 2014 12:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFUBNAGuEvOL for ; Thu, 16 Jan 2014 12:29:00 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E1E241A16F0 for ; Thu, 16 Jan 2014 12:28:59 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0GKSWtU009680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jan 2014 12:28:35 -0800 Message-ID: <52D840E7.2010706@dcrocker.net> Date: Thu, 16 Jan 2014 12:28:23 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joseph Lorenzo Hall , perpass@ietf.org References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <52D80B1A.8060100@cdt.org> In-Reply-To: <52D80B1A.8060100@cdt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 16 Jan 2014 12:28:35 -0800 (PST) Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:29:01 -0000 On 1/16/2014 8:38 AM, Joseph Lorenzo Hall wrote: > I like how the recent Barnes et al. draft refers to this as "object > encryption." best, joe Indeed, channel vs. object protection is long-standing terminology for the distinction. Separately, note that "end-to-end" can refer to different end-points. The gateway to an end-users administrative network is a reasonable example of an end, for some considerations. Equally, a mailbox isn't necessary and end-point, when talking about applications that interact via email, since the application might have additional transit, beyond email. (That's not hypothetical. Electronic Data Interchange [EDI] demonstrated this point.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Thu Jan 16 13:30:34 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626211AD8C4 for ; Thu, 16 Jan 2014 13:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24KU52quRcyi for ; Thu, 16 Jan 2014 13:30:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 32DD91AD739 for ; Thu, 16 Jan 2014 13:30:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1083BE20; Thu, 16 Jan 2014 21:30:17 +0000 (GMT) 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 3r471bGC355R; Thu, 16 Jan 2014 21:30:16 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.42.25.131]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4559EBDF9; Thu, 16 Jan 2014 21:30:16 +0000 (GMT) Message-ID: <52D84F68.7030100@cs.tcd.ie> Date: Thu, 16 Jan 2014 21:30:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Theodore Ts'o , Phillip Hallam-Baker References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> In-Reply-To: <20140116192320.GD32098@thunk.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , perpass , Stephen Kent Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 21:30:34 -0000 Hi Ted, On 01/16/2014 07:23 PM, Theodore Ts'o wrote: > That may be true, but the alternative of edge-to-edge security is even > worse. I'm fairly sure you don't mean it that way, but just in case... We'll really be better off not to be talking as if end-to-end (or object) and hop-by-hop (channel) security were mutually exclusive - "the alternative" sort of implies that. And there are different hops or channels as well, e.g. if I run IMAP/TLS whilst on an IPsec VPN etc etc. Or see the discussion between Adrian and Steve Kent on our draft. So those are also options and not mutually exclusive. One take away from a lot of the snowdonia stuff is that we should have well defined interoperable and ideally easy to deploy ways to do security at *every* level since every single option will work best for someone somewhere. For example, when the tcpcrypt folks turned up at the IETF a couple of years ago I was against it really. That was mostly because I figured we already had TLS so why would we want another thing that's so similar but partly because they were selling it as "better" than TLS. I've now concluded that I was wrong about that and am encouraging them as I can. And our draft is meant to be the same - another tool for the tool-box. (Well, assuming it turns out to be a useful tool, which is still not yet known.) Cheers, S. From hallam@gmail.com Thu Jan 16 14:19:48 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86DD1AD8DA for ; Thu, 16 Jan 2014 14:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBZiGGKpH9H3 for ; Thu, 16 Jan 2014 14:19:46 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 37E5F1AD739 for ; Thu, 16 Jan 2014 14:19:46 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id el20so516530lab.20 for ; Thu, 16 Jan 2014 14:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DZ3TNaQhgRCcqAWITO0v20l8k2CoqmC4QgJYcPwcp6o=; b=Txh7hDNjQhkLrA2AW7RI6HgdXX4UKlLPMUMt6hXR90oS0tSmmZUcfFxtzZLuJ2pyqO +e6UPtu3X3bHJZWP0JdFTPr1m203i6H415lgvZV/k3l2rjxeuvHeeZ9qh5leSRAvmwR0 Z++So0+SQKFR7oKwfYHa6JHaWOArYgSeBZuIhN2sEG7awQuMR+VmscvW3zOncwNn42y1 jbQsp0EBXA0ZZ4gLOCe6aUvK9RVLEFrI9anDm78FSiyGfb+BR8tzeeyK8DgeujGVrV6F gaqc4Sj6TkKGm8l94W/IYNKt4uvOnpSYR/BBSNpHdOVvrifhyChwF7qTwp+OCuntKuBM mU3A== MIME-Version: 1.0 X-Received: by 10.152.22.201 with SMTP id g9mr6469318laf.27.1389910773241; Thu, 16 Jan 2014 14:19:33 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 16 Jan 2014 14:19:32 -0800 (PST) In-Reply-To: <20140116192320.GD32098@thunk.org> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> Date: Thu, 16 Jan 2014 17:19:32 -0500 Message-ID: From: Phillip Hallam-Baker To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary=089e0158c308e89d5e04f01dd174 Cc: Adrian Farrel , perpass , Stephen Kent Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 22:19:49 -0000 --089e0158c308e89d5e04f01dd174 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 16, 2014 at 2:23 PM, Theodore Ts'o wrote: > On Thu, Jan 16, 2014 at 09:57:07AM -0500, Phillip Hallam-Baker wrote: > > End to end ideology in security is particularly harmful because there are > > some security controls that are simply not compatible with end-to-end > > approaches. You cannot protect against traffic or meta-data analysis > > end-to-end. > > That may be true, but the alternative of edge-to-edge security is even > worse. Edge-to-edge security also doesn't protect against traffic or > meta-data analysis, and upon receipt of a National Security Letter to > your IMAP provider, doesn't protect the contents of your e-mail, > either. > > So I don't see how claiming that striving for end-to-end security is > "harmful". > Arguing for end to end security at the exclusion of transport models is harmful. Looking at NSLs as the attack paradigm is unwise as we don't currently have any IETF countermeasure. Not PGP, not S/MIME, not STARTTLS. You are free to propose one but it certainly won't be an end to end security solution because the internet infrastructure that is routing packets and messages needs to know the direction to send them in. PGP and S/MIME are both unable to protect meta-data against an attacker with intercept capability. STARTTLS is unable to protect content against attack by a corrupt system administrator. To have comprehensive security we need both the End 2 End security to protect the data at rest and the transport layer security to protect the metadata in motion. -- Website: http://hallambaker.com/ --089e0158c308e89d5e04f01dd174 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 16, 2014 at 2:23 PM, Theodore Ts'o <tytso@mit.edu&= gt; wrote:
On Thu, Jan 16, 2014 at 09= :57:07AM -0500, Phillip Hallam-Baker wrote:
> End to end ideology in security is particularly harmful because there = are
> some security controls that are simply not compatible with end-to-end<= br> > approaches. You cannot protect against traffic or meta-data analysis > end-to-end.

That may be true, but the alternative of edge-to-edge security is eve= n
worse. =A0Edge-to-edge security also doesn't protect against traffic or=
meta-data analysis, and upon receipt of a National Security Letter to
your IMAP provider, doesn't protect the contents of your e-mail,
either.

So I don't see how claiming that striving for end-to-end security is "harmful".


Arg= uing for end to end security at the exclusion of transport models is harmfu= l.

Looking at NSLs as the attack paradigm is unwis= e as we don't currently have any IETF countermeasure. Not PGP, not S/MI= ME, not STARTTLS. You are free to propose one but it certainly won't be= an end to end security solution because the internet infrastructure that i= s routing packets and messages needs to know the direction to send them in.= =A0

PGP and S/MIME are both unable to protect meta-data aga= inst an attacker with intercept capability. =A0

ST= ARTTLS is unable to protect content against attack by a corrupt system admi= nistrator.


To have comprehensive security we = need both the End 2 End security to protect the data at rest and the transp= ort layer security to protect the metadata in motion.

--
Website: http://hallambaker.com/=
--089e0158c308e89d5e04f01dd174-- From huitema@huitema.net Thu Jan 16 22:23:07 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33631ADF85 for ; Thu, 16 Jan 2014 22:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGZAlBKMReUB for ; Thu, 16 Jan 2014 22:23:05 -0800 (PST) Received: from xsmtp04.mail2web.com (xsmtp24.mail2web.com [168.144.250.190]) by ietfa.amsl.com (Postfix) with ESMTP id 389BC1ADF76 for ; Thu, 16 Jan 2014 22:23:05 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1W42pP-0000PR-Fl for perpass@ietf.org; Fri, 17 Jan 2014 01:22:52 -0500 Received: (qmail 31898 invoked from network); 17 Jan 2014 06:22:50 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Jan 2014 06:22:50 -0000 From: "Christian Huitema" To: "'Phillip Hallam-Baker'" , "'Theodore Ts'o'" References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> In-Reply-To: Date: Thu, 16 Jan 2014 22:22:47 -0800 Message-ID: <021301cf134c$8bcc54a0$a364fde0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQF0Acy8YdaXXCAmfcgNFLBaLQGzOQKyuo5sAtdBCbYCc0fKFZr+qV1Q Content-Language: en-us Cc: 'Adrian Farrel' , 'perpass' , 'Stephen Kent' Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 06:23:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > PGP and S/MIME are both unable to protect meta-data against an = attacker with intercept capability. =20 > > STARTTLS is unable to protect content against attack by a corrupt = system administrator. > > To have comprehensive security we need both the End 2 End security to = protect the data at rest > and the transport layer security to protect the metadata in motion. Well, yes, of course. But we also have to start somewhere. STARTTLS is = reasonably easy to deploy, and many mail services are either already = deploying it or are in the process of deploying it. The channel = protection with STARTTLS will not protect against compromised servers, = and will not prevent providers to comply with national security letters = and other subpoenas. But it will prevent the bulk collection of message = headers by tapping links, and that's a very good first step. - -- Christian Huitema -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJS2Mw2AAoJELba05IUOHVQdHwH/RSjp+nR91GMvR9pOOh+axwg Nyaw7EN6EXjsNyY22Ai2Zg993kBCdva4GXiIbmbTJjdpdjO76KLYJWQli7V78+Et ZvrHHVedv0HAU9VthpYcKhfFcbNjnxy8pDWvFOF/UszQUXFk8QB8bZLLndHXBEEP HggaKjVVda5/jCq/jMRIDVk8HyToIUwJaeWysv/U56T56rYiMkXOhnaRQXVYJJ1F SS1tq29M0LKi7+copWNZjBO7keIfnbESs3k3Fc8GPJSW3F8+WoPZlbXGF4SAZFdw bhtNQ8PKjAqMOmnoyP/NC0SZZY/Ck0vP40SV891AeTMwY3g6now2YXUzob6poRw=3D =3DdoiO -----END PGP SIGNATURE----- From hallam@gmail.com Fri Jan 17 04:51:11 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3061AE0A6 for ; Fri, 17 Jan 2014 04:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0KzL5P1dS9B for ; Fri, 17 Jan 2014 04:51:09 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7783E1ADF76 for ; Fri, 17 Jan 2014 04:51:09 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so2999361lbi.0 for ; Fri, 17 Jan 2014 04:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YLVRuWQU/ag+T4gfXyMY/ec6H+KaWPBUxPFGj4nKOBY=; b=wotxu7ErtQuXmgQpc5kgi+lr4P0dq7sokMzXll0mnYaJLAQDbfe1wQ5/RTd4WZkd+K 9ZJ8RWwVxagvATTK0Rg/gakFywf/FN75zthkSEviSBAsh/1xReH8mnb+GUC22lNxaVXM m4XDIWtawc5WWm/jgBQ+YqXmnEFpyZVgnSN9CM8IPljpqGq43Ls4OgB6rN3QO0cAzBZF M1egsVGAB8bLuKa2h1IG8tlB1ZOBpOACOe/0hPLrP/um7tQZdYRqqK2ArRJPnSS2baeo jAxO7JmyROkyCj+LbzYamOc4UzMuXSXuhbMy0oO4HGRUaCepN7XHIOzjP3dr+IgL0l+W jW4w== MIME-Version: 1.0 X-Received: by 10.112.148.70 with SMTP id tq6mr949523lbb.40.1389963056305; Fri, 17 Jan 2014 04:50:56 -0800 (PST) Received: by 10.112.37.172 with HTTP; Fri, 17 Jan 2014 04:50:56 -0800 (PST) In-Reply-To: <021301cf134c$8bcc54a0$a364fde0$@huitema.net> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <021301cf134c$8bcc54a0$a364fde0$@huitema.net> Date: Fri, 17 Jan 2014 07:50:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Christian Huitema Content-Type: multipart/alternative; boundary=047d7b3a887238de4d04f029feab Cc: Adrian Farrel , perpass , Theodore Ts'o , Stephen Kent Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 12:51:12 -0000 --047d7b3a887238de4d04f029feab Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 17, 2014 at 1:22 AM, Christian Huitema wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > PGP and S/MIME are both unable to protect meta-data against an attacker > with intercept capability. > > > > STARTTLS is unable to protect content against attack by a corrupt system > administrator. > > > > To have comprehensive security we need both the End 2 End security to > protect the data at rest > > and the transport layer security to protect the metadata in motion. > > Well, yes, of course. But we also have to start somewhere. STARTTLS is > reasonably easy to deploy, and many mail services are either already > deploying it or are in the process of deploying it. The channel protection > with STARTTLS will not protect against compromised servers, and will not > prevent providers to comply with national security letters and other > subpoenas. But it will prevent the bulk collection of message headers by > tapping links, and that's a very good first step. > Which was my argument. Except that there is nothing STARTTLS or PGP or S/MIME can do against a national security letter demanding metadata from a server. So it is fine to use NSLs as an argument for doing more than STARTTLS, it is not an argument for doing PGP or S/MIME instead. The law authorizing NSLs does limit them to metadata in theory but we don't have any evidence to suggest that they are not widely abused and used for content and there are plenty of reasons to distrust agencies of a government that was engaged in torture under the previous administration. The SMTP SEND, RCPT (and to a lesser degree RFC822 header) data has to be public for the system to work. I think I have a scheme that sorts out the usability catastrophe and trust model limitations of the End to End model. What I was saying is that doing that does not eliminate the need for STARTTLS. We can discuss mechanisms for dealing with NSLs but I don't think that is productive until we have the E2E issue solved in practice rather than a large scale science project. A million users is not enough on a network with a billion users. My PPE scheme does provide a hole where someone can wire in a scheme that protects metadata and has protection against traffic analysis. But that isn't something I would make a priority at this stage. -- Website: http://hallambaker.com/ --047d7b3a887238de4d04f029feab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 17, 2014 at 1:22 AM, Christian Huitema <huitema@huit= ema.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> PGP and S/MIME are both unable to protect meta-data against an attacke= r with intercept capability.
>
> STARTTLS is unable to protect content against attack by a corrupt syst= em administrator.
>
> To have comprehensive security we need both the End 2 End security to = protect the data at rest
> and the transport layer security to protect the metadata in motion.
Well, yes, of course. But we also have to start somewhere. STARTTLS i= s reasonably easy to deploy, and many mail services are either already depl= oying it or are in the process of deploying it. The channel protection with= STARTTLS will not protect against compromised servers, and will not preven= t providers to comply with national security letters and other subpoenas. B= ut it will prevent the bulk collection of message headers by tapping links,= and that's a very good first step.

Which was my argument.

Except that there is nothing STARTTLS or PGP or S/MIME can do against= a national security letter demanding metadata from a server. So it is fine= to use NSLs as an argument for doing more than STARTTLS, it is not an argu= ment for doing PGP or S/MIME instead.

The law authorizing NSLs does limit them to metadata in= theory but we don't have any evidence to suggest that they are not wid= ely abused and used for content and there are plenty of reasons to distrust= agencies of a government that was engaged in torture under the previous ad= ministration.

The SMTP SEND, RCPT (and to a lesser degree RFC822 head= er) data has to be public for the system to work.

=
I think I have a scheme that sorts out the usability catastr= ophe and trust model limitations of the End to End model. What I was saying= is that doing that does not eliminate the need for STARTTLS.

We can discuss mechanisms for dealing with NSLs b= ut I don't think that is productive until we have the E2E issue solved = in practice rather than a large scale science project. A million users is n= ot enough on a network with a billion users.=A0

My PPE scheme does provide a hole where someone can wir= e in a scheme that protects metadata and has protection against traffic ana= lysis. But that isn't something I would make a priority at this stage.<= /div>

--
Website: http://h= allambaker.com/
--047d7b3a887238de4d04f029feab-- From oritl@microsoft.com Fri Jan 17 22:32:15 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340F1ADEB7 for ; Fri, 17 Jan 2014 22:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4Pzla5cUdOi for ; Fri, 17 Jan 2014 22:32:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id C83E11ADE72 for ; Fri, 17 Jan 2014 22:32:12 -0800 (PST) Received: from BY2PR03MB300.namprd03.prod.outlook.com (10.141.139.24) by BY2PR03MB299.namprd03.prod.outlook.com (10.141.139.21) with Microsoft SMTP Server (TLS) id 15.0.851.11; Sat, 18 Jan 2014 06:31:58 +0000 Received: from BY2PR03MB300.namprd03.prod.outlook.com ([10.141.139.24]) by BY2PR03MB300.namprd03.prod.outlook.com ([10.141.139.24]) with mapi id 15.00.0851.011; Sat, 18 Jan 2014 06:31:58 +0000 From: "Orit Levin (LCA)" To: "perpass@ietf.org" Thread-Topic: Proposed list of deliverables Thread-Index: Ac8UFmYji/VA3VmEQGKaaXEQ6c6LRQ== Date: Sat, 18 Jan 2014 06:31:57 +0000 Message-ID: <06cc9b13e6024b39b619c6a26710f4f4@BY2PR03MB300.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.247.123.117] x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(679001)(779001)(689001)(13464003)(199002)(189002)(164054003)(377454003)(69234005)(31966008)(93136001)(92566001)(74502001)(93516002)(74662001)(47446002)(76176001)(56776001)(79102001)(81542001)(77982001)(59766001)(81342001)(76786001)(76796001)(76576001)(66066001)(65816001)(80022001)(54316002)(74316001)(74876001)(74706001)(63696002)(69226001)(74366001)(49866001)(47736001)(85852003)(51856001)(81686001)(53806001)(47976001)(83072002)(50986001)(4396001)(33646001)(46102001)(87266001)(87936001)(15975445006)(80976001)(2656002)(56816005)(81816001)(90146001)(19580395003)(19580405001)(83322001)(54356001)(76482001)(85306002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB299; H:BY2PR03MB300.namprd03.prod.outlook.com; CLIP:98.247.123.117; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [perpass] UTA: Proposed list of deliverables X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 06:32:15 -0000 FYI and let's keep this thread on the UTA list. Thanks, Orit. -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Orit Levin (LCA) Sent: Friday, January 17, 2014 10:25 PM To: uta@ietf.org Cc: Pete Resnick; Barry Leiba Subject: [Uta] Proposed list of deliverables Below is the list of deliverables for your consideration: 1. A threat analysis document containing a collection of known security bre= aches to application protocols due to poor use of TLS (Likely an Informatio= nal RFC) 2. Applications' independent document recommending best existing a= nd future practices for using TLS (Likely a BCP or a Proposed Standard RFC)= 3. A set of documents, each describing best existing and future practices = for using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, = XMPP, HTTP 1.1, etc. (Case-by-case likely a BCP or a Proposed Standard RFC)= 4. A document discussing (and potentially defining) how to apply the oppor= tunistic encryption approach (preliminary outlined in draft-farrelll-mpls-o= pportunistic-encrypt-00.txt) to TLS. (Category TBD) Please, send your feedback to the list (including short +1s to indicate tha= t the direction makes sense to you). Thanks, Leif and Orit - the chairs. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From gip-perpass@m.gmane.org Fri Jan 17 22:55:20 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52E1A1F56 for ; Fri, 17 Jan 2014 22:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFUcnM7iellF for ; Fri, 17 Jan 2014 22:55:19 -0800 (PST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7200B1A1F1F for ; Fri, 17 Jan 2014 22:55:19 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W4Po8-00013Z-4z for perpass@ietf.org; Sat, 18 Jan 2014 07:55:04 +0100 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jan 2014 07:55:04 +0100 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jan 2014 07:55:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: perpass@ietf.org From: Alex Elsayed Date: Tue, 14 Jan 2014 01:18:38 -0800 Lines: 24 Message-ID: References: <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D40D16.7060307@bbn.com> <20140113161349.GA22541@thunk.org> <52D41A06.2000008@bbn.com> <20140113185350.GA23463@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-50-132-41-203.hsd1.wa.comcast.net User-Agent: KNode/4.12 Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 06:55:20 -0000 Theodore Ts'o wrote: > On Mon, Jan 13, 2014 at 11:53:26AM -0500, Stephen Kent wrote: >> >It helps against some attacks, but it doesn't help for others, right? >> >After all, if you are a US national, you might not trust that the >> >Chinese Telecom won't pass your traffic to the MSS. (Or if you are a >> >German national, that AT&T won't decrypto your traffic and then pass >> >it off to the NSA...) >> yep. IPsec, under the control of a subscriber, offers more protection, >> in princple. > > Or put another way, MPLS-mediated encryption violates the end-to-end > principle. It also allows ISP's to violate net neutrality principles > as well (i.e., by allowing them to do deep packet inspection and then > prioritizing some traffic over others). > > - Ted On the other hand, encryption occurring at the MPLS layer in the ISP in no way prevents someone from using IPsec for traffic that ISP carries - in fact, there are cases (ISP wishes to prevent parties from eavedropping without the ISP's signoff while customer wishes to prevent eavesdropping period; possibly others) where the incentives would naturally support the deployment of both. From scott.brim@gmail.com Sat Jan 18 13:08:13 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFBA1ADFBD for ; Sat, 18 Jan 2014 13:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd4nTgw6SP0b for ; Sat, 18 Jan 2014 13:08:11 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id AC0111ADFBC for ; Sat, 18 Jan 2014 13:08:11 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so1294838oag.7 for ; Sat, 18 Jan 2014 13:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=Pz+cPcnS8nbas1+8n8fr1hK1qhhKo8UajKm91zOa5Es=; b=PklgsqpUGau6yK8Jm+m06kbSRWil52ZZoaRcRy1kw+K/NuGb3TfYPFJysi8k7IOOVU fQ/G9nR+7Q+mH05cVoqtXa7D9N/8L1bj2T/R02V+hJmg7tXdp2idYT9zDO/2FtLOZLiy inkV1kd5vWJ0Ll7YrSxeNy1+v7QBV0oojsWWJUcMItNGATGZdHrAFr9GRayEcdmdAvAF W9hlcZqdazoS4iqJqfatCTtdnjr6kmbDxD9Rj8//dN21/AH7pdpdKaa4JHAWqND4pydW rgacfXvw8slWeJSIQF8q+W0AJdkFnpaNdzjZRftL2SW715D0eTQqgHIXSe79lDPozeR9 rr3A== X-Received: by 10.60.220.199 with SMTP id py7mr8018272oec.26.1390079278715; Sat, 18 Jan 2014 13:07:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Sat, 18 Jan 2014 13:07:38 -0800 (PST) From: Scott Brim Date: Sat, 18 Jan 2014 16:07:38 -0500 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=001a113671a89e434b04f0450de3 Cc: perpass Subject: [perpass] draft-johansson-linkability-bad-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 21:08:13 -0000 --001a113671a89e434b04f0450de3 Content-Type: text/plain; charset=ISO-8859-1 Leif: excellent. Sorry I won't be at STRINT. Scott --001a113671a89e434b04f0450de3 Content-Type: text/html; charset=ISO-8859-1
Leif: excellent.

Sorry I won't be at STRINT.

Scott

--001a113671a89e434b04f0450de3-- From jari.arkko@piuha.net Sun Jan 19 05:04:01 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF061ADF26; Sun, 19 Jan 2014 05:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T53WdogRp6qs; Sun, 19 Jan 2014 05:03:59 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2B1AD7C1; Sun, 19 Jan 2014 05:03:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C73232CC5F; Sun, 19 Jan 2014 15:03:43 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywbBqCZpZdIN; Sun, 19 Jan 2014 15:03:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3441D2CC48; Sun, 19 Jan 2014 15:03:43 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: Date: Sun, 19 Jan 2014 15:03:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00DB0CC4-5E6A-483C-8E18-B24526CAED71@piuha.net> References: <52D43E69.6090001@cs.tcd.ie> To: Scott Brim X-Mailer: Apple Mail (2.1510) Cc: perpass , "Fred Baker \(fred\)" , IETF-Discussion Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 13:04:02 -0000 > The main problem is that: privacy issues are deeper than that, the > question could be misunderstood without a larger context, and there's > already a set of documents discussing most of that larger context (RFC > 6973, the perpass problem statement draft, etc.). >=20 > The Document Shepherd Write-Up currently doesn't reference security > guidelines directly. Instead of asking a few specific questions in the > shepherd's writeup as you suggest, consider adding the privacy/perpass > docs to BCP 72 (which already includes RFC 3552) as they are approved, > and then optionally add a question to the shepherd's writeup that > refers to it, in order to emphasize the increased attention to the > issue. FWIW, I do not feel strongly about this topic but my personal opinion is = that if we do something with the shepherd write-up, it should be on the = general level outlined by Scott above. (But I think the documents = themselves are more important than the write-ups. A few years down the = road, I'm sure the reader like to know what the thinking on security was = on such and such RFC. On any aspect of security, PM or otherwise. When = there's something to say, of course, which isn't always.) Jari From kent@bbn.com Mon Jan 20 07:11:53 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4401A0186 for ; Mon, 20 Jan 2014 07:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0upJIvIQ2Nj8 for ; Mon, 20 Jan 2014 07:11:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B91A00DE for ; Mon, 20 Jan 2014 07:11:46 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54468) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5GVk-000O75-Gc; Mon, 20 Jan 2014 10:11:36 -0500 Message-ID: <52DD3CAA.6010004@bbn.com> Date: Mon, 20 Jan 2014 10:11:38 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , Theodore Ts'o , Phillip Hallam-Baker References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> In-Reply-To: <52D84F68.7030100@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , perpass Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:11:53 -0000 Stephen, > Hi Ted, > > On 01/16/2014 07:23 PM, Theodore Ts'o wrote: >> That may be true, but the alternative of edge-to-edge security is even >> worse. > I'm fairly sure you don't mean it that way, but just in case... > > We'll really be better off not to be talking as if end-to-end > (or object) and hop-by-hop (channel) security were mutually > exclusive - "the alternative" sort of implies that. > > And there are different hops or channels as well, e.g. if I > run IMAP/TLS whilst on an IPsec VPN etc etc. Or see the > discussion between Adrian and Steve Kent on our draft. So > those are also options and not mutually exclusive. no, they are not, but having a plethora of security options available does not mean that, on a pairwise basis, one will be able to invoke any of them. (Assuming that we are sticking with mandatory to implement, not mandatory to use). > One take away from a lot of the snowdonia stuff is that we > should have well defined interoperable and ideally easy to > deploy ways to do security at *every* level since every single > option will work best for someone somewhere. maybe. > For example, when the tcpcrypt folks turned up at the IETF a > couple of years ago I was against it really. That was mostly > because I figured we already had TLS so why would we want > another thing that's so similar but partly because they were > selling it as "better" than TLS. I've now concluded that I > was wrong about that and am encouraging them as I can. I wish you wouldn't encourage them. I can easily see confusion and non-interoperability arising because of the need to choose between TLS and tcpcrypt. Steve From stephen.farrell@cs.tcd.ie Mon Jan 20 07:19:02 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79D1A01A0 for ; Mon, 20 Jan 2014 07:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd6LBNcFxsTp for ; Mon, 20 Jan 2014 07:19:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB581A019D for ; Mon, 20 Jan 2014 07:19:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C995BE47; Mon, 20 Jan 2014 15:19:00 +0000 (GMT) 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 8QBwAE80gIhe; Mon, 20 Jan 2014 15:19:00 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6BB43BE39; Mon, 20 Jan 2014 15:19:00 +0000 (GMT) Message-ID: <52DD3E64.2000707@cs.tcd.ie> Date: Mon, 20 Jan 2014 15:19:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Kent References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> In-Reply-To: <52DD3CAA.6010004@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:19:02 -0000 On 01/20/2014 03:11 PM, Stephen Kent wrote: >> For example, when the tcpcrypt folks turned up at the IETF a >> couple of years ago I was against it really. That was mostly >> because I figured we already had TLS so why would we want >> another thing that's so similar but partly because they were >> selling it as "better" than TLS. I've now concluded that I >> was wrong about that and am encouraging them as I can. > I wish you wouldn't encourage them. I can easily see confusion > and non-interoperability arising because of the need to choose > between TLS and tcpcrypt. I think its fair to say that the question of when tcpcrypt might be a better tool to use than TLS is an open one, and one where it'd be good to have some deployment experience before making recommendations. Speculating, I'd expect that if tcpcrypt were implemented in some kernels then it'd be useful in places where you can't feasibly use TLS. But that's me speculating and I'm sure the proponents of tcpcrypt can give you a better answer. S. From dcrocker@bbiw.net Mon Jan 20 07:27:32 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93141A01B5 for ; Mon, 20 Jan 2014 07:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ8Sr3iNmo0s for ; Mon, 20 Jan 2014 07:27:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89BA11A018D for ; Mon, 20 Jan 2014 07:27:31 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0KFRLWZ025569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jan 2014 07:27:24 -0800 Message-ID: <52DD404B.1080705@bbiw.net> Date: Mon, 20 Jan 2014 07:27:07 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , Stephen Kent References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> In-Reply-To: <52DD3E64.2000707@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Mon, 20 Jan 2014 07:27:24 -0800 (PST) Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:27:33 -0000 On 1/20/2014 7:19 AM, Stephen Farrell wrote: > I'd expect that if tcpcrypt were implemented in > some kernels then it'd be useful in places where you can't > feasibly use TLS. what are some examples of when this could occur? as long as there is speculation about this as a legitimate alternative, it would help to have the speculation include plausible examples. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Tue Jan 21 06:31:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97DA1A0152 for ; Tue, 21 Jan 2014 06:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17edadEXnxW8 for ; Tue, 21 Jan 2014 06:31:24 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB261A0151 for ; Tue, 21 Jan 2014 06:31:24 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id n15so5903766lbi.39 for ; Tue, 21 Jan 2014 06:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9C5iCiUKkY4Ycu0vZN72UacMVUW8ARQySIlKF279ZtM=; b=rKQ2tl9paOGgftONgpkWbM+CvCOa9t44WLQm3RaiGBKzJ632i87xgvt9IfTTY8wlZo n4tOY8+p4joxs/PTKQp9y/2b2g7Y06K+xGE8fGx8M3A0iOgYJUxKf35kEup6N8XXN/e1 eMYD+qD//FzCmQKJ62FsHJ5+QE4RpFWlF0165GlNH3zwWQwgoiqgwQ4mxfXOU8n3LAEC 7dOroRrWCK8uo8T6XkvsG6SVv/wMltMH6C7LHpCd1GGJUuWGeSD4DvWp7luqxQ1FfsGx /99h4xH5BaawoiAEAvUAfodK6EsmBXxwT943+g6xwfTP7l3ddcB765Mkpx1XR2MEgj+L pTRQ== MIME-Version: 1.0 X-Received: by 10.112.139.35 with SMTP id qv3mr1459475lbb.47.1390314683711; Tue, 21 Jan 2014 06:31:23 -0800 (PST) Received: by 10.112.37.172 with HTTP; Tue, 21 Jan 2014 06:31:23 -0800 (PST) In-Reply-To: <52DD404B.1080705@bbiw.net> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> Date: Tue, 21 Jan 2014 09:31:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=089e0115fb12d9467f04f07bdc09 Cc: perpass , Stephen Kent , Stephen Farrell Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:31:26 -0000 --089e0115fb12d9467f04f07bdc09 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 20, 2014 at 10:27 AM, Dave Crocker wrote: > On 1/20/2014 7:19 AM, Stephen Farrell wrote: > >> I'd expect that if tcpcrypt were implemented in >> some kernels then it'd be useful in places where you can't >> feasibly use TLS. >> > > > what are some examples of when this could occur? > > as long as there is speculation about this as a legitimate alternative, it > would help to have the speculation include plausible examples. tcpcrypt looks more like an alternative to IPSEC than TLS to me. Given that IPSEC has been a flop, working on an alternative twenty years later seems fine to me. The types of use case where I see problems with our current infrastructure are for applications such as wireless networking where WiFi security is still a usability disaster and remote access (aka dialup but we don't dialup any more). One major design limit in IPSEC and TLS is that both view the key exchange as being integral to the security layer rather than a separate service. I would like to separate out consideration of how chunks of data passing over the net are tagged and bagged for encryption and authentication from the question of key setup. There is no logical reason why the key negotiation for TLS, IPSEC and tcpcrypt cant be shared. -- Website: http://hallambaker.com/ --089e0115fb12d9467f04f07bdc09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 20, 2014 at 10:27 AM, Dave Crocker &l= t;dcrocker@bbiw.net<= /a>> wrote:
On 1/20/2014 7:19 AM, Step= hen Farrell wrote:
I'd expect that if tcpcrypt were implemented in
some kernels then it'd be useful in places where you can't
feasibly use TLS.


what are some examples of when this could occur?

as long as there is speculation about this as a legitimate alternative, it = would help to have the speculation include plausible examples.
=

tcpcrypt looks more like an alternative to IPSEC than T= LS to me.

Given that IPSEC has been a flop, working on an alterna= tive twenty years later seems fine to me.


The types of use case where I see problems with our current infrastr= ucture are for applications such as wireless networking where WiFi security= is still a usability disaster and remote access (aka dialup but we don'= ;t dialup any more).

One major design limit in IPSEC and TLS is that both vi= ew the key exchange as being integral to the security layer rather than a s= eparate service. I would like to separate out consideration of how chunks o= f data passing over the net are tagged and bagged for encryption and authen= tication from the question of key setup.

There is no logical reason why the key negotiation for = TLS, IPSEC and tcpcrypt cant be shared.=A0

<= br>
--
Website: http://hallamb= aker.com/
--089e0115fb12d9467f04f07bdc09-- From kent@bbn.com Tue Jan 21 07:25:43 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0375F1A02D8 for ; Tue, 21 Jan 2014 07:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBhAP2DjTvM1 for ; Tue, 21 Jan 2014 07:25:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 522FF1A0150 for ; Tue, 21 Jan 2014 07:25:41 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:44671 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5dCu-000Fe6-K9; Tue, 21 Jan 2014 10:25:40 -0500 Message-ID: <52DE9174.7000504@bbn.com> Date: Tue, 21 Jan 2014 10:25:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:25:43 -0000 PHB, ... > > One major design limit in IPSEC and TLS is that both view the key > exchange as being integral to the security layer rather than a > separate service. I would like to separate out consideration of how > chunks of data passing over the net are tagged and bagged for > encryption and authentication from the question of key setup. IKE is separate from ESP and AH. ESP and AH can be used independently of IKE, although manual keying is obviously not attractive in most cases. TLS is a different matter, in that the handshake that puts keys in place is integral to the data security protocol. However, DTLS is used with SRTP to secure VoIP, showing that the key exchange there can be used to support other protocols. > > There is no logical reason why the key negotiation for TLS, IPSEC and > tcpcrypt cant be shared. yes, it could be, despite the erroneous assertions above ;-) Steve From hallam@gmail.com Tue Jan 21 08:05:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2BE1A0360 for ; Tue, 21 Jan 2014 08:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_8fd4WrnjpM for ; Tue, 21 Jan 2014 08:05:14 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 883FE1A0346 for ; Tue, 21 Jan 2014 08:05:14 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so5611622lbi.35 for ; Tue, 21 Jan 2014 08:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c019JWwzMo8ptAKIo7sS13eu1/R9haK+M/1J2OhYkfI=; b=t+bkgWIEum9Xs9WyXJPkP4jCBnh0MOXgUC3cnL9P4d5figahQ8bhxChG7TufqZNw/O KYV2ggP0yJNOddHO0qiBkCfCa7GSFkuHwNmMDcmgnt6CHNhz14PmXd3NKNflQXoxI9bN 9kJp8KdqfnV9fi+MXCfTda4E3ZSUyUkaDIYnlbh4Q7Cwr/nmL18IhKCiSJv9fGt2Uox4 +U+9jOvAZLVIBEahf+Dec/fne2Eygs4qs02mKBS/lxxrOn9+fgwxG1k9xLEUFM6HZalS 5Iwd+jlaycw+7WuSn8wfE2BJfEUa1OynH/rmX/ZuTfts8CYP4ev8eBNFG1ikLODMUqg9 +72A== MIME-Version: 1.0 X-Received: by 10.112.139.72 with SMTP id qw8mr15997798lbb.16.1390320313649; Tue, 21 Jan 2014 08:05:13 -0800 (PST) Received: by 10.112.37.172 with HTTP; Tue, 21 Jan 2014 08:05:13 -0800 (PST) In-Reply-To: <52DE9174.7000504@bbn.com> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> Date: Tue, 21 Jan 2014 11:05:13 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=089e0112c1ba6b4fff04f07d2c47 Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:05:17 -0000 --089e0112c1ba6b4fff04f07d2c47 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 21, 2014 at 10:25 AM, Stephen Kent wrote: > PHB, > ... > > >> One major design limit in IPSEC and TLS is that both view the key >> exchange as being integral to the security layer rather than a separate >> service. I would like to separate out consideration of how chunks of data >> passing over the net are tagged and bagged for encryption and >> authentication from the question of key setup. >> > IKE is separate from ESP and AH. ESP and AH can be used independently of > IKE, although manual keying > is obviously not attractive in most cases. TLS is a different matter, in > that the handshake that > puts keys in place is integral to the data security protocol. However, > DTLS is used with SRTP > to secure VoIP, showing that the key exchange there can be used to support > other protocols. > > >> There is no logical reason why the key negotiation for TLS, IPSEC and >> tcpcrypt cant be shared. >> > yes, it could be, despite the erroneous assertions above ;-) > Please do not confuse your misunderstanding of my post with my knowledge of the circumstances. IKE is certainly not currently packaged up for use an independent service. Saying that this could be done is not the same as it having been done. The current IKE document begins as follows: Kaufman, et al. Standards Track [Page 4] RFC 5996 IKEv2bis September 2010 1 . Introduction IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. That is not how I expect a document describing an independent crypto protocol designed for use in other schemes to begin. Suggesting that the IETF adopt a practice of requiring re-use of such schemes in the security area is actually suggesting quite a major change in our approach. i.e. instead of having PGP and S/MIME sit in separate rooms defining two different message formats for secure email, require them to agree on one message format that can be used with both trust infrastructures. The idea that key exchange can be implemented as an independent Web Service is not something I expect to see in the IPSEC docs since the originals were written several years before the term was coined. -- Website: http://hallambaker.com/ --089e0112c1ba6b4fff04f07d2c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 21, 2014 at 10:25 AM, Stephen Kent &l= t;kent@bbn.com> wrote:
PHB,
...


One major design limit in IPSEC and TLS is that both view the key exchange = as being integral to the security layer rather than a separate service. I w= ould like to separate out consideration of how chunks of data passing over = the net are tagged and bagged for encryption and authentication from the qu= estion of key setup.
IKE is separate from ESP and AH. ESP and AH can be used independently of IK= E, although manual keying
is obviously not attractive in most cases. TLS is a different matter, in th= at the handshake that
puts keys in place is integral to the data security protocol. However, DTLS= is used with SRTP
to secure VoIP, showing that the key exchange there can be used to support = other protocols.


There is no logical reason why the key negotiation for TLS, IPSEC and tcpcr= ypt cant be shared.
yes, it could be, despite the erroneous assertions above ;-)

Please do not confuse your misunderstanding of my pos= t with my knowledge of the circumstances.

IKE is c= ertainly not currently packaged up for use an independent service. Saying t= hat this could be done is not the same as it having been done.
=A0
The current IKE document beg= ins as follows:

Kaufman, et al.          =
    Standards Track                    [Page 4]

 
RFC 5996        =
                IKEv2bis                  September 2010



1.  Introduction


   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.

That is not how I expect a document describing an independ= ent crypto protocol designed for use in other schemes to begin.

Suggesting that the IETF adopt a practice of requiring re-us= e of such schemes in the security area is actually suggesting quite a major= change in our approach. i.e. instead of having PGP and S/MIME sit in separ= ate rooms defining two different message formats for secure email, require = them to agree on one message format that can be used with both trust infras= tructures.

The idea that key exchange can be implemented as an ind= ependent Web Service is not something I expect to see in the IPSEC docs sin= ce the originals were written several years before the term was coined.

--
Website: http://h= allambaker.com/
--089e0112c1ba6b4fff04f07d2c47-- From kent@bbn.com Tue Jan 21 08:30:59 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AC61A02ED for ; Tue, 21 Jan 2014 08:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anWa0KIqNn_J for ; Tue, 21 Jan 2014 08:30:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FE1A017E for ; Tue, 21 Jan 2014 08:30:56 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:57933 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5eE3-0009Ss-WC; Tue, 21 Jan 2014 11:30:56 -0500 Message-ID: <52DEA0BF.3020507@bbn.com> Date: Tue, 21 Jan 2014 11:30:55 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020608080008010105010101" Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:30:59 -0000 This is a multi-part message in MIME format. --------------020608080008010105010101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit PHB, ... > Please do not confuse your misunderstanding of my post with my > knowledge of the circumstances. read what I wrote, as opposed to your misunderstanding ... > IKE is certainly not currently packaged up for use an independent > service. Saying that this could be done is not the same as it having > been done. > The current IKE document begins as follows: > > Kaufman, et al. Standards Track [Page 4] > > RFC 5996 IKEv2bis September 2010 > > > 1 . Introduction > > > > > IP Security (IPsec) provides confidentiality, data integrity, access > control, and data source authentication to IP datagrams. I said that IKE is _separate_ from ESP and AH and that _AH and ESP can be used without IKE_. It is true that IKE is a version of ISAKMP that has been tailored to support IPsec, but it is still independent of ESP and AH; IKE uses its own mechanisms to protect its SAs, not ESP. > That is not how I expect a document describing an independent crypto > protocol designed for use in other schemes to begin. > > Suggesting that the IETF adopt a practice of requiring re-use of such > schemes in the security area is actually suggesting quite a major > change in our approach. i.e. instead of having PGP and S/MIME sit in > separate rooms defining two different message formats for secure > email, require them to agree on one message format that can be used > with both trust infrastructures. (O)PGP and S/MIME are different in more ways than the assumed "trust infrastructure." I think no one is requiring re-use of IKE in contexts where it is not appropriate. However, given the complexity of developing good key management protocols, Security ADs usually advise against creating a new one unless it is necessary. > The idea that key exchange can be implemented as an independent Web > Service is not something I expect to see in the IPSEC docs since the > originals were written several years before the term was coined. Ah, so your (previously hidden) agenda is a push for a Web Service for key management. Well, at least that's on the table now, sitting next to OmniBroker. Steve --------------020608080008010105010101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PHB,

...
Please do not confuse your misunderstanding of my post with my knowledge of the circumstances.
read what I wrote, as opposed to your misunderstanding ...

IKE is certainly not currently packaged up for use an independent service. Saying that this could be done is not the same as it having been done.
 
The current IKE document begins as follows:

Kaufman, et al.              Standards Track                    [Page 4]

 
RFC 5996                        IKEv2bis                  September 2010



1.  Introduction



   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.
I said that IKE is separate from ESP and AH and that AH and ESP can be used without IKE.

It is true that IKE is a version of ISAKMP that has been tailored to support IPsec, but it
is still independent of ESP and AH; IKE uses its own mechanisms to protect its SAs, not ESP.
That is not how I expect a document describing an independent crypto protocol designed for use in other schemes to begin.

Suggesting that the IETF adopt a practice of requiring re-use of such schemes in the security area is actually suggesting quite a major change in our approach. i.e. instead of having PGP and S/MIME sit in separate rooms defining two different message formats for secure email, require them to agree on one message format that can be used with both trust infrastructures.
(O)PGP and S/MIME are different in more ways than the assumed "trust infrastructure."

I think no one is requiring re-use of IKE in contexts where it is not appropriate. However, given
the complexity of developing good key management protocols, Security ADs usually advise against
creating a new one unless it is necessary.
The idea that key exchange can be implemented as an independent Web Service is not something I expect to see in the IPSEC docs since the originals were written several years before the term was coined.
Ah, so your (previously hidden) agenda is a push for a Web Service for key management. Well, at least that's
on the table now, sitting next to OmniBroker.

Steve
--------------020608080008010105010101-- From adrian@olddog.co.uk Tue Jan 21 13:52:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2761A03C2 for ; Tue, 21 Jan 2014 13:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvK3IGhYEUTy for ; Tue, 21 Jan 2014 13:52:24 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 846C71A03C0 for ; Tue, 21 Jan 2014 13:52:24 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LLqMbr005508 for ; Tue, 21 Jan 2014 21:52:22 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LLq9Y5005460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 21 Jan 2014 21:52:22 GMT From: "Adrian Farrel" To: References: <20140121214750.13233.68712.idtracker@ietfa.amsl.com> In-Reply-To: <20140121214750.13233.68712.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 21:52:11 -0000 Message-ID: <0c0d01cf16f3$1211e3a0$3635aae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJrSyNW413zlmJ2jncG01mERPobdZlXT7lg Content-Language: en-gb Subject: [perpass] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:52:27 -0000 Hi, This document still remains a focus for discussion and is not (yet?) a = concrete proposal for implementation. Our purpose is to establish what = could be done and to have the discussion about whether there could be = value. You can, of course, diff out the changes in this revision. The main = change is to add some discussion of the nonce (nonce-sense) and to add = text to the applicability discussion in section 5. As before, Stephen and I remain at your disposal for entertaining and = enlightening conversation on this topic. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 21 January 2014 21:48 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for = draft-farrelll-mpls-opportunistic-encrypt- > 01.txt >=20 >=20 > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 01 > Title: Opportunistic Encryption in MPLS Networks > Document date: 2014-01-21 > Group: Individual Submission > Pages: 25 > URL: = http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- > encrypt-01.txt > Status: = https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- > encrypt/ > Htmlized: = http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- > 01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- > encrypt-01 >=20 > Abstract: > This document describes a way to apply opportunistic encryption > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be = exchanged > to enable the encryption, and indicates how key identifiers are > exchanged in encrypted MPLS packets. Finally, this document > describes the applicability of opportunistic encryption in MPLS > networks with an indication of the level of improved security as = well > as the continued vulnerabilities. >=20 > This document does not describe security for MPLS control plane > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From hallam@gmail.com Tue Jan 21 16:35:43 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB641A0125 for ; Tue, 21 Jan 2014 16:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgJDVnEbz3HO for ; Tue, 21 Jan 2014 16:35:41 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EC24D1A01BC for ; Tue, 21 Jan 2014 16:35:40 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so7210838lan.33 for ; Tue, 21 Jan 2014 16:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=07oNTuGFlLk0tHu6T9Yq8crQmPAgjsVCv3hSxmc+jRs=; b=iwW32wKI0j1tSj/QksXIhTkXoIF3R+cDGreT6HIO88ovhUGqJzFtHugslJqrpe07xU tzKzlSTUkBs+hFUIGszyYBwxJem79WYqDQKyCkrCbjJ0uIx7Oh7ntW2upqM11UPtIVMS lxrN5YJNel2mqVn25/6kLgrJgKirVeygej0oKxY8Iox/sKH7Ku0vUdd8m6AIZZ0AZzei WNurDgI2kBswI/tFJiZiekX2qamftTczerP4jVw/OHOkaGBvSaFLSvmGDlxjjLR3YwEu TIqMXoLPGAJ7/YKqUXJLDR6N5IfeN/4h3T3wula7rktZMiIXfZCiGuXJ3NppDiEHUBKi Twcw== MIME-Version: 1.0 X-Received: by 10.112.150.200 with SMTP id uk8mr16589105lbb.1.1390350939958; Tue, 21 Jan 2014 16:35:39 -0800 (PST) Received: by 10.112.37.172 with HTTP; Tue, 21 Jan 2014 16:35:39 -0800 (PST) In-Reply-To: <52DEA0BF.3020507@bbn.com> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> Date: Tue, 21 Jan 2014 19:35:39 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b342f86e3b21d04f0844d93 Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 00:35:44 -0000 --047d7b342f86e3b21d04f0844d93 Content-Type: text/plain; charset=ISO-8859-1 Steve If you are going to state that someone got their post wrong then all that actually matters is what they said because that is the case you are arguing against. You can't redefine my motion and then complain that I didn't understand it. If you are going to say I got things wrong and then followup with a completely unrelated post then you are a confused bunny. And I split the key agreement out of Omnibroker into WSConnect, oh, six months ago. Precisely because it is a feature that we now need at the Web Service layer. So hardly a 'hidden agenda'. While we are at it we could reinstate photuris. On Tue, Jan 21, 2014 at 11:30 AM, Stephen Kent wrote: > PHB, > > ... > > Please do not confuse your misunderstanding of my post with my > knowledge of the circumstances. > > read what I wrote, as opposed to your misunderstanding ... > > > IKE is certainly not currently packaged up for use an independent > service. Saying that this could be done is not the same as it having been > done. > > The current IKE document begins as follows: > > Kaufman, et al. Standards Track [Page 4] > > RFC 5996 IKEv2bis September 2010 > > 1 . Introduction > > IP Security (IPsec) provides confidentiality, data integrity, access > control, and data source authentication to IP datagrams. > > I said that IKE is *separate* from ESP and AH and that *AH and ESP can > be used without IKE*. > > It is true that IKE is a version of ISAKMP that has been tailored to > support IPsec, but it > is still independent of ESP and AH; IKE uses its own mechanisms to protect > its SAs, not ESP. > > That is not how I expect a document describing an independent crypto > protocol designed for use in other schemes to begin. > > Suggesting that the IETF adopt a practice of requiring re-use of such > schemes in the security area is actually suggesting quite a major change in > our approach. i.e. instead of having PGP and S/MIME sit in separate rooms > defining two different message formats for secure email, require them to > agree on one message format that can be used with both trust > infrastructures. > > (O)PGP and S/MIME are different in more ways than the assumed "trust > infrastructure." > > I think no one is requiring re-use of IKE in contexts where it is not > appropriate. However, given > the complexity of developing good key management protocols, Security ADs > usually advise against > creating a new one unless it is necessary. > > The idea that key exchange can be implemented as an independent Web > Service is not something I expect to see in the IPSEC docs since the > originals were written several years before the term was coined. > > Ah, so your (previously hidden) agenda is a push for a Web Service for key > management. Well, at least that's > on the table now, sitting next to OmniBroker. > > Steve > -- Website: http://hallambaker.com/ --047d7b342f86e3b21d04f0844d93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Steve

If you are going to state that so= meone got their post wrong then all that actually matters is what they said= because that is the case you are arguing against. You can't redefine m= y motion and then complain that I didn't understand it.

If you are going to say I got things wrong and then fol= lowup with a completely unrelated post then you are a confused bunny.
=

And I split the key agreement out of Omnibroker into WS= Connect, oh, six months ago. Precisely because it is a feature that we now = need at the Web Service layer. So hardly a 'hidden agenda'.

While we are at it we could reinstate photuris.




On Tue, Jan 21, 2014 at 11:30 AM, Stephen Kent <kent@bbn.c= om> wrote:
=20 =20 =20
PHB,

...
Please do not confuse your misunderstanding of my post with my knowledge of the circumstances.
read what I wrote, as opposed to your misunderstanding ...


IKE is certainly not currently packaged up for use an independent service. Saying that this could be done is not the same as it having been done.
=A0
The current IKE document begins as follows:

<=
span style=3D"color:rgb(119,119,119)">Kaufman, et al.              Standard=
s Track                    [Page 4]

<=
a name=3D"143b5a3f361b6c58_page-5" href=3D"http://tools.ietf.org/html/rfc59=
96#page-5" style=3D"text-decoration:none;color:white" target=3D"_blank"> 
RFC 5996 =
                       IKEv2bis                  September 2010



1.  Introduction<=
/h2>



   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.
I said that IKE is separate from ESP and AH and that AH and ESP can be used without IKE.

It is true that IKE is a version of ISAKMP that has been tailored to support IPsec, but it
is still independent of ESP and AH; IKE uses its own mechanisms to protect its SAs, not ESP.
That is not how I expect a document describing an independent crypto protocol designed for use in other schemes to begin.

Suggesting that the IETF adopt a practice of requiring re-use of such schemes in the security area is actually suggesting quite a major change in our approach. i.e. instead of having PGP and S/MIME sit in separate rooms defining two different message formats for secure email, require them to agree on one message format that can be used with both trust infrastructures.
(O)PGP and S/MIME are different in more ways than the assumed "tru= st infrastructure."

I think no one is requiring re-use of IKE in contexts where it is not appropriate. However, given
the complexity of developing good key management protocols, Security ADs usually advise against
creating a new one unless it is necessary.

The idea that key exchange can be implemented as an independent Web Service is not something I expect to see in the IPSEC docs since the originals were written several years before the term was coined.
Ah, so your (previously hidden) agenda is a push for a Web Service for key management. Well, at least that's
on the table now, sitting next to OmniBroker.

Steve



--
Website: http://hallambaker.com/
--047d7b342f86e3b21d04f0844d93-- From kent@bbn.com Wed Jan 22 06:47:34 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D171A00F0 for ; Wed, 22 Jan 2014 06:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAkLsNQQOHDX for ; Wed, 22 Jan 2014 06:47:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB01A00E7 for ; Wed, 22 Jan 2014 06:47:32 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49120 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5z5X-0006mN-Km; Wed, 22 Jan 2014 09:47:31 -0500 Message-ID: <52DFDA03.3060608@bbn.com> Date: Wed, 22 Jan 2014 09:47:31 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , perpass References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:47:34 -0000 PHB, I'd respond to your comments if they were directly tied to specific statements I made. But, for the most part, they are so vague ... WRT Omnibroker, my comment was not based on key agreement being part of Omnibroker; it was an observation that your recent proposals all tend to focus on technologies that fit nicely into a model where you current employer could generate a revenue stream, as an extension of its current Web PKI CA model. I have not tracked the evolution of Omnibroker, as it is an individual submission. Since such submissions are not vetted, it's not generally worth my time to track them. Steve From hallam@gmail.com Wed Jan 22 08:40:50 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21A1A014B for ; Wed, 22 Jan 2014 08:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNeoNHfbFQ2I for ; Wed, 22 Jan 2014 08:40:48 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id D98091A010D for ; Wed, 22 Jan 2014 08:40:47 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z5so529663lbh.12 for ; Wed, 22 Jan 2014 08:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=13RJqY379qOVyr1sGuMhqJakEHqHbkv4cnRC3R8ubTA=; b=AZqnLHR/WEgkL6UPJR3NwPH9vglXfbQQCRenvEV3L685EXtLZ0JH3jtysM3eUnQHdX tA1/nJfeef7FGDqI8BV6PY2ai9KoKVpytoi4nNTH/ZU7GWAckvEnP9wOKvMkX1vtdYnZ QTFpBErQjsmkCrTB0oV8LIBonwzgrfwB4GgIpZ5XY58BQO/Nhzo2MMIZzOHthxq6FdGS ogNvZKwfiGPoRL1IbRyEwA7a4HMQSnfWUU5OdpAbn+An+wuEL5DTddwSSD3VYsCh1m8K 0BeQwNZRqHlpDYGKVdoVqRusj4XOd7Us5Dvn/+pv13vRevdUzE5CdLcX19fTCPXj9FvN DI4Q== MIME-Version: 1.0 X-Received: by 10.152.116.4 with SMTP id js4mr1637578lab.53.1390408846499; Wed, 22 Jan 2014 08:40:46 -0800 (PST) Received: by 10.112.37.172 with HTTP; Wed, 22 Jan 2014 08:40:46 -0800 (PST) In-Reply-To: <52DFDA03.3060608@bbn.com> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> <52DFDA03.3060608@bbn.com> Date: Wed, 22 Jan 2014 11:40:46 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c234a663640c04f091c982 Cc: perpass Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 16:40:50 -0000 --001a11c234a663640c04f091c982 Content-Type: text/plain; charset=ISO-8859-1 I find it rather interesting that someone who takes great offense when it is pointed out that he works under contract to the NSA goes after people for having a 'hidden' agenda. If you want to start questioning people's ulterior or bought motives you are sawing off a mighty fine branch there and its the one you are standing on. Is the reason that you are arguing against Omnibroker so hard because someone in Fort Meade is getting nervous? Maybe they should, they had three people come to see my first public talk on PRISM-PROOF email. Or is it impolite for me to ask such questions because you are the only person allowed to call people's motives into question? I have made absolutely no secret of the fact that Omnibroker provides a business model for CA like companies. In fact that is the basis on which I have presented it to Symantec and McAfee and other anti-virus companies precisely to solicit support. As far as I am aware, they are not communists. Neither is my employer. Changing the Internet is hard. You can't change it unless your scheme is actually free or backed by a business model that covers the costs. I can't remember at this stage whether I talk about the business model in part 1 or 2, I haven't got round to editing part 2 yet: http://www.youtube.com/watch?v=PTKrt471vTU I talk about business models because I understand that I can't change the infrastructure alone. I need the help of Microsoft and Google and Apple and Mozilla. And they are not likely to be interested in a business model that only fits one provider. What we need to get away from is the clueless business models of the past. CAs add real value in the WebPKI but not very much to the MailPKI currently which is why there isn't one, or rather isn't very much of one. A model that makes CAs toll booth collectors before the road is built does not work. But CAs can certainly add value to a MailPKI infrastructure once it reaches critical mass. Today maybe 0.01% of Internet users know enough about crypto to configure their systems securely themselves. That may rise to 5% or so with training etc. That leaves a huge market for CAs. If a billion people want to use crypto to protect themselves against the panicking generals that run the NSA, we will find ways to make money. The Open Source model works fine for many software products. Red Hat does pretty well. But we are taking a risk here. Comodo group has 155,000 paid, non expired S/MIME certs right now. So changing the model could backfire on us. But thats a risk we have decided to take. On Wed, Jan 22, 2014 at 9:47 AM, Stephen Kent wrote: > PHB, > > I'd respond to your comments if they were directly tied to specific > statements > I made. But, for the most part, they are so vague ... > > WRT Omnibroker, my comment was not based on key agreement being part of > Omnibroker; > it was an observation that your recent proposals all tend to focus on > technologies that > fit nicely into a model where you current employer could generate a > revenue stream, > as an extension of its current Web PKI CA model. I have not tracked the > evolution > of Omnibroker, as it is an individual submission. Since such submissions > are > not vetted, it's not generally worth my time to track them. > > Steve > -- Website: http://hallambaker.com/ --001a11c234a663640c04f091c982 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I find it rather interesting that someone who takes great = offense when it is pointed out that he works under contract to the NSA goes= after people for having a 'hidden' agenda.

If y= ou want to start questioning people's ulterior or bought motives you ar= e sawing off a mighty fine branch there and its the one you are standing on= .

Is the reason that you are arguing against Omnibroker so hard= because someone in Fort Meade is getting nervous? Maybe they should, they = had three people come to see my first public talk on PRISM-PROOF email. Or = is it impolite for me to ask such questions because you are the only person= allowed to call people's motives into question?


I have made absolutely no secret of the = fact that Omnibroker provides a business model for CA like companies. In fa= ct that is the basis on which I have presented it to Symantec and McAfee an= d other anti-virus companies precisely to solicit support. As far as I am a= ware, they are not communists. Neither is my employer.

Changing the Internet is hard. You can't change it = unless your scheme is actually free or backed by a business model that cove= rs the costs. I can't remember at this stage whether I talk about the b= usiness model in part 1 or 2, I haven't got round to editing part 2 yet= :


I talk about business= models because I understand that I can't change the infrastructure alo= ne. I need the help of Microsoft and Google and Apple and Mozilla. And they= are not likely to be interested in a business model that only fits one pro= vider.

What we nee= d to get away from is the clueless business models of the past. CAs add rea= l value in the WebPKI but not very much to the MailPKI currently which is w= hy there isn't one, or rather isn't very much of one. A model that = makes CAs toll booth collectors before the road is built does not work.

But CAs can= certainly add value to a MailPKI infrastructure once it reaches critical m= ass. Today maybe 0.01% of Internet users know enough about crypto to config= ure their systems securely themselves. That may rise to 5% or so with train= ing etc. That leaves a huge market for CAs. If a billion people want to use= crypto to protect themselves against the panicking generals that run the N= SA, we will find ways to make money.

The Open So= urce model works fine for many software products. Red Hat does pretty well.=

But w= e are taking a risk here. Comodo group has 155,000 paid, non expired S/MIME= certs right now. So changing the model could backfire on us. But thats a r= isk we have decided to take.


On Wed, Jan 22, 2014 at 9:47 AM, Stephen Kent <kent@bbn.com= > wrote:
PHB,

I'd respond to your comments if they were directly tied to specific sta= tements
I made. But, for the most part, they are so vague ...

WRT Omnibroker, my comment was not based on key agreement being part of Omn= ibroker;
it was an observation that your recent proposals all tend to focus on techn= ologies that
fit nicely into a model where you current employer could generate a revenue= stream,
as an extension of its current Web PKI CA model. I have not tracked the evo= lution
of Omnibroker, as it is an individual submission. Since such submissions ar= e
not vetted, it's not generally worth my time to track them.

Steve



--
Website: http://hallambaker.com/
--001a11c234a663640c04f091c982-- From leifj@mnt.se Wed Jan 22 12:19:31 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF261A0455 for ; Wed, 22 Jan 2014 12:19:31 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDIL5K-BMzk6 for ; Wed, 22 Jan 2014 12:19:29 -0800 (PST) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3921F1A0472 for ; Wed, 22 Jan 2014 12:19:27 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so10937ead.20 for ; Wed, 22 Jan 2014 12:19:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DpTGZgtP8Rb9FHuOEhJE+vt+aTXHwDnWucs2RusEnqY=; b=MBzbSTJadfoz3eDP/Q6sgQVOPe8SV78kwnlE83SGt5rjJXpnrzq6baJ0VpSapMab5o 4qza3AoRxTsR1rBzZmaJjcrmHoXHNFgLxh7iKHe2FsPCPu6z8fVcOGPqwi5UAtFcNaQP ShxvhgARaZUaspmD3pXUHds4ypM+qOIyS/SZrbDKNgZouyomi4vlg2SwcdKW4cx6icuJ wJlHnhSAHGrMaVFfGqItfYkqtXbw+eRa9rFMsUipVwtOOkrSfxqfXnMMnXhVW8kjo2PN r9OfMXFbsEiewvdcWwF0MNurPDSYE3jlLA1u9xLuxynUyyeZhaMZ+vI3w4X/gp2whJNJ n9VA== X-Gm-Message-State: ALoCoQmzxCU80gqcqi5r+31y8EgE8aczGWNZiR0pr0AcHILqxpbe5A4hkYEBs7dhC4/YZP+iTsDF X-Received: by 10.14.0.201 with SMTP id 49mr3610460eeb.38.1390421966226; Wed, 22 Jan 2014 12:19:26 -0800 (PST) Received: from [10.0.0.151] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id u7sm31122306eep.11.2014.01.22.12.19.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 12:19:25 -0800 (PST) Message-ID: <52E027CC.1010405@mnt.se> Date: Wed, 22 Jan 2014 21:19:24 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> <52DFDA03.3060608@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Increasingly strange thread (was: .... I honestly can't remember) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:19:32 -0000 Are we there yet? From scott.brim@gmail.com Wed Jan 22 12:32:23 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568CC1A0490 for ; Wed, 22 Jan 2014 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg5Pkt3o3eAe for ; Wed, 22 Jan 2014 12:32:21 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A7B331A0265 for ; Wed, 22 Jan 2014 12:32:21 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so1031316obc.1 for ; Wed, 22 Jan 2014 12:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XzQRFxd7GQWwUXBpsVXN7v6+Sz5+8xlzy2uiAU0jdDQ=; b=cylqaOEfnIQrSr5GaPfyCJY5qAfMAaxaWdPsjtvNi3IXymhsB6xV9ziLygk70AhFHq bm3pW2CXNOzbT9uRm0DZzkVYM/31vTi90wK70C04977YmtPV3VM59vz1ZVDZPONTTBQV bXqele2p8QDTseP6SwQd6ti0+MND5FgwKEFMMyBTeXxuwzEjBCYOJ+wd91i7SzFwBVem RC3I2/NWf+qrTC0/fLgBD9FpsKgLGsRnPzmx3cBTM3s1mFtIwfFIdl6P7eRe4Y/fqMbw Ji22HE0uFXOnuR4D9iqbvOOc+An/Mf/9sJwiO/qvFX5AhOTlJNJXEax9HZhSZWIGIq8+ eXOQ== X-Received: by 10.60.50.202 with SMTP id e10mr2865436oeo.39.1390422741022; Wed, 22 Jan 2014 12:32:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 22 Jan 2014 12:32:00 -0800 (PST) In-Reply-To: <52E027CC.1010405@mnt.se> References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> <52DFDA03.3060608@bbn.com> <52E027CC.1010405@mnt.se> From: Scott Brim Date: Wed, 22 Jan 2014 15:32:00 -0500 Message-ID: To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass Subject: Re: [perpass] Increasingly strange thread (was: .... I honestly can't remember) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:32:23 -0000 On Wed, Jan 22, 2014 at 3:19 PM, Leif Johansson wrote: > > Are we there yet? I deny that I am monitoring your location. From hallam@gmail.com Thu Jan 23 14:51:55 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD091A0182 for ; Thu, 23 Jan 2014 14:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1HlOYPWjjqS for ; Thu, 23 Jan 2014 14:51:52 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 082DC1A007C for ; Thu, 23 Jan 2014 14:51:51 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so1995971lan.18 for ; Thu, 23 Jan 2014 14:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GVDITnl+dDsdi7eZXPwbviu9pD0xyueolqLU2Sxt1b8=; b=pN1YFS0+HdsNnpAtZ09WO0uL4PuKHQ/f4//dAcLsiManRl5Eg6qgg/xZxNkeIliRdf wcgDx95Ts6H+ouFLPNFs+xGvfB/sGqTlIh8X4BD1hD7ZLpyk85fUhTveJ13raOKTj34V dG+Wi27wqtF5NBvtuLWxpHYRwFZxhdwNqyIpSrPHxfW22xVrz3FuZkglZlW3it6szLXz XcV+rDLucie1nWYFKFOXss2C2dTDgEKY2OVR1WlWIHqj2JjbUrE9xV02G3FQtnxDID7j 8vcrOpWz7FRbmGi6VHkqiwLC1w1HGX9OYrh8pCBlmP9316HEEU/ijDSZos6m+zLe2a4A +3yQ== MIME-Version: 1.0 X-Received: by 10.112.234.194 with SMTP id ug2mr77917lbc.86.1390517510375; Thu, 23 Jan 2014 14:51:50 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 23 Jan 2014 14:51:50 -0800 (PST) Date: Thu, 23 Jan 2014 17:51:50 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c30d06428b5404f0ab1683 Subject: [perpass] Why a Key Exchange should be a separate module X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:51:55 -0000 --001a11c30d06428b5404f0ab1683 Content-Type: text/plain; charset=ISO-8859-1 It occurs to me that in answering Kent's attack on me, I may have inadvertently left the wrong impression of the reason why I have come to the conclusion that key exchange should be a separate concern from the binding to the communication layer. Then as I began to wonder why the proposal might have set him off and working from a hypothesis advanced in another place, I have come up with a better scheme than previously. The only connection to Omnibroker is that I realized the need to make this separation as a result of writing Omnibroker. After writing the first implementation, I took a look at my code and realized that over 70% of it dealt with the problem of establishing and managing a long term trust relationship between a group of related clients (i.e. sharing the same account) and a service. And that this is a mechanism that can be used in many, many other protocols. Consequently, I factored the connection protocol out. http://tools.ietf.org/search/draft-hallambaker-wsconnect-05 Now people can argue that the approach I take in wsconnect, namely relying on the encapsulating TLS transport to protect exchange of the long term secrets is a naive approach. Which of course it is. I want to replace that approach with something better, preferably something that has been thoroughly tested. But that currently requires me to reverse engineer some other key exchange which is hardly an optimal approach. So the current scheme is really a placeholder rather than a final proposal. Kerberos has shown the way forward here. A symmetric security context may be reduced to: * The identity and permissions of the subject * A set of cryptographic parameters (algorithms, etc) * A set of symmetric keys * An identifier that allows the counterparty to obtain the above Since the only necessary feature of the identifier is that it uniquely identify the security context to the counterparty, the identifier should be opaque to the communication medium. If the counterparty generates the identifier and the permitted identifier length is sufficiently long, the identifier can contain the security context provided that suitable encryption and authentication measures are used. Presenting the Key Exchange as a separate Web Service with defined inputs and outputs means that instead of having to choose between OAKLEY, IKE, PHOTURIS etc. as effectively exclusive schemes because there is only one MTI, a mix and match approach becomes easier. This presentation also makes it rather easier to conceal the identities of the parties when combined with the WSConnect approach because this integrates key exchange into the service discovery process. A WSConnect service association is to a collection of hosts with information to enable protocol and protocol version agility. Each host has a separate security association. So in WSConnect right now, if I have service A and B, the security association would have a different key identifier and symmetric key for each (with dummy data): Service = [ { "host" : "a", "secret" : "xxxxxx", "id" : "iixxxxx"}, { "host" : "b", "secret" : "yyyyyy", "id" : "iiyyyyy"}] This approach means that a passive observer can perform traffic analysis by looking for repeated appearances of iixxxxx and iiyyyyy. This would allow an attacker to match traffic from different IP addresses. It is not possible for the attacker to correlate iixxxxx and iiyyyyy directly but this may be inferred from other data. Now imagine that we add a parameter for a DH public key for each host. We can now blind the identifier values by encrypting them under an ephemeral DH key from the client. The separate key exchange service approach is very powerful because we can use it iteratively. One key exchange service can be used to protect interactions with another. This allows identity leakage to be concealed to a far greater degree than is currently possible in IPSEC or TLS. Control over identity leakage is given to the party deploying a service rather than the designer of the protocol. I think that is a good thing. Others might disagree. -- Website: http://hallambaker.com/ --001a11c30d06428b5404f0ab1683 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It occurs to me that in answering Kent's attack o= n me, I may have inadvertently left the wrong impression of the reason why = I have come to the conclusion that key exchange should be a separate concer= n from the binding to the communication layer.

Then as I began to wonder why the proposal might have s= et him off and working from a hypothesis advanced in another place, I have = come up with a better scheme than previously.


The only connection to Omnibroker is that I realized the nee= d to make this separation as a result of writing Omnibroker. After writing = the first implementation, I took a look at my code and realized that over 7= 0% of it dealt with the problem of establishing and managing a long term tr= ust relationship between a group of related clients (i.e. sharing the same = account) and a service. And that this is a mechanism that can be used in ma= ny, many other protocols.

Consequently, I factored the connection protocol out.



Now people can argue that the appr= oach I take in wsconnect, namely relying on the encapsulating TLS transport= to protect exchange of the long term secrets is a naive approach. Which of= course it is. I want to replace that approach with something better, prefe= rably something that has been thoroughly tested. But that currently require= s me to reverse engineer some other key exchange which is hardly an optimal= approach. So the current scheme is really a placeholder rather than a fina= l proposal.

Kerberos has shown the way forward here. A symmetric se= curity context may be reduced to:

* The identity a= nd permissions of the subject
* A set of cryptographic parameters= (algorithms, etc)
* A set of symmetric keys
* An identifier that allows the co= unterparty to obtain the above

Since the only nece= ssary feature of the identifier is that it uniquely identify the security c= ontext to the counterparty, the identifier should be opaque to the communic= ation medium.

If the counterparty generates the identifier and the pe= rmitted identifier length is sufficiently long, the identifier can contain = the security context provided that suitable encryption and authentication m= easures are used.


Presenting the Key Exchange as a separat= e Web Service with defined inputs and outputs means that instead of having = to choose between OAKLEY, IKE, PHOTURIS etc. as effectively exclusive schem= es because there is only one MTI, a mix and match approach becomes easier.<= /div>

This presentation also makes it rather easier to concea= l the identities of the parties when combined with the WSConnect approach b= ecause this integrates key exchange into the service discovery process. A W= SConnect service association is to a collection of hosts with information t= o enable protocol and protocol version agility. Each host has a separate se= curity association.=A0


So in WSConnect right now, if I have ser= vice A and B, the security association would have a different key identifie= r and symmetric key for each (with dummy data):

Service =3D [=A0
=A0 { "host" : "a", "se= cret" : "xxxxxx", "id" : "iixxxxx"},
=A0 { "host" : "b", "secret" : "y= yyyyy", "id" : "iiyyyyy"}]

This approach means that a passive observer can p= erform traffic analysis by looking for repeated appearances of iixxxxx and = iiyyyyy. This would allow an attacker to match traffic from different IP ad= dresses. It is not possible for the attacker to correlate iixxxxx and iiyyy= yy directly but this may be inferred from other data.

Now imagine that we add a parameter for a DH public key= for each host. We can now blind the identifier values by encrypting them u= nder an ephemeral DH key from the client.


The separate key exchange service approach is very powerful beca= use we can use it iteratively. One key exchange service can be used to prot= ect interactions with another. This allows identity leakage to be concealed= to a far greater degree than is currently possible in IPSEC or TLS. Contro= l over identity leakage is given to the party deploying a service rather th= an the designer of the protocol.

I think that is a good thing. Others might disagree.

--
Website: http:= //hallambaker.com/
--001a11c30d06428b5404f0ab1683-- From huitema@huitema.net Sat Jan 25 13:11:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE11A003A for ; Sat, 25 Jan 2014 13:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SFhnkSbal3D for ; Sat, 25 Jan 2014 13:11:03 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4701A0039 for ; Sat, 25 Jan 2014 13:11:03 -0800 (PST) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1W7AVI-00041F-U4 for perpass@ietf.org; Sat, 25 Jan 2014 16:11:01 -0500 Received: (qmail 12328 invoked from network); 25 Jan 2014 21:10:59 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2014 21:10:59 -0000 From: "Christian Huitema" To: "'Dave Crocker'" , "'Stephen Farrell'" Date: Sat, 25 Jan 2014 13:10:58 -0800 Message-ID: <012101cf1a11$f23cc9b0$d6b65d10$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8aDzOiXC3A69wOQdSedKL5r1l8SQ== Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] tcpcrypt applicability X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:11:09 -0000 From: Dave Crocker, Monday, January 20, 2014 7:27 AM > On 1/20/2014 7:19 AM, Stephen Farrell wrote: >> I'd expect that if tcpcrypt were implemented in >> some kernels then it'd be useful in places where you can't >> feasibly use TLS. > > > what are some examples of when this could occur? > > as long as there is speculation about this as a legitimate alternative, > it would help to have the speculation include plausible examples. TCPCRYPT is a very good way to do opportunistic encryption. It will negotiate encryption by default at the beginning of the TCP session, without any attempt to provide authentication. At the same time, the stack provides a unique identifier of the encryption session, which can be used by the application protocol to perform authentication and detect MITM by any way they see fit -- PKI, EKE, PGP, some application specific scheme, or even nothing if the application does not care. The architecture looks what we should have done 20 years ago. Kudos to the authors of the spec. But then, the big question is, is it deployable? First, it pretty much requires OS implementation. I can foresee interesting discussions before big development teams decide to do this. It also supposes a communication API between app and stack, and also some yet-to-be-standardized application protocols for managing the encryption identifiers. That too will take time. And then it requires new TCP options, which many NAT and firewalls are known to block by default. In short, high potential, but likely to remain a small deployment for several years. If I were a transport AD, I would charter the group and give them time to grow... but of course I know better than give advice to the folks actually doing the work. -- Christian Huitema From hallam@gmail.com Mon Jan 27 08:28:44 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7859D1A034A for ; Mon, 27 Jan 2014 08:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrJIm-draO7T for ; Mon, 27 Jan 2014 08:28:41 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF11A033D for ; Mon, 27 Jan 2014 08:28:40 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so4693370lab.34 for ; Mon, 27 Jan 2014 08:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tQHXEi5Q1AwihyELIBD8liAIxU1c7mDvJVUA7Ri2OW4=; b=F7GzUSa1IAG17YcGyPtR4vPGXAMReNSINHfkEXJk6kb64XVB7bX7PhmsghKEWiQvYa krR1o05V5w8Fp6m0avP39XXTdHCf614asDoJRbRivyU2tPzZ/tpUUUQaWpc/2Aakkbcz zRRO80g84fF0+0sNFUn4Lj/Vc64A2jW7jxFo1PkG06Qs01EHSxpLamhLqmpdhyCobGhc qsNOFZayvkJUZuM4HW2rH49yi+KESFiOjuNRLdvnpHJ1wAjo5zRvep4L+7YUguD2tL0U Ei7MDm+WblpkPRv3fe6x48la8V6fMU3c4Z7UiSzJ6Hn2fYbnPwlUa3/rL+/2+F3dqWA/ XRWQ== MIME-Version: 1.0 X-Received: by 10.152.205.197 with SMTP id li5mr35046lac.50.1390840117052; Mon, 27 Jan 2014 08:28:37 -0800 (PST) Received: by 10.112.37.168 with HTTP; Mon, 27 Jan 2014 08:28:36 -0800 (PST) In-Reply-To: <012101cf1a11$f23cc9b0$d6b65d10$@huitema.net> References: <012101cf1a11$f23cc9b0$d6b65d10$@huitema.net> Date: Mon, 27 Jan 2014 11:28:36 -0500 Message-ID: From: Phillip Hallam-Baker To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1136d45e1dca4d04f0f6338d Cc: perpass , Dave Crocker , Stephen Farrell Subject: Re: [perpass] tcpcrypt applicability X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 16:28:44 -0000 --001a1136d45e1dca4d04f0f6338d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 25, 2014 at 4:10 PM, Christian Huitema wrote: > From: Dave Crocker, Monday, January 20, 2014 7:27 AM > > On 1/20/2014 7:19 AM, Stephen Farrell wrote: > >> I'd expect that if tcpcrypt were implemented in > >> some kernels then it'd be useful in places where you can't > >> feasibly use TLS. > > > > > > what are some examples of when this could occur? > > > > as long as there is speculation about this as a legitimate alternative, > > it would help to have the speculation include plausible examples. > > TCPCRYPT is a very good way to do opportunistic encryption. It will > negotiate encryption by default at the beginning of the TCP session, > without > any attempt to provide authentication. At the same time, the stack provides > a unique identifier of the encryption session, which can be used by the > application protocol to perform authentication and detect MITM by any way > they see fit -- PKI, EKE, PGP, some application specific scheme, or even > nothing if the application does not care. The architecture looks what we > should have done 20 years ago. Kudos to the authors of the spec. > > But then, the big question is, is it deployable? First, it pretty much > requires OS implementation. I can foresee interesting discussions before > big > development teams decide to do this. It also supposes a communication API > between app and stack, and also some yet-to-be-standardized application > protocols for managing the encryption identifiers. That too will take time. > And then it requires new TCP options, which many NAT and firewalls are > known > to block by default. > Hence my proposal that this is something we should look at in conjunction with TLSvNext. There are two parts to any crypto transport, there is a key exchange and a transport binding. Hitherto we have treated these as being intrinsically and inseparably connected. So IPSEC uses IPSEC key exchange, TLS uses TLS key exchange and so on. If we separate the concerns here we could have one key exchange which could be used with an IP, TCP, Socket or Message layer transport binding. I certainly don't want a pure TCP layer binding because the application needs to know what the security context is and what the key is authenticated to. So I need some of the crypto to be visible at the socket layer. But I can certainly see room for a scheme where the TCP layer in the platform looks to see if the upper layer is doing crypto and if not does crypto opportunistically. But then that raises the question of integration with DNS and our issues with DNSSEC transport being only 97% visible at best but any deployment having to work in 99.99999% of network configurations. -- Website: http://hallambaker.com/ --001a1136d45e1dca4d04f0f6338d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jan 25, 2014 at 4:10 PM, Christian Huitema <huitema@huit= ema.net> wrote:
From: Dave Crocker, Monday, January 20, 2014= 7:27 AM
> On 1/20/2014 7:19 AM, Stephen Farrell wrote:
>> I'd expect that if tcpcrypt were implemented in
>> some kernels then it'd be useful in places where you can't=
>> feasibly use TLS.
>
>
> what are some examples of when this could occur?
>
> as long as there is speculation about this as a legitimate alternative= ,
> it would help to have the speculation include plausible examples.

TCPCRYPT is a very good way to do opportunistic encryption. It will
negotiate encryption by default at the beginning of the TCP session, withou= t
any attempt to provide authentication. At the same time, the stack provides=
a unique identifier of the encryption session, which can be used by the
application protocol to perform authentication and detect MITM by any way they see fit -- PKI, EKE, PGP, some application specific scheme, or even nothing if the application does not care. The architecture looks what we should have done 20 years ago. Kudos to the authors of the spec.

But then, the big question is, is it deployable? First, it pretty much
requires OS implementation. I can foresee interesting discussions before bi= g
development teams decide to do this. It also supposes a communication API between app and stack, and also some yet-to-be-standardized application
protocols for managing the encryption identifiers. That too will take time.=
And then it requires new TCP options, which many NAT and firewalls are know= n
to block by default.

Hence my proposal = that this is something we should look at in conjunction with TLSvNext.

There are two parts to any crypto transport, there is = a key exchange and a transport binding. Hitherto we have treated these as b= eing intrinsically and inseparably connected. So IPSEC uses IPSEC key excha= nge, TLS uses TLS key exchange and so on.

If we separate the concerns here we could have one key = exchange which could be used with an IP, TCP, Socket or Message layer trans= port binding.

I certainly don't want a pure TC= P layer binding because the application needs to know what the security con= text is and what the key is authenticated to. So I need some of the crypto = to be visible at the socket layer.

But I can certainly see room for a scheme where the TCP= layer in the platform looks to see if the upper layer is doing crypto and = if not does crypto opportunistically.

But then tha= t raises the question of integration with DNS and our issues with DNSSEC tr= ansport being only 97% visible at best but any deployment having to work in= 99.99999% of network configurations.
=A0
--
Website: htt= p://hallambaker.com/
--001a1136d45e1dca4d04f0f6338d-- From sob@sobco.com Tue Jan 28 15:39:37 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF01A033C for ; Tue, 28 Jan 2014 15:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3J6NRL_OKhq for ; Tue, 28 Jan 2014 15:39:36 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 45D511A02EC for ; Tue, 28 Jan 2014 15:39:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id ADAB95E2978 for ; Tue, 28 Jan 2014 18:39:32 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoZxgijdUkdJ for ; Tue, 28 Jan 2014 18:39:32 -0500 (EST) Received: from [10.2.244.246] (unknown [204.93.49.152]) by sobco.sobco.com (Postfix) with ESMTPSA id E7BC05E2963 for ; Tue, 28 Jan 2014 18:39:31 -0500 (EST) From: "Scott O. Bradner" Content-Type: multipart/signed; boundary="Apple-Mail=_5CD86BFB-E2B3-4E89-BFA8-831D30D7DF20"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <8FEC00FC-D83C-4FB2-8FE3-C8536CEAC814@sobco.com> Date: Tue, 28 Jan 2014 18:39:29 -0500 To: perpass Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [perpass] blast from the past X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:39:37 -0000 --Apple-Mail=_5CD86BFB-E2B3-4E89-BFA8-831D30D7DF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just remembered that we talked about setting a direction towards = protection quite a while ago in RFC 1752 (the IPv6 recommendation) We feel that an improvement in the basic level of security in the Internet is vital to its continued success. Users must be able to assume that their exchanges are safe from tampering, diversion and exposure. Organizations that wish to use the Internet to conduct business must be able to have a high level of confidence in the identity of their correspondents and in the security of their communications. The goal is to provide strong protection as a matter of course throughout the Internet. Scott --Apple-Mail=_5CD86BFB-E2B3-4E89-BFA8-831D30D7DF20 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 iQEcBAEBCgAGBQJS6D+xAAoJEGfrUQgIbw1kBG0H/ja8bdKCoGNn/v0B8D5oZp08 ziCv6Vc86wStxbFZ3mOe1Uno9qUbykp7FrYCWB8QJjlUIJ5GaVMXdriPbb5OC0ck Y8DTma/GCHcItYFf4+2lhsWzSiSocSujajjxEdHWlV3qGIOP6+vBWR6R+pwX6wCj sACVqxyTqpenDJjjnkobADP4w+SKZq+Qv0W8rCcdSQKhjKiSrRpqucqgoP+UjiQG 5MVUkW7v29P9IvsAIuox6PTltnYYAI2oY6Y26S4rYIYBRts5Q8TDks8dLSOC6CI+ jrwVdEYW6BTrqCm0rHFglIAdjX+wWdoNOHjfscpAl16qqoVlXENPSf/T4xQQfx0= =cvo+ -----END PGP SIGNATURE----- --Apple-Mail=_5CD86BFB-E2B3-4E89-BFA8-831D30D7DF20-- From brian.e.carpenter@gmail.com Tue Jan 28 15:53:22 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2774D1A036C for ; Tue, 28 Jan 2014 15:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJndwWcNMZ-2 for ; Tue, 28 Jan 2014 15:53:20 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 98A011A028F for ; Tue, 28 Jan 2014 15:53:20 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so1025973pbc.4 for ; Tue, 28 Jan 2014 15:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L3/UCXEI4naEt7oJ2+6SekwV/9Bo0vUHXTJmi76LH28=; b=zGupu7IT0uX/l+ce3I3SVF5nLNTMqXvQJkI1H6JIFA6ON4cPpk8QEroV9Taw/Vnvo4 l8HmNpvsgIXEr2OpvZhi7r0fumTZksrnFw7k+NZ+QznITKsFuarmLRDYATNYVRwSB5iJ wZUH0gBxI/Ctq+74uNyFYGEeV0kCvLt5ofZeYj0TWtYyTXsYblIrlT6yYVoLEJ/wbPPW DtQY5iAV8YKg4aO38uT4n1uH0dLWb2Wtv5+2QQB09lznJ/oaVk40sowUcxrrD7NEoako MC7xSRuGL4BCM8/ArZQH1r4IqbesuGeDCdJlAmJlBfGRVpp4xCnIgJ8Hy5/gw4ZJJE4D ubwg== X-Received: by 10.66.232.129 with SMTP id to1mr4552710pac.29.1390953198093; Tue, 28 Jan 2014 15:53:18 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id iq10sm649214pbc.14.2014.01.28.15.53.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 15:53:17 -0800 (PST) Message-ID: <52E842EE.2030508@gmail.com> Date: Wed, 29 Jan 2014 12:53:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Scott O. Bradner" References: <8FEC00FC-D83C-4FB2-8FE3-C8536CEAC814@sobco.com> In-Reply-To: <8FEC00FC-D83C-4FB2-8FE3-C8536CEAC814@sobco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] blast from the past X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:53:22 -0000 On 29/01/2014 12:39, Scott O. Bradner wrote: > I just remembered that we talked about setting a direction towards protection quite a while ago in RFC 1752 > (the IPv6 recommendation) > > We feel that an improvement in the basic level of security in the > Internet is vital to its continued success. Users must be able to > assume that their exchanges are safe from tampering, diversion and > exposure. Organizations that wish to use the Internet to conduct > business must be able to have a high level of confidence in the > identity of their correspondents and in the security of their > communications. The goal is to provide strong protection as a matter > of course throughout the Internet. > > Scott I also noticed that we said this in RFC 1958: 6.2 It is highly desirable that Internet carriers protect the privacy and authenticity of all traffic, but this is not a requirement of the architecture. Confidentiality and authentication are the responsibility of end users and must be implemented in the protocols used by the end users. Endpoints should not depend on the confidentiality or integrity of the carriers. Carriers may choose to provide some level of protection, but this is secondary to the primary responsibility of the end users to protect themselves. Brian From stephen.farrell@cs.tcd.ie Wed Jan 29 05:55:55 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ED21A02EA for ; Wed, 29 Jan 2014 05:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J55iVZKJcrMg for ; Wed, 29 Jan 2014 05:55:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 933391A02C8 for ; Wed, 29 Jan 2014 05:55:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0C9C7BE25 for ; Wed, 29 Jan 2014 13:55:48 +0000 (GMT) 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 sGqT4TSwvERh for ; Wed, 29 Jan 2014 13:55:47 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D90FEBDE3 for ; Wed, 29 Jan 2014 13:55:47 +0000 (GMT) Message-ID: <52E90863.5070805@cs.tcd.ie> Date: Wed, 29 Jan 2014 13:55:47 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 13:55:55 -0000 Hiya, One idea that came up in Vancouver and that we (meaning at least me:-) haven't had a chance to progress was the idea of trying to get a team of folks together to go do privacy reviews of existing RFCs. Or perhaps slightly differently, reviews that explicitly consider pervasive monitoring, which might be more constrained and a bit easier. I think Christian H. commented at the mic that there is probably a *lot* of low hanging fruit out there, and I suspect he's quite right:-) Now that we're in the run up to the London IETF, if some of you had time to try self-organise that kind of thing that'd be great. Any takers for trying to organise that? Using this list to start with should be fine, if it results in loads of traffic we can spin up a new one, or move over to ietf-privacy@ietf.org. If there are folks willing to take this on and having a side-meeting in London helps, I can get you a room for that. Thanks, S. From scott.brim@gmail.com Wed Jan 29 06:16:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC11A0395 for ; Wed, 29 Jan 2014 06:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbR-RGqMOhSP for ; Wed, 29 Jan 2014 06:16:07 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A70531A0207 for ; Wed, 29 Jan 2014 06:16:07 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id vb8so1987684obc.4 for ; Wed, 29 Jan 2014 06:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r26dfmJ3eFwNsNyzUqrJfSYCSrqO7UHWXIvSBov1uSw=; b=t5tOT+vHnzG2KJygd5DA0rRKWV12HtGOHn/4YxMy4YF0mebo8xQAyKEqpHtTJkGp0+ COHjo8Uasq4puARw9WeOjT5BcC1MXs+PKR2Ko4xn+XE8Ru5r4v+8R/i6tud7Em0vONvd 2BLpyso9mL5fi6Pv3Ls2hoWkxHRM63SYJXQT/XcD8VXUxmjPzdtCqbugyqr2KaQJCKP3 3QfiSG4bsXEdj7/ETYnrSSTG587UjbpiBuX+wurtDxWrkk8xrkSDT1EPhkYU2s9OP4Qq sAi4XK8yd5oYXcOa4dvBjtvLzm3yuW6T0F41kEMwtKJrf9kB4TWV5mVmpYH1hPF0C8XB D8Ug== MIME-Version: 1.0 X-Received: by 10.60.165.72 with SMTP id yw8mr605864oeb.71.1391004964727; Wed, 29 Jan 2014 06:16:04 -0800 (PST) Received: by 10.182.48.9 with HTTP; Wed, 29 Jan 2014 06:16:04 -0800 (PST) Received: by 10.182.48.9 with HTTP; Wed, 29 Jan 2014 06:16:04 -0800 (PST) In-Reply-To: <52E90863.5070805@cs.tcd.ie> References: <52E90863.5070805@cs.tcd.ie> Date: Wed, 29 Jan 2014 09:16:04 -0500 Message-ID: From: Scott Brim To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b41904bcdb1e704f11c94dd Cc: perpass Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:16:09 -0000 --047d7b41904bcdb1e704f11c94dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First, what are the goals of getting organized? =E2=98=BA Some of us alrea= dy consider privacy as a matter of course for new drafts (I do gen-art reviews in addition to WG reviews). I don't think we want to organize a group to comment on new material - it would be better get privacy/pm to be included in security considerations. My goal for a group would be to organize reviews of *existing* drafts/RFCs that are in common use. It shouldn't take a lot of work, maybe just a wiki page. I'm enthusiastic about having a side meeting in London. Scott --047d7b41904bcdb1e704f11c94dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

First, what are the goals of getting organized? =E2=98=BA=C2= =A0 Some of us already consider privacy as a matter of course for new draft= s (I do gen-art reviews in addition to WG reviews). I don't think we wa= nt to organize a group to comment on new material - it would be better get = privacy/pm to be included in security considerations. My goal for a group w= ould be to organize reviews of *existing* drafts/RFCs that are in common us= e. It shouldn't take a lot of work, maybe just a wiki page.

I'm enthusiastic about having a side meeting in London. =

Scott

--047d7b41904bcdb1e704f11c94dd-- From stephen.farrell@cs.tcd.ie Wed Jan 29 06:33:15 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABC1A0280 for ; Wed, 29 Jan 2014 06:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TsGopgsMcEo for ; Wed, 29 Jan 2014 06:33:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D66321A0207 for ; Wed, 29 Jan 2014 06:33:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1ED47BE29; Wed, 29 Jan 2014 14:33:07 +0000 (GMT) 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 ysPDUH2y8t7R; Wed, 29 Jan 2014 14:33:07 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9DBD1BE25; Wed, 29 Jan 2014 14:33:06 +0000 (GMT) Message-ID: <52E91122.9070807@cs.tcd.ie> Date: Wed, 29 Jan 2014 14:33:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim References: <52E90863.5070805@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: perpass Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:33:15 -0000 On 01/29/2014 02:16 PM, Scott Brim wrote: > First, what are the goals of getting organized? ☺ Fighting chaos chaotically:-) > Some of us already > consider privacy as a matter of course for new drafts (I do gen-art reviews > in addition to WG reviews). I don't think we want to organize a group to > comment on new material - it would be better get privacy/pm to be included > in security considerations. Absolutely. > My goal for a group would be to organize > reviews of *existing* drafts/RFCs that are in common use. It shouldn't take > a lot of work, maybe just a wiki page. Yep. I expect that the first thing to do would be that, to recruit some willing folks and then figure out what's doable based on their expertise, interests and available cycles, and on which RFCs that group figure might provide the best payoffs, e.g. RFcs that the group figured are likely to be revised/extended would probably be better targets than things we think won't or can't be changed. > > I'm enthusiastic about having a side meeting in London. Cool. I bet a bit of f2f discussion could be fruitful here if we can get some good folks in a room. S. > > Scott > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From klaas@wierenga.net Wed Jan 29 07:42:09 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39581A03FB for ; Wed, 29 Jan 2014 07:42:09 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TTWqMTiEtvA for ; Wed, 29 Jan 2014 07:42:07 -0800 (PST) Received: from out21-ams.mf.surf.net (out21-ams.mf.surf.net [145.0.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 709371A03E0 for ; Wed, 29 Jan 2014 07:42:06 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0TFfwtF008117; Wed, 29 Jan 2014 16:41:59 +0100 Received: from 173-38-208-169.cisco.com ([173.38.208.169] helo=dhcp-10-61-103-11.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1W8XD0-00050H-7l; Wed, 29 Jan 2014 16:37:46 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_583EEBBA-0393-457F-955D-177B978678C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Klaas Wierenga In-Reply-To: Date: Wed, 29 Jan 2014 16:41:57 +0100 Message-Id: References: <52E90863.5070805@cs.tcd.ie> To: Scott Brim X-Mailer: Apple Mail (2.1510) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uLjPFWS9 - 5c42364eb296 - 20140129 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: perpass , Stephen Farrell Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:42:10 -0000 --Apple-Mail=_583EEBBA-0393-457F-955D-177B978678C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Scott, On Jan 29, 2014, at 3:16 PM, Scott Brim wrote: > First, what are the goals of getting organized? =E2=98=BA Some of us = already consider privacy as a matter of course for new drafts (I do = gen-art reviews in addition to WG reviews). I don't think we want to = organize a group to comment on new material - it would be better get = privacy/pm to be included in security considerations. My goal for a = group would be to organize reviews of *existing* drafts/RFCs that are in = common use. It shouldn't take a lot of work, maybe just a wiki page. >=20 > I'm enthusiastic about having a side meeting in London. happy to be involved! Klaas --Apple-Mail=_583EEBBA-0393-457F-955D-177B978678C6 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 iEYEARECAAYFAlLpIUYACgkQH2Wy/p4XeFLzAgCgv0q21RXRp/IFxyGQesSiYGc1 T98AoKsA5/EvhoXAWF0Y6ZZdr7qJgLrd =A0Nc -----END PGP SIGNATURE----- --Apple-Mail=_583EEBBA-0393-457F-955D-177B978678C6-- From dcrocker@bbiw.net Wed Jan 29 07:51:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548031A0207 for ; Wed, 29 Jan 2014 07:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePsz_g2gv93Y for ; Wed, 29 Jan 2014 07:51:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 506D11A0230 for ; Wed, 29 Jan 2014 07:51:26 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0TFpFZD024909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jan 2014 07:51:18 -0800 Message-ID: <52E9235C.2030601@bbiw.net> Date: Wed, 29 Jan 2014 07:50:52 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <52E90863.5070805@cs.tcd.ie> In-Reply-To: <52E90863.5070805@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 29 Jan 2014 07:51:18 -0800 (PST) Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:51:27 -0000 On 1/29/2014 5:55 AM, Stephen Farrell wrote: > One idea that came up in Vancouver and that we (meaning at least > me:-) haven't had a chance to progress was the idea of trying to > get a team of folks together to go do privacy reviews of existing > RFCs. Or perhaps slightly differently, reviews that explicitly > consider pervasive monitoring, which might be more constrained > and a bit easier. ... > Now that we're in the run up to the London IETF, if some of you > had time to try self-organise that kind of thing that'd be great. > Any takers for trying to organise that? Doing reviews for attention to PM is really an experimental activity. We don't have a track record of those specific types of reviews and I believe we are some distance away from having a shared, usable model of what to review for. But we do need to develop it. So I think what you are proposing actually ought to be its own development project, with the goal of producing a document in the realm of "Guidelines for doing Pervasive Monitoring Reviews of IETF Specifications." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim@gmail.com Wed Jan 29 08:05:31 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224DC1A02C8 for ; Wed, 29 Jan 2014 08:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSLBgaHwx6Ol for ; Wed, 29 Jan 2014 08:05:29 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A667B1A029B for ; Wed, 29 Jan 2014 08:05:29 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id vb8so2151262obc.4 for ; Wed, 29 Jan 2014 08:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NekBeAfam/cZozu70zTWbGimph8HghTQJuhL8mIH2AA=; b=cYusUqu1/lTbZg5fw2F2Za8+nExcgV55Yc85308+D9VIh98qtK3Pcn/d3kaXnHGijv zjwteXWFGriZSKylidYTr6kYyhUnFsOUtem2uIoEaRbTfzySRQHyBOjujODKcF1RyNfd YOzcndYPkk/vMIpLQHb77S+1anAEdFCnL47PiWNMvAMWbjH/7Dr9ZF/40neG9lZ+PuJQ 4WGOcZc3NwAsEzz0//7q1nUtwqWlDpinvChBfsIsFJtaS4zeR24SoCaGQTVL902wtnur syOQ4MortSVVBkHJzVMN0gvp1sOxu4pMOcChsFwv6zZFUkesk3SKWErIMyTF56sF8r9l TW1w== X-Received: by 10.182.153.226 with SMTP id vj2mr7090811obb.26.1391011526671; Wed, 29 Jan 2014 08:05:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 29 Jan 2014 08:05:06 -0800 (PST) In-Reply-To: <52E9235C.2030601@bbiw.net> References: <52E90863.5070805@cs.tcd.ie> <52E9235C.2030601@bbiw.net> From: Scott Brim Date: Wed, 29 Jan 2014 11:05:06 -0500 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=089e013d0dc0ed047004f11e1bfd Cc: perpass , Stephen Farrell Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 16:05:31 -0000 --089e013d0dc0ed047004f11e1bfd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 29, 2014 at 10:50 AM, Dave Crocker wrote: > Doing reviews for attention to PM is really an experimental activity. We > don't have a track record of those specific types of reviews and I believe > we are some distance away from having a shared, usable model of what to > review for. > Yes we do, it's just not organized. For example, there was good discussion of the draft for IPv6 addressing in moving vehicles, and it led to changing the applicability. Maybe you're thinking we don't have an understanding of the attack vectors. That may be, but we do know what we want to protect. See the drafts/RFCs and slides from perpass. I think the criteria are pretty clear, they just take some digging to understand. > So I think what you are proposing actually ought to be its own development > project, with the goal of producing a document in the realm of "Guidelines > for doing Pervasive Monitoring Reviews of IETF Specifications." > That would be useful, as long as it's kept up to date. Scott --089e013d0dc0ed047004f11e1bfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 29, 2014 at 10:50 AM, Dave Crocker <dcrocker@bbiw.net> wrote:
Doing reviews for attention to PM is really an experimental activ= ity. We don't have a track record of those specific types of reviews an= d I believe we are some distance away from having a shared, usable model of= what to review for.

Yes we do, it's just not organized. Fo= r example, there was good discussion of the draft for IPv6 addressing in mo= ving vehicles, and it led to changing the applicability. Maybe you're t= hinking we don't have an understanding of the attack vectors. That may = be, but we do know what we want to protect. See the drafts/RFCs and slides = from perpass. I think the criteria are pretty clear, they just take some di= gging to understand.
=A0
So I think what you are proposing actually ought t= o be its own development project, with the goal of producing a document in = the realm of "Guidelines for doing Pervasive Monitoring Reviews of IET= F Specifications."

That would be useful, as long as it's = kept up to date.=A0

Scott
--089e013d0dc0ed047004f11e1bfd-- From spencerdawkins.ietf@gmail.com Wed Jan 29 08:06:08 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01E1A029B for ; Wed, 29 Jan 2014 08:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpPC5S10tHOx for ; Wed, 29 Jan 2014 08:06:07 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 355501A02C8 for ; Wed, 29 Jan 2014 08:06:06 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i7so2233210oag.36 for ; Wed, 29 Jan 2014 08:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=W9edKPKgCyAKbxICmMLJO5MVO6KRLwsRiFzgw0RGSBA=; b=ZUvsIScMhQd8Jg11KOlAKs6tAHQ3t98pdieNUloRxdbdebkRQo1Q7LskGgihetfbsM 4a97vI6FjfyTpmUjMV3bguAUplJ+M1roJvtM5Vne1wlz9QbINadPCiO/IL6cSzShjjAw P+N/1NK1DBtk8v+c/PjdP/MyvuvnLVozXDAZ7V+/aCwJAHXslYsMV5sVlK3L6Z9uwF3s jwKSiYX9K/HryVNRli7AdBs9+8khasbYLAZSgVxQRECjebfJ244O7MtgjfcxGi+4GuVA xQuxl50ROrPOAmMhIORTHCD+Kdj60kQoYbqQUT2gm6n8uiPKCXeLMIl/RjQ8/7tcoDAb t5cw== X-Received: by 10.182.142.37 with SMTP id rt5mr1034037obb.76.1391011563266; Wed, 29 Jan 2014 08:06:03 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id m7sm4674880obo.7.2014.01.29.08.06.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 08:06:02 -0800 (PST) Message-ID: <52E926E8.4040803@gmail.com> Date: Wed, 29 Jan 2014 10:06:00 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Crocker , Stephen Farrell , perpass References: <52E90863.5070805@cs.tcd.ie> <52E9235C.2030601@bbiw.net> In-Reply-To: <52E9235C.2030601@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 16:06:08 -0000 I should be assuming that everyone else has already thought of this, but ... On 01/29/2014 09:50 AM, Dave Crocker wrote: > On 1/29/2014 5:55 AM, Stephen Farrell wrote: >> One idea that came up in Vancouver and that we (meaning at least >> me:-) haven't had a chance to progress was the idea of trying to >> get a team of folks together to go do privacy reviews of existing >> RFCs. Or perhaps slightly differently, reviews that explicitly >> consider pervasive monitoring, which might be more constrained >> and a bit easier. > ... >> Now that we're in the run up to the London IETF, if some of you >> had time to try self-organise that kind of thing that'd be great. >> Any takers for trying to organise that? > > > Doing reviews for attention to PM is really an experimental activity. > We don't have a track record of those specific types of reviews and I > believe we are some distance away from having a shared, usable model > of what to review for. > > But we do need to develop it. > > So I think what you are proposing actually ought to be its own > development project, with the goal of producing a document in the > realm of "Guidelines for doing Pervasive Monitoring Reviews of IETF > Specifications." Dave's suggestion is likely a great second-wave suggestion. I took Stephen's suggestion and offer of a room as a great first-wave suggestion, and I had assumed that we weren't talking about reviewing all 7000-odd existing RFCs, but that people likely have a few widely deployed protocols in mind where they're already worrying about privacy aspects, reviewing widely deployed protocols that people are already worried about would be useful on its own, and might very well be the basis for developing guidelines that Dave is suggesting. So, the worriers would self-organize in London as a first step. If I got that wrong, my bad, and I'll go annoy people about transport issues, of course :-) Spencer From hallam@gmail.com Wed Jan 29 09:11:19 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96B41A03F9 for ; Wed, 29 Jan 2014 09:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxjyTXLUh2DC for ; Wed, 29 Jan 2014 09:11:14 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 411981A03E9 for ; Wed, 29 Jan 2014 09:11:14 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so1677513lbv.38 for ; Wed, 29 Jan 2014 09:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9Q7263fSu04JoEQ9ZcsPrt27Dsz8eljxxlRcxN5MYz8=; b=HGf+2h8RCD0+NCKnd+QlQdK/44wz0w8Lzp73keFVEI6tXAr9A1ukl88F1PE3EEVrOP zctDqSvlp5xskjlbAeeprtT24LyJvHDdSmTEZXZ4TJfmuldrurdvjZlLKMaxelOIHle3 HZKy++yQXG3hiqDsaaVhJLD6kcITzUqDn2VW+P/QHPxnbT/uqA8qOSDAsJTWE1cCh0gX e6F3XGb33OKTk7v3Ttk2I1344AyzPjOeR1MhIXu2NUwLcPVjKlwGBVGS1IxXmLNkG0qc sAGY5K6vly1RJDXoJCH1VPaxwGahNjOCwphnpmi83X2/33HHi47A0JcvzAR8E/q6LrWl 5DxA== MIME-Version: 1.0 X-Received: by 10.152.87.142 with SMTP id ay14mr6041125lab.7.1391015470455; Wed, 29 Jan 2014 09:11:10 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 29 Jan 2014 09:11:10 -0800 (PST) Date: Wed, 29 Jan 2014 12:11:10 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c3560cfe5ed204f11f067c Subject: [perpass] Security delivery model X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:11:20 -0000 --001a11c3560cfe5ed204f11f067c Content-Type: text/plain; charset=ISO-8859-1 If we are going to secure the net we need more than specifications, we need running code and configurations to match. Right now the problems caused by us using SHA1 are vastly less than the problems caused by systems that are just terribly configured or don't make the right security checks. I have an exploit that lets me dump out usernames and passwords enclair from certain applications despite the apparent use of 'security' because most of the clients and many of the servers out there are not configured right. But it does not currently even merit a CERT advisory because it isn't a bug in the code or the specification, it is a configuration failure. So here is the proposal, IETF and W3C develop a series of profiles for how to lock down a service (Web, mail, chat) that provide specific security protections against specified attacks. The suite would also include profiles for backbone, datacenter providers etc. These profiles can then form the basis for a range of security services that can be fulfilled by providers as appropriate to the needs of the clients. So for example, Comodo and the other CAs and some of the DNS registrars can pitch in on the retail end and provide 'off the shelf' services that are locked down to a calibrated security profile. Then at the other end of the scale very large enterprises with a designated CISO would call in the likes of big consulting companies to deploy. There would also be business opportunities for independent consultants. In fact I am not sure that the retail model is going to be viable unless I can tell an unprofitable customer that their needs are beyond what the flat service fee model can support and they need to contact an independent contractor. This is of course something the industry has traditionally looked to NIST to provide. But lets face it, that model is dead. It might be five years before we can get people in a room together. Meanwhile we face real threats. I see a number of questions here, one of which is what the appropriate venue is. Another is what community should be involved. While this probably needs to be an IETF or W3C activity it need not necessarily take place at IETF meetings. A technical session lumped onto the front of Blackhat while the admin type folk are in the training sessions might well be a better venue. We probably want to follow up on Jim Getty's advice to connect to the Linux Plumbers. Security protocol designers are not the best folk for finding holes because most of the holes are created by people doing stuff that is just so stupid most of us would never think to do it. But the work does need to be done somewhere and it needs to be an open, unencumbered specification that draws on open standards. -- Website: http://hallambaker.com/ --001a11c3560cfe5ed204f11f067c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we are going to secure the net we need more than specif= ications, we need running code and configurations to match.

<= div>Right now the problems caused by us using SHA1 are vastly less than the= problems caused by systems that are just terribly configured or don't = make the right security checks.

I have an exploit that lets me dump out usernames and p= asswords enclair from certain applications despite the apparent use of '= ;security' because most of the clients and many of the servers out ther= e are not configured right. But it does not currently even merit a CERT adv= isory because it isn't a bug in the code or the specification, it is a = configuration failure.


So here is the proposal, IETF and W3C de= velop a series of profiles for how to lock down a service (Web, mail, chat)= that provide specific security protections against specified attacks. The = suite would also include profiles for backbone, datacenter providers etc.

These profiles can then form the basis for a range of s= ecurity services that can be fulfilled by providers as appropriate to the n= eeds of the clients.

So for example, Comodo and th= e other CAs and some of the DNS registrars can pitch in on the retail end a= nd provide 'off the shelf' services that are locked down to a calib= rated security profile. Then at the other end of the scale very large enter= prises with a designated CISO would call in the likes of big consulting com= panies to deploy.

There would also be business opportunities for independ= ent consultants. In fact I am not sure that the retail model is going to be= viable unless I can tell an unprofitable customer that their needs are bey= ond what the flat service fee model can support and they need to contact an= independent contractor.=A0


This is of course something the = industry has traditionally looked to NIST to provide. But lets face it, tha= t model is dead. It might be five years before we can get people in a room = together. Meanwhile we face real threats.

I see a number of questions here, one of which is what = the appropriate venue is. Another is what community should be involved. Whi= le this probably needs to be an IETF or W3C activity it need not necessaril= y take place at IETF meetings. A technical session lumped onto the front of= Blackhat while the admin type folk are in the training sessions might well= be a better venue. We probably want to follow up on Jim Getty's advice= to connect to the Linux Plumbers.=A0

Security protocol designers are not the best folk for f= inding holes because most of the holes are created by people doing stuff th= at is just so stupid most of us would never think to do it.=A0

But the work does need to be done somewhere and it needs to = be an open, unencumbered specification that draws on open standards.
<= div>
--
Website: http://ha= llambaker.com/
--001a11c3560cfe5ed204f11f067c-- From kent@bbn.com Wed Jan 29 11:35:13 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1F51A0363 for ; Wed, 29 Jan 2014 11:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmLX0Z3GKu4T for ; Wed, 29 Jan 2014 11:35:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8A1A0240 for ; Wed, 29 Jan 2014 11:35:03 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53773) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W8aua-000A8H-AE for perpass@ietf.org; Wed, 29 Jan 2014 14:35:00 -0500 Message-ID: <52E957E4.4000303@bbn.com> Date: Wed, 29 Jan 2014 14:35:00 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <52DE9174.7000504@bbn.com> <52DEA0BF.3020507@bbn.com> <52DFDA03.3060608@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090301030805030904000703" Subject: Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 19:35:14 -0000 This is a multi-part message in MIME format. --------------090301030805030904000703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/22/14 11:40 AM, Phillip Hallam-Baker wrote: > I find it rather interesting that someone who takes great offense when > it is pointed out that he works under contract to the NSA goes after > people for having a 'hidden' agenda. > > If you want to start questioning people's ulterior or bought motives > you are sawing off a mighty fine branch there and its the one you are > standing on. > > Is the reason that you are arguing against Omnibroker so hard because > someone in Fort Meade is getting nervous? Maybe they should, they had > three people come to see my first public talk on PRISM-PROOF email. Or > is it impolite for me to ask such questions because you are the only > person allowed to call people's motives into question? PHB, I'm pretty sure communism didn't enter into my comments on your proposals :-). I also have no idea whether anyone at NSA has any interest in Omnibroker. To the extent that it represents an opportunity for centralizing and outsourcing trust services, I can imagine some there might even find it attractive :-). I have absolutely no desire to watch any YouTube videos you have produced. I'd like to think that, during over 30 years of participation in Internet standards, my agenda has never been hidden. Yes, I am a government contractor. I have received funding from various parts of the DoD (including DARPA, DCA, Army, Navy, etc.) the DHS, and otherorganizations. In most cases, and for all of my recent funding (say, over the past 20ish years) the work I do is the result of what I have proposed to funding organizations, because I think it is useful for improving Internet security. I don't tend to bid on BAAs or RFPs from funding agencies; instead, I approach them, describe security problems I think are important and where I think I can help, and ask for money to do the work. Sometimes I get funds, sometimes not. But my agenda is overt. Sometimes IETF participants have asked why I participate in the IETF, since I am do not work for a product company or a service provider, and I've explained, as above. For example, my work on IPsec was motivated by years of experience with layer 3 security technology. When I began working at BBN, in the later 70's, we had an ARPA (now DARPA) project to build the first packet network encryption system, using a KDC. I worked on that project, extending the architecture to accommodate multiple KDCs (for robustness) and to enable establishing security associations across administrative domains. The hardware we used (inline hardware crypto, built by another government contractor) employed the first DES chips certified by NBS (now NIST). BBN wrote the software, which worked with early versions of TCP and IP. This work was completed, including performance testing, several years before MIT initiated Project Athena, and developed Kerberos. In the latter 80's and early 90's I was a participant in the SDNS (Secure Data Network Systems) program (which was sponsored by NSA) to develop network layer crypto systems for protecting DoD classified data. That program developed SP3, a precursor to IPsec, and MSP, some aspects of which appear in S/MIME. The MSP work leveraged my experience leading work on PEM, the first e-mail Internet standard security protocol. (PEM was initially developed initially in the Privacy and Security Research Group, then in the PEM WG, both of which I chaired.) This showed that DoD-sponsored work canbenefit from work performed in the "outside" world. In the late 90's and through 2005, I contributed to, and eventually became responsible for, the IPsec RFCs, bringing to that effort some of the experience I gained in the SDNS program. (BTW, all of the SDNS protocol specs were unclassified, because NSA wanted vendors to use them in buildingsystems to protect unclassified, as well as classified, data.) So, in this case, experience flowed from government work to the public standards sector. At one time NSA bought into what the big telecom providers were saying, and created network layer crypto that worked only with ATM. This was brought to my attention by a router vendor, who was hoping to sell products to DoD clients, who could not use the routers because they were not compatible with the latest, fastest crypto available for protecting classified data. When I because aware of this I urged NSA to revisit IP-based network crypto. They had been told that IP-based crypto systems would be slow, compared to the ATM-based systems they were fielding. So, some colleagues at BBN and I designed a 10Gb/s IP crypto device (that used DoD algorithms approved to protect classified data), to demonstrate that IP crypto could be fast. That effort (yes, we were paid!) led to a significant program change, so that when ATM stopped being the "next big thing" and fast IP routers were available, there were network layer crypto devices that would work with them. The resulting products were called HAIPEs (High Assurance IP Encryptors). I wasn't pleased with all aspects of those products, but at least we avoided the ATM dead end J. I chaired PKIX for about 18 years; part of the funding for my participation came from the DoD. They were making a big investment in PKI and were willing to help support work that advanced PKI standards. They became a big user of OCSP (not my personal, favorite protocol, but ...) and thus benefitted from the existence of an IETF WG that offered a forum for developing PKI standards. My co-chairs over this time included folks from the PKI industry, NIST, and Microsoft. Since the last 90's I have worked on architectures to improve inter-domain routing security. This work was sponsored initially by DARPA, and later received DHS funds, in part because the principal sponsor moved from DARPA to DHS! My work in SIDR, on the RPKI and BGPSEC, has been paid for by DHS and DoD, because they see the need for better routing security. Nothing mysterious there. Overall, I am pretty proud of the work I have done in the IETF, the 22 (soon to be 23) RFCs that I've published, my time on the IAB, chairing the PSRG, PEM and PKIX WGs, serving on four Nomcoms, and my contributions to other WGs. In all of the years that I have worked on Internet standards the only RFC that recall writing in response to a request from the DoD was my first, RFC 1108. That RFC (published in 1991) described the IPv4 basic and extended security options, as implemented in a DoD network crypto system (BLACKER) of the 80's. I don't think that work, or anything I have done since, makes me an agent provocateur. Steve --------------090301030805030904000703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/22/14 11:40 AM, Phillip Hallam-Baker wrote:
I find it rather interesting that someone who takes great offense when it is pointed out that he works under contract to the NSA goes after people for having a 'hidden' agenda.

If you want to start questioning people's ulterior or bought motives you are sawing off a mighty fine branch there and its the one you are standing on.

Is the reason that you are arguing against Omnibroker so hard because someone in Fort Meade is getting nervous? Maybe they should, they had three people come to see my first public talk on PRISM-PROOF email. Or is it impolite for me to ask such questions because you are the only person allowed to call people's motives into question?

PHB,

 

I'm pretty sure communism didn't enter into my comments on your proposals :-).

I also have no idea whether anyone at NSA has any interest in Omnibroker. To
the extent that it represents an opportunity for centralizing and outsourcing
trust services, I can imagine some there might even find it attractive :-).


I have absolutely no desire to watch any YouTube videos you have produced.



I’d like to think that, during over 30 years of participation in Internet standards, my agenda has never been hidden. Yes, I am a government contractor. I have received funding from various parts of the DoD (including DARPA, DCA, Army, Navy, etc.) the DHS, and other organizations. In most cases, and for all of my recent funding (say, over the past 20ish years) the work I do is the result of what I have proposed to funding organizations, because I think it is useful for improving Internet security. I don’t tend to bid on BAAs or RFPs from funding agencies; instead, I approach them, describe security problems I think are important and where I think I can help, and ask for money to do the work. Sometimes I get funds, sometimes not. But my agenda is overt. Sometimes IETF participants have asked why I participate in the IETF, since I am do not work for a product company or a service provider, and I’ve explained, as above.

 

For example, my work on IPsec was motivated by years of experience with layer 3 security technology. When I began working at BBN, in the later 70’s, we had an ARPA (now DARPA) project to build the first packet network encryption system, using a KDC. I worked on that project, extending the architecture to accommodate multiple KDCs (for robustness) and to enable establishing security associations across administrative domains. The hardware we used (inline hardware crypto, built by another government contractor) employed the first DES chips certified by NBS (now NIST). BBN wrote the software, which worked with early versions of TCP and IP. This work was completed, including performance testing, several years before MIT initiated Project Athena, and developed Kerberos.

 

In the latter 80’s and early 90’s I was a participant in the SDNS (Secure Data Network Systems) program (which was sponsored by NSA) to develop network layer crypto systems for protecting DoD classified data. That program developed SP3, a precursor to IPsec, and MSP, some aspects of which appear in S/MIME. The MSP work leveraged my experience leading work on PEM, the first e-mail Internet standard security protocol. (PEM was initially developed initially in the Privacy and Security Research Group, then in the PEM WG, both of which I chaired.) This showed that DoD-sponsored work can  benefit from work performed in the “outside” world.

 

In the late 90’s and through 2005, I contributed to, and eventually became responsible for, the IPsec RFCs, bringing to that effort some of the experience I gained in the SDNS program. (BTW, all of the SDNS protocol specs were unclassified, because NSA wanted vendors to use them in building  systems to protect unclassified, as well as classified, data.) So, in this case, experience flowed from government work to the public standards sector.

 

At one time NSA bought into what the big telecom providers were saying, and created network layer crypto that worked only with ATM. This was brought to my attention by a router vendor, who was hoping to sell products to DoD clients, who could not use the routers because they were not compatible with the latest, fastest crypto available for protecting classified data. When I because aware of this I urged NSA to revisit IP-based network crypto. They had been told that IP-based crypto systems would be slow, compared to the ATM-based systems they were fielding. So, some colleagues at BBN and I designed a 10Gb/s IP crypto device (that used DoD algorithms approved to protect classified data), to demonstrate that IP crypto could be fast. That effort (yes, we were paid!) led to a significant program change, so that when ATM stopped being the “next big thing” and fast IP routers were available, there were network layer crypto devices that would work with them. The resulting products were called HAIPEs (High Assurance IP Encryptors). I wasn’t pleased with all aspects of those products, but at least we avoided the ATM dead end J.

 

I chaired PKIX for about 18 years; part of the funding for my participation came from the DoD. They were making a big investment in PKI and were willing to help support work that advanced PKI standards. They became a big user of OCSP (not my personal, favorite protocol, but …) and thus benefitted from the existence of an IETF WG that offered a forum for developing PKI standards. My co-chairs over this time included folks from the PKI industry, NIST, and Microsoft.  

 

Since the last 90’s I have worked on architectures to improve inter-domain routing security. This work was sponsored initially by DARPA, and later received DHS funds, in part because the principal sponsor moved from DARPA to DHS! My work in SIDR, on the RPKI and BGPSEC, has been paid for by DHS and DoD, because they see the need for better routing security. Nothing mysterious there.

 

Overall, I am pretty proud of the work I have done in the IETF, the 22 (soon to be 23) RFCs that I’ve published, my time on the IAB, chairing the PSRG, PEM and PKIX WGs, serving on four Nomcoms, and my contributions to other WGs. In all of the years that I have worked on Internet standards the only RFC that recall writing in response to a request from the DoD was my first, RFC 1108. That RFC (published in 1991) described the IPv4 basic and extended security options, as implemented in a DoD network crypto system (BLACKER) of the 80’s. I don’t think that work, or anything I have done since, makes me an agent provocateur.

Steve



--------------090301030805030904000703-- From w.pienciak@ieee.org Thu Jan 30 08:49:37 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304D91A0433 for ; Thu, 30 Jan 2014 08:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dUydOD-ia34 for ; Thu, 30 Jan 2014 08:49:34 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD51A0421 for ; Thu, 30 Jan 2014 08:49:34 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h16so3872660oag.24 for ; Thu, 30 Jan 2014 08:49:31 -0800 (PST) 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-type; bh=EHTgfP5xd6Ha2S17ATK3FCmHeR5POSc8LzhDz4vnz+g=; b=JunHujK0VAdkw+T67DECi/D06wVTKYJrfmjAijYG6xeC7ji58jfw0GosUpLficjMtw Wm/7Jcl4G0BK93fxk78t14Q4BaShA0t9akXeodFi6iOpDwuuqsnPhkg/gJXguYA7y8EL XzAoSb6uVA18QVkNIhX0XldRxU79w2x/p+Fn/P9B5fJkeDSTXCVfenWiQKdRuOpaLD/K 3M2UIU6v5GDAbNrrUvwSWykZV89Ce4lnbY5bWcG9n5a3+DxUNeZ43ijRLAz5BZKwImnA EeS6DVfeb2AE3ASYYLCg8sEIQsXgZ8f3o8jJrOqArqFju5uVDwzCUXM1kClb3qU5mXcN RBpA== X-Gm-Message-State: ALoCoQlHTg80+AYrvv06iOMsXXroQ//NQReo5zQTt5XIf2zUqqWLTdyfL5rxI11fnnGUH2/j6s3k X-Received: by 10.182.135.194 with SMTP id pu2mr12395703obb.38.1391100571322; Thu, 30 Jan 2014 08:49:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.172.133 with HTTP; Thu, 30 Jan 2014 08:49:11 -0800 (PST) In-Reply-To: References: From: Walter Pienciak Date: Thu, 30 Jan 2014 09:49:11 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e0122a6c066a4bb04f132d753 Cc: perpass Subject: Re: [perpass] Security delivery model X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 16:49:37 -0000 --089e0122a6c066a4bb04f132d753 Content-Type: text/plain; charset=ISO-8859-1 "Best practices" implementation guides have real value. We've seen them developed for specific application/platform deployment, and other organizations such as USENIX and SANS have shown there is a demand for them by the folks in the trenches. I agree that standards/protocols guides are much more uncommon; to what extent that is due to "out of scope" determination by the employers of standards developers is an open question. But to reiterate: "best practices" guides with a security focus would be a valuable addition to the many efforts underway already. Inexpertly administrated resources will always be an issue, no matter the efforts ranging from random number generation through hardening of transport and data exchange. Walter Walter Pienciak Senior Manager, Technology Community, IEEE Standards Association w.pienciak@ieee.org +1 303 527 0934 On Wed, Jan 29, 2014 at 10:11 AM, Phillip Hallam-Baker wrote: > If we are going to secure the net we need more than specifications, we > need running code and configurations to match. > > Right now the problems caused by us using SHA1 are vastly less than the > problems caused by systems that are just terribly configured or don't make > the right security checks. > > I have an exploit that lets me dump out usernames and passwords enclair > from certain applications despite the apparent use of 'security' because > most of the clients and many of the servers out there are not configured > right. But it does not currently even merit a CERT advisory because it > isn't a bug in the code or the specification, it is a configuration failure. > > > So here is the proposal, IETF and W3C develop a series of profiles for how > to lock down a service (Web, mail, chat) that provide specific security > protections against specified attacks. The suite would also include > profiles for backbone, datacenter providers etc. > > These profiles can then form the basis for a range of security services > that can be fulfilled by providers as appropriate to the needs of the > clients. > > So for example, Comodo and the other CAs and some of the DNS registrars > can pitch in on the retail end and provide 'off the shelf' services that > are locked down to a calibrated security profile. Then at the other end of > the scale very large enterprises with a designated CISO would call in the > likes of big consulting companies to deploy. > > There would also be business opportunities for independent consultants. In > fact I am not sure that the retail model is going to be viable unless I can > tell an unprofitable customer that their needs are beyond what the flat > service fee model can support and they need to contact an independent > contractor. > > > This is of course something the industry has traditionally looked to NIST > to provide. But lets face it, that model is dead. It might be five years > before we can get people in a room together. Meanwhile we face real threats. > > I see a number of questions here, one of which is what the appropriate > venue is. Another is what community should be involved. While this probably > needs to be an IETF or W3C activity it need not necessarily take place at > IETF meetings. A technical session lumped onto the front of Blackhat while > the admin type folk are in the training sessions might well be a better > venue. We probably want to follow up on Jim Getty's advice to connect to > the Linux Plumbers. > > Security protocol designers are not the best folk for finding holes > because most of the holes are created by people doing stuff that is just so > stupid most of us would never think to do it. > > But the work does need to be done somewhere and it needs to be an open, > unencumbered specification that draws on open standards. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --089e0122a6c066a4bb04f132d753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"Best practices" implementation guides have real= value. =A0We've seen them developed for specific application/platform = deployment, and other organizations such as USENIX and SANS have shown ther= e is a demand for them by the folks in the trenches. =A0I agree that standa= rds/protocols guides are much more uncommon; to what extent that is due to = "out of scope" determination by the employers of
standards developers is an open question.

But to reiterate: =A0"best practices" guides with a security = focus would be a valuable addition to the many efforts underway already. = =A0Inexpertly administrated resources will always be an issue, no matter th= e efforts ranging from random number generation through hardening of transp= ort and data exchange.

Walter


Walter Pienci= ak
Senior Manager, Technology Community, IEEE Standards Associati= on

+1 303 527 0934


On Wed, Jan 29, 2014 at 10:11 AM, Philli= p Hallam-Baker <hallam@gmail.com> wrote:
If we are going to secure the net we need more than specif= ications, we need running code and configurations to match.

<= div>Right now the problems caused by us using SHA1 are vastly less than the= problems caused by systems that are just terribly configured or don't = make the right security checks.

I have an exploit that lets me dump out usernames and p= asswords enclair from certain applications despite the apparent use of '= ;security' because most of the clients and many of the servers out ther= e are not configured right. But it does not currently even merit a CERT adv= isory because it isn't a bug in the code or the specification, it is a = configuration failure.


So here is the proposal, IETF and W3C de= velop a series of profiles for how to lock down a service (Web, mail, chat)= that provide specific security protections against specified attacks. The = suite would also include profiles for backbone, datacenter providers etc.

These profiles can then form the basis for a range of s= ecurity services that can be fulfilled by providers as appropriate to the n= eeds of the clients.

So for example, Comodo and th= e other CAs and some of the DNS registrars can pitch in on the retail end a= nd provide 'off the shelf' services that are locked down to a calib= rated security profile. Then at the other end of the scale very large enter= prises with a designated CISO would call in the likes of big consulting com= panies to deploy.

There would also be business opportunities for independ= ent consultants. In fact I am not sure that the retail model is going to be= viable unless I can tell an unprofitable customer that their needs are bey= ond what the flat service fee model can support and they need to contact an= independent contractor.=A0


This is of course something the = industry has traditionally looked to NIST to provide. But lets face it, tha= t model is dead. It might be five years before we can get people in a room = together. Meanwhile we face real threats.

I see a number of questions here, one of which is what = the appropriate venue is. Another is what community should be involved. Whi= le this probably needs to be an IETF or W3C activity it need not necessaril= y take place at IETF meetings. A technical session lumped onto the front of= Blackhat while the admin type folk are in the training sessions might well= be a better venue. We probably want to follow up on Jim Getty's advice= to connect to the Linux Plumbers.=A0

Security protocol designers are not the best folk for f= inding holes because most of the holes are created by people doing stuff th= at is just so stupid most of us would never think to do it.=A0

But the work does need to be done somewhere and it needs to = be an open, unencumbered specification that draws on open standards.
<= span class=3D"HOEnZb">

--
Website= : http://hallambaker.= com/

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


--089e0122a6c066a4bb04f132d753-- From oritl@microsoft.com Thu Jan 30 09:04:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43E51A043B for ; Thu, 30 Jan 2014 09:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOY1xvsGLfD8 for ; Thu, 30 Jan 2014 09:04:14 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id E036E1A0419 for ; Thu, 30 Jan 2014 09:04:13 -0800 (PST) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB289.namprd03.prod.outlook.com (10.141.68.12) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 30 Jan 2014 17:04:09 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0859.020; Thu, 30 Jan 2014 17:04:09 +0000 From: "Orit Levin (LCA)" To: Walter Pienciak , Phillip Hallam-Baker Thread-Topic: [perpass] Security delivery model Thread-Index: AQHPHRUjydIFxbKM80eGeYEwKU58YpqdfDuAgAABqlA= Date: Thu, 30 Jan 2014 17:04:09 +0000 Message-ID: <7e8748c166874d30aade0dcb77c6dbe9@BL2PR03MB290.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.247.123.117] x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(24454002)(199002)(377454003)(31966008)(87266001)(46102001)(53806001)(15975445006)(54356001)(81816001)(81686001)(19580405001)(50986001)(85306002)(4396001)(47976001)(15395725003)(47446002)(74502001)(74662001)(76786001)(76576001)(47736001)(87936001)(76796001)(69226001)(19580395003)(83322001)(81342001)(56816005)(2656002)(51856001)(92566001)(80976001)(93136001)(74706001)(74316001)(80022001)(65816001)(90146001)(81542001)(86362001)(94316002)(54316002)(66066001)(79102001)(74366001)(49866001)(33646001)(76482001)(93516002)(74876001)(63696002)(77982001)(94946001)(551544002)(561944002)(15202345003)(56776001)(83072002)(85852003)(59766001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB289; H:BL2PR03MB290.namprd03.prod.outlook.com; CLIP:98.247.123.117; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: perpass Subject: Re: [perpass] Security delivery model X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:04:17 -0000 Good points. In the meanwhile, we invite you to join the effort at UTA http://datatracke= r.ietf.org/wg/uta/charter/ . Orit. From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Walter Piencia= k Sent: Thursday, January 30, 2014 8:49 AM To: Phillip Hallam-Baker Cc: perpass Subject: Re: [perpass] Security delivery model "Best practices" implementation guides have real value. =A0We've seen them = developed for specific application/platform deployment, and other organizat= ions such as USENIX and SANS have shown there is a demand for them by the f= olks in the trenches. =A0I agree that standards/protocols guides are much m= ore uncommon; to what extent that is due to "out of scope" determination by= the employers of standards developers is an open question. But to reiterate: =A0"best practices" guides with a security focus would be= a valuable addition to the many efforts underway already. =A0Inexpertly ad= ministrated resources will always be an issue, no matter the efforts rangin= g from random number generation through hardening of transport and data exc= hange. Walter Walter Pienciak Senior Manager, Technology Community, IEEE Standards Association w.pienciak@ieee.org +1 303 527 0934 On Wed, Jan 29, 2014 at 10:11 AM, Phillip Hallam-Baker w= rote: If we are going to secure the net we need more than specifications, we need= running code and configurations to match. Right now the problems caused by us using SHA1 are vastly less than the pro= blems caused by systems that are just terribly configured or don't make the= right security checks. I have an exploit that lets me dump out usernames and passwords enclair fro= m certain applications despite the apparent use of 'security' because most = of the clients and many of the servers out there are not configured right. = But it does not currently even merit a CERT advisory because it isn't a bug= in the code or the specification, it is a configuration failure. So here is the proposal, IETF and W3C develop a series of profiles for how = to lock down a service (Web, mail, chat) that provide specific security pro= tections against specified attacks. The suite would also include profiles f= or backbone, datacenter providers etc. These profiles can then form the basis for a range of security services tha= t can be fulfilled by providers as appropriate to the needs of the clients. So for example, Comodo and the other CAs and some of the DNS registrars can= pitch in on the retail end and provide 'off the shelf' services that are l= ocked down to a calibrated security profile. Then at the other end of the s= cale very large enterprises with a designated CISO would call in the likes = of big consulting companies to deploy. There would also be business opportunities for independent consultants. In = fact I am not sure that the retail model is going to be viable unless I can= tell an unprofitable customer that their needs are beyond what the flat se= rvice fee model can support and they need to contact an independent contrac= tor.=A0 This is of course something the industry has traditionally looked to NIST t= o provide. But lets face it, that model is dead. It might be five years bef= ore we can get people in a room together. Meanwhile we face real threats. I see a number of questions here, one of which is what the appropriate venu= e is. Another is what community should be involved. While this probably nee= ds to be an IETF or W3C activity it need not necessarily take place at IETF= meetings. A technical session lumped onto the front of Blackhat while the = admin type folk are in the training sessions might well be a better venue. = We probably want to follow up on Jim Getty's advice to connect to the Linux= Plumbers.=A0 Security protocol designers are not the best folk for finding holes because= most of the holes are created by people doing stuff that is just so stupid= most of us would never think to do it.=A0 But the work does need to be done somewhere and it needs to be an open, une= ncumbered specification that draws on open standards. --=20 Website: http://hallambaker.com/ _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Thu Jan 30 09:28:46 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192D61A0433 for ; Thu, 30 Jan 2014 09:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCCHvZPECYaH for ; Thu, 30 Jan 2014 09:28:43 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 43E9F1A03E0 for ; Thu, 30 Jan 2014 09:28:43 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id c11so2774357lbj.16 for ; Thu, 30 Jan 2014 09:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SHXf/w8MV3VT6VTk3/1P/7xizLp+uj56iaI6pMQ2HxI=; b=hX7zZX1RZz7pwQXiFqn2LRB6S90fpqt+I1gsp4NKSL3YndnEUam04+QYS2tvhz5vet aDkXiL3Ecgvwi4kbtlEVDy+lcnZ7JUlG6kBsr/YH4L31kO7qXtwMDF810+bIoiyEwhxf 68Zm7fraM0j8WCrN0SHLR4WXetLl7uO7tPt8b6MnT2RaYcWkN5WTN0xH6/wOoxvn7oyU putQBpRffhyGGDUBxRq4XQeu4jI/8Rnlzd+1C8y7UHz1jgMX4MJKMYR8GY89BhUBCibA yF31fOtco4HjlDSAVNGD+FKbvhCIa1YjSPVfDY2kxQLCDUW9EK04211H/mh83D2UMYE1 Tatw== MIME-Version: 1.0 X-Received: by 10.112.138.233 with SMTP id qt9mr2358044lbb.34.1391102919117; Thu, 30 Jan 2014 09:28:39 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 30 Jan 2014 09:28:39 -0800 (PST) In-Reply-To: <7e8748c166874d30aade0dcb77c6dbe9@BL2PR03MB290.namprd03.prod.outlook.com> References: <7e8748c166874d30aade0dcb77c6dbe9@BL2PR03MB290.namprd03.prod.outlook.com> Date: Thu, 30 Jan 2014 12:28:39 -0500 Message-ID: From: Phillip Hallam-Baker To: "Orit Levin (LCA)" Content-Type: multipart/alternative; boundary=089e0122971057163604f1336364 Cc: Walter Pienciak , perpass Subject: Re: [perpass] Security delivery model X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:28:46 -0000 --089e0122971057163604f1336364 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 30, 2014 at 12:04 PM, Orit Levin (LCA) wrote: > Good points. > In the meanwhile, we invite you to join the effort at UTA > http://datatracker.ietf.org/wg/uta/charter/ . > Orit. > Using TLS in Applications is useful work but not quite what I was suggesting. I think the security profiles need to be more than 'best practices'. They need to be a set of specific practices that meet specific security requirements. There are some areas where a security profile activity might lead to standards work. For example I am pretty sure that some of our application protocols cannot be deployed securely and standards compliant. There is also a question of audience participation. The audience for these specs would be security practitioners, not protocol designers. Most of the application security holes being created right now involve tools that I would simply never consider using because they are a security nightmare. It took quite a lot of us quite some time to understand the significance of HTTP injection attacks because we would never consider hooking up a scripting language in that way in the first place. So the community that needs to buy in here is the OWASP/BlackHat community rather the protocol design community. I don't really want to set up yet another standards organization and these may not be standards in the usual sense. It certainly seems useful to re-use IETF or W3C to publish the profiles. But there may be an advantage to some sort of political separation. I can point to quite a few IETF specs that have been broken as far as practical deployment goes and efforts to fix the problem have been thwarted through committee inertia. What looks good to a standards committee can be absolutely cretinous in actual deployment. To take a non IETF example, can anyone fill in the blank here? if (x != x) { } We can thank an IEEE committee for that particular facepalm. Some idiots worrying about mathematical models and laws developed a standard that creates ugly holes in the laws of every programming language built on that spec. The laws of occam originally included IF (x = x) |= and IF (x != x) |= SKIP. But those aren't true and someone with their pants in a bunch on a standards group is to blame. So if we have a group look at mail security profiles I would really like the political setup to allow that group to publish a report stating that X, Y and Z are defects in the SMTP, TLS or whatever protocols and for that to publish without someone on the IESG being able to veto it because they want to protect their baby. -- Website: http://hallambaker.com/ --089e0122971057163604f1336364 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 30, 2014 at 12:04 PM, Orit Levin (LCA) <oritl@microsoft.com&= gt; wrote:
Good points.
In the meanwhile, we invite you to join the effort at UTA http://datatracker= .ietf.org/wg/uta/charter/ .
Orit.

Using TLS in Applications is usef= ul work but not quite what I was suggesting.

I thi= nk the security profiles need to be more than 'best practices'. The= y need to be a set of specific practices that meet specific security requir= ements.


There are some areas where a security pr= ofile activity might lead to standards work. For example I am pretty sure t= hat some of our application protocols cannot be deployed securely and stand= ards compliant.

There is also a question of audience participation. The= audience for these specs would be security practitioners, not protocol des= igners. Most of the application security holes being created right now invo= lve tools that I would simply never consider using because they are a secur= ity nightmare. It took quite a lot of us quite some time to understand the = significance of HTTP injection attacks because we would never consider hook= ing up a scripting language in that way in the first place.

So the community that needs to buy in here is the= OWASP/BlackHat community rather the protocol design community.
<= br>

I don't really want to set up yet another = standards organization and these may not be standards in the usual sense. I= t certainly seems useful to re-use IETF or W3C to publish the profiles.

But there may be an advantage to some sort of political= separation. I can point to quite a few IETF specs that have been broken as= far as practical deployment goes and efforts to fix the problem have been = thwarted through committee inertia. What looks good to a standards committe= e can be absolutely cretinous in actual deployment.

To take a non IETF example, can anyone fill in the blan= k here?

if (x !=3D x) =A0{ <what code goes here= ?> }

We can thank an IEEE committee for that pa= rticular facepalm. Some idiots worrying about mathematical models and laws = developed a standard that creates ugly holes in the laws of every programmi= ng language built on that spec.

The laws of occam originally included IF (x =3D x) <= proc> |=3D <proc> and IF (x !=3D x) <proc> |=3D SKIP. But th= ose aren't true and someone with their pants in a bunch on a standards = group is to blame.


So if we have a group look at mail secur= ity profiles I would really like the political setup to allow that group to= publish a report stating that X, Y and Z are defects in the SMTP, TLS or w= hatever protocols and for that to publish without someone on the IESG being= able to veto it because they want to protect their baby.


--
Website: http://hallambaker.com/
--089e0122971057163604f1336364-- From oritl@microsoft.com Thu Jan 30 11:32:19 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222A21A04D4 for ; Thu, 30 Jan 2014 11:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL2KvIwSnLD3 for ; Thu, 30 Jan 2014 11:32:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id C74501A04D6 for ; Thu, 30 Jan 2014 11:32:12 -0800 (PST) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB292.namprd03.prod.outlook.com (10.141.68.28) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 30 Jan 2014 19:32:08 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0859.020; Thu, 30 Jan 2014 19:32:08 +0000 From: "Orit Levin (LCA)" To: Phillip Hallam-Baker Thread-Topic: [perpass] Security delivery model Thread-Index: AQHPHRUjydIFxbKM80eGeYEwKU58YpqdfDuAgAABqlCAAAldgIAAGWHw Date: Thu, 30 Jan 2014 19:32:06 +0000 Message-ID: <8a7e4034b0d04b138baa156dff055f90@BL2PR03MB290.namprd03.prod.outlook.com> References: <7e8748c166874d30aade0dcb77c6dbe9@BL2PR03MB290.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.247.123.117] x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(81542001)(63696002)(54316002)(66066001)(79102001)(94316002)(56776001)(80022001)(74316001)(93136001)(86362001)(80976001)(90146001)(74366001)(59766001)(77982001)(74876001)(85852003)(2656002)(81342001)(83072002)(51856001)(93516002)(65816001)(49866001)(85306002)(1411001)(74502001)(74662001)(47446002)(87266001)(46102001)(54356001)(76482001)(31966008)(53806001)(81816001)(81686001)(76786001)(76576001)(83322001)(50986001)(47976001)(92566001)(74706001)(87936001)(69226001)(76796001)(94946001)(33646001)(4396001)(47736001)(56816005)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB292; H:BL2PR03MB290.namprd03.prod.outlook.com; CLIP:98.247.123.117; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Walter Pienciak , perpass Subject: Re: [perpass] Security delivery model X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:32:19 -0000 >Using TLS in Applications is useful work but not quite what I was suggesti= ng. These are complementary approaches, indeed. >...I am pretty sure that some of our application protocols cannot be deplo= yed securely and standards compliant. Please, submit these cases to UTA if related to usage of TLS. This will be = very helpful and open to the broad community review. >There is also a question of audience participation. The audience for these= specs would be security practitioners, not protocol designers.=20 One of the important UTA's (and of IETF at large) goals is broadening the "= security practitioners" circle to include "application protocols" designers= and developers. I believe that this cross-pollination of ideas and needs w= ill make a practical difference. Orit. From doug.mtview@gmail.com Thu Jan 30 11:37:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0CC1A0451 for ; Thu, 30 Jan 2014 11:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAosnyOLSGiu for ; Thu, 30 Jan 2014 11:37:15 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3695A1A0450 for ; Thu, 30 Jan 2014 11:37:15 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so3410081pdj.29 for ; Thu, 30 Jan 2014 11:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zkbdnxaRUG8KhOd9B5iQcYZOFuKHUwZlVf+U9QTxYCU=; b=gHPrPGLD6bV5orPEd6PA0LJTFbijY0ExgrXrHLKUa7anxq0N0ZsCJ/HYsCRpB4Sds+ 2RcMLYwqLxyjSws/0JXLRVm7zfw5kvnXq2gn9pkDoxh7N7ZHrmJmQTSNsCx5JNn5+kDA +voXsceai3vRqjPguwNqvHi0Ev8yU41VbCJNaUD76bBIE9Kn0JV2CfGeHh47N00+ACKZ 5Nf1YZIwGBGjyz9fppJ5BA0C2ujQIPSC3z3bE7UmSYQV3SFuJOPICMpPulUigKUKp6TK +rGjrKzhf5XMHU4I3qrDYXYSyj5wTrt9V6IC2VXg2o/AaDtO6ao9FscSA0SWKwnGwZkc JdmA== X-Received: by 10.66.26.10 with SMTP id h10mr16172240pag.24.1391110632003; Thu, 30 Jan 2014 11:37:12 -0800 (PST) Received: from [192.168.2.232] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id e6sm20116724pbg.4.2014.01.30.11.37.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 11:37:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <52E842EE.2030508@gmail.com> Date: Thu, 30 Jan 2014 11:37:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FEC00FC-D83C-4FB2-8FE3-C8536CEAC814@sobco.com> <52E842EE.2030508@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) Cc: perpass , "Scott O. Bradner" Subject: Re: [perpass] blast from the past X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:37:17 -0000 On Jan 28, 2014, at 3:53 PM, Brian E Carpenter = wrote: > On 29/01/2014 12:39, Scott O. Bradner wrote: >> I just remembered that we talked about setting a direction towards = protection quite a while ago in RFC 1752 >> (the IPv6 recommendation) >>=20 >> We feel that an improvement in the basic level of security in the >> Internet is vital to its continued success. Users must be able to >> assume that their exchanges are safe from tampering, diversion and >> exposure. Organizations that wish to use the Internet to conduct >> business must be able to have a high level of confidence in the >> identity of their correspondents and in the security of their >> communications. The goal is to provide strong protection as a = matter >> of course throughout the Internet. >>=20 >> Scott >=20 > I also noticed that we said this in RFC 1958: >=20 > 6.2 It is highly desirable that Internet carriers protect the = privacy > and authenticity of all traffic, but this is not a requirement of = the > architecture. Confidentiality and authentication are the > responsibility of end users and must be implemented in the protocols > used by the end users. Endpoints should not depend on the > confidentiality or integrity of the carriers. Carriers may choose to > provide some level of protection, but this is secondary to the > primary responsibility of the end users to protect themselves. >=20 > Brian Dear Brian, Agreed. In addition, lack of SMTP client authentication is a primary = reason IPv6 email remains difficult service to defend. Endpoint authentication is possible. StartTLS or TLS can exchange = client and server certificates as a means to authenticate these = endpoints while also protecting transactions from third-party = monitoring. If only... DKIM authenticates signed portions of a message in a manner independent = of the sender without ensuring proper delivery or trivial checks = protecting against message spoofing. Nearly all email is exchanged as = clear text where just the sender IP address offers a practical means to = identify and block abuse. IPv6 email defense remains problematic, where = attempts often employ various DNS derived authorization extensions which = might even offer greater exposures. Reliance on IP addresses with = insecure DNS exposes email to difficult to detect forms of router and = DNS spoofing which may permit undetected MiTM attacks. Regards, Douglas Otis= From bortzmeyer@nic.fr Fri Jan 31 02:39:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E561A0581 for ; Fri, 31 Jan 2014 02:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTnzIwpqXp4N for ; Fri, 31 Jan 2014 02:39:15 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7331A0580 for ; Fri, 31 Jan 2014 02:39:15 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3F8442802F3; Fri, 31 Jan 2014 11:39:11 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 3ADBA28014A; Fri, 31 Jan 2014 11:39:11 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 2F4C8B3800C; Fri, 31 Jan 2014 11:38:41 +0100 (CET) Date: Fri, 31 Jan 2014 11:38:41 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20140131103840.GA32380@nic.fr> References: <52E90863.5070805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E90863.5070805@cs.tcd.ie> X-Operating-System: Debian GNU/Linux 7.3 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:39:17 -0000 On Wed, Jan 29, 2014 at 01:55:47PM +0000, Stephen Farrell wrote a message of 33 lines which said: > privacy reviews of existing RFCs. Just to check that I understand you correctly: do you think that Internet-Drafts like draft-bortzmeyer-dnsop-dns-privacy are such "privacy reviews of existing RFC"? If yes, are there other examples to follow? If not, what is missing in it? I miss a privacy review of IP, which would help to answer questions like "is the IP address a personal identifier" or "is IPv6 better or worse than IPv4 for privacy, taking into account CGN and things like that" From bortzmeyer@nic.fr Fri Jan 31 02:50:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF21F1A0585 for ; Fri, 31 Jan 2014 02:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtWF0hVc7aBx for ; Fri, 31 Jan 2014 02:50:57 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id D4BEF1A057D for ; Fri, 31 Jan 2014 02:50:56 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 10E0328050F; Fri, 31 Jan 2014 11:50:53 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id EF6CD280527; Fri, 31 Jan 2014 11:50:52 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 0FE22B3803B; Fri, 31 Jan 2014 11:50:27 +0100 (CET) Date: Fri, 31 Jan 2014 11:50:26 +0100 From: Stephane Bortzmeyer To: Dave Crocker Message-ID: <20140131105026.GB32380@nic.fr> References: <52E90863.5070805@cs.tcd.ie> <52E9235C.2030601@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E9235C.2030601@bbiw.net> X-Operating-System: Debian GNU/Linux 7.3 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass , Stephen Farrell Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:50:58 -0000 On Wed, Jan 29, 2014 at 07:50:52AM -0800, Dave Crocker wrote a message of 35 lines which said: > We don't have a track record of those specific types of reviews and > I believe we are some distance away from having a shared, usable > model of what to review for. We don't start from zero, we have already RFC 6973 and its section 8 is a very good example of privacy/PM analysis of an existing protocol. From joe@cdt.org Fri Jan 31 06:52:12 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010A1A02C5 for ; Fri, 31 Jan 2014 06:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heLxodBUyZGx for ; Fri, 31 Jan 2014 06:52:10 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1159E1A0276 for ; Fri, 31 Jan 2014 06:52:09 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from hypochilid.local ([199.119.118.18]) (authenticated user jhall@cdt.org) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for perpass@ietf.org; Fri, 31 Jan 2014 09:52:05 -0500 Message-ID: <52EBB894.60605@cdt.org> Date: Fri, 31 Jan 2014 09:52:04 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52E90863.5070805@cs.tcd.ie> In-Reply-To: <52E90863.5070805@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] privacy/PM reviews of existing stuff X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:52:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Stephen and perpassians, Please count myself and our new technologist, Runa Sandvik (formerly of Tor), as willing and ready here. We are very new to the IETF and although I've read the Tao and have great mentors among you, I don't think we'd be the best leading the effort, but able troops. Unfortunately, we can only attend STRINT (if invited) and the first two days of IETF 89 as we have to be back in DC for CDT's 20th anniversary (https://cdt.org/techprom). best, Joe On 1/29/14, 8:55 AM, Stephen Farrell wrote: > > Hiya, > > One idea that came up in Vancouver and that we (meaning at least > me:-) haven't had a chance to progress was the idea of trying to > get a team of folks together to go do privacy reviews of existing > RFCs. Or perhaps slightly differently, reviews that explicitly > consider pervasive monitoring, which might be more constrained and > a bit easier. > > I think Christian H. commented at the mic that there is probably a > *lot* of low hanging fruit out there, and I suspect he's quite > right:-) > > Now that we're in the run up to the London IETF, if some of you had > time to try self-organise that kind of thing that'd be great. Any > takers for trying to organise that? > > Using this list to start with should be fine, if it results in > loads of traffic we can spin up a new one, or move over to > ietf-privacy@ietf.org. > > If there are folks willing to take this on and having a > side-meeting in London helps, I can get you a room for that. > > Thanks, S. > > > _______________________________________________ perpass mailing > list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS67iUAAoJEF+GaYdAqahx+ZAP/0F05eBYpu8HFQn39XWHFgUp Ox+gjN9TZZ22UC/bbGY6hYTIrjp/W0TBUxh4QA5z698SdPrTdWnpptI0FnCjBRQM jQLP8HiW8LHYEw//qCH3Pz3s+Q7AvlTHFpBdvNVubFZgC3QqEZY533+qc2M8q7Ye 5MuAIfulSnL4i2feKfipZT+8BW/vAHF1s94qruXczXc1LaFUlBkku2z0LnhBBv/a qDYN0Lahe97jB3fgXTSzPPgsVUWkD5BVWl7Q4eBDTp51BgZDl37akSdwD9Ae2KIj jmbEwyFVv6bz9/26MDR4lD05CU0op94S0z626HBrsQlV58na9NJDk5p/Xgqnqk8Z P0mwLskjO7vkkHQ7zsCQyg9cEaNXZ4DodmjmYNH4jUNH3lqmn7iCP2XJUgHhiin7 5Sun9dH2AWIiYlMH5iAROIhYZ1GW4PHOw1AmaGRMfhEov4vASOOKhvuiyJS4bM8P rBL6Da68hYfsqu0c5U8R5rhVKGOVk5k4QsZe45fCikIwCPcrFw/Ue9IpzVQ2CHu4 yA6w91acQ1ggqtMIEcANfcooKCoe75U6bFLDRoht8yK2ppKe6SjManM6RnvGhvSp EIb5L2D//9Qz4vM7ddC+3Y92SlcSE9pstC5P18XkRR2+9FtdSZ7a9Coe/nIDGlW8 k4q0gYc9uR7PTqOwK67z =pwQb -----END PGP SIGNATURE-----