From hallam@gmail.com Fri Nov 1 17:03:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C574B11E8156 for ; Fri, 1 Nov 2013 17:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBVgqzGj+mow for ; Fri, 1 Nov 2013 17:03:21 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4AE11E80E9 for ; Fri, 1 Nov 2013 17:03:19 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so2127740lab.8 for ; Fri, 01 Nov 2013 17:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=x73ppP73HRdO48AXlQAeEEC+N27/JFiujIq1JDDNPPU=; b=VqkCynJQ374Gb38v8n2r/KFB2mrRepPDuq559Ao1ef8GHrJcAXHqKYIJz9EfK3ML4t QdUU35QymIREg3uiaPvnMG6GcJWmljXlgvUTBJEILfhnwX3nZnc6pJc24Fn84hul3RiD Fv4Bk6wRGUz6kZlisCpKHpBwFXVVaPvfMQMevtkPhZQRtyFEPwnxK1b/x65aRSzstwL1 reTbipN66wBC07mdGE5R65FAHVf6tQJX5WW4nKFvGUYgo3eyUw6u+saM0tqwQp+CYsaq Zx5kJOpyYMWuIBB4dID2TGxbM/ccxL1lVCp4hiBiEJmv6w+7l1dwNP7ZPMo/DAf7uef9 Xneg== MIME-Version: 1.0 X-Received: by 10.112.128.166 with SMTP id np6mr3206356lbb.7.1383350599085; Fri, 01 Nov 2013 17:03:19 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 1 Nov 2013 17:03:19 -0700 (PDT) Date: Fri, 1 Nov 2013 20:03:19 -0400 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=047d7b343ef20ef61004ea26697a Subject: [perpass] The last hard problem in PKI X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 00:03:22 -0000 --047d7b343ef20ef61004ea26697a Content-Type: text/plain; charset=ISO-8859-1 The issues that consume most time in standards process are the ones that everyone can have an opinion on. If we are building a time machine then everyone can argue about what color to paint it but none of us has a sensible opinion on the time travel mechanism other than that we don't know how to make it. So most of the problems of securing email end to end come down to plumbing. Over the past couple of months I have been trying to perform triage on the problem, isolating the parts that are 'research' from the parts that are 'plumbing'. The first iteration was basically to copy the design of XKMS and isolate all the PKI components in a Web Service. But we can further divide the problem inside the PKI space as follows: Case A: We know the public key of the other party Case B: We know the message digest of the public key of the other party Case C: We have no information about the public key of the other party The difficulty of these three cases is very different yet in the current approaches we are forced to solve the difficult problem of case C even for cases A and B! Case A does not need any infrastructure at all but SSH seems to get along just fine. Case B only requires the ability to resolve the digest to a public key which is essentially just an index lookup. If we had an end to end email security system that was only secure after first use or if the counterparty provided their strong email address with the digest of their key it would cover a huge number of use cases. And we can build that without any 'infrastructure' dependence at all beyond a web server or two. There is still a research problem to solve case C, but we don't need to insist on that problem being solved or even knowing that we can solve it to start work on cases A and B. Now I believe that I have also solved case C but that is another issue and one that has a longer argument to justify it. The point is we can do useful work to make end to end email security usable now even if my proposal for the hard problem turns out not to work. -- Website: http://hallambaker.com/ --047d7b343ef20ef61004ea26697a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The issues that consume most time in standards process are= the ones that everyone can have an opinion on. If we are building a time m= achine then everyone can argue about what color to paint it but none of us = has a sensible opinion on the time travel mechanism other than that we don&= #39;t know how to make it.

So most of the problems of securing email end to end come do= wn to plumbing. Over the past couple of months I have been trying to perfor= m triage on the problem, isolating the parts that are 'research' fr= om the parts that are 'plumbing'.

The first iteration was basically to copy the design of= XKMS and isolate all the PKI components in a Web Service.=A0
But we can further divide the problem inside the PKI space as f= ollows:


Case A: We know the public key of the ot= her party

Case B: We know the message digest of th= e public key of the other party

Case C: We have no= information about the public key of the other party


The difficulty of these three cases is v= ery different yet in the current approaches we are forced to solve the diff= icult problem of case C even for cases A and B!

Case A does not need any infrastructure at all but SSH seems to get along j= ust fine. Case B only requires the ability to resolve the digest to a publi= c key which is essentially just an index lookup.

If we had an end to end email security system that was only secure after fi= rst use or if the counterparty provided their strong email address with the= digest of their key it would cover a huge number of use cases. And we can = build that without any 'infrastructure' dependence at all beyond a = web server or two.


There is still a research problem to sol= ve case C, but we don't need to insist on that problem being solved or = even knowing that we can solve it to start work on cases A and B.

Now I believe that I have also solved case C but that i= s another issue and one that has a longer argument to justify it. The point= is we can do useful work to make end to end email security usable now even= if my proposal for the hard problem turns out not to work.



--
Website: http://hallambaker.com/
--047d7b343ef20ef61004ea26697a-- From trammell@tik.ee.ethz.ch Sat Nov 2 15:10:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7423521E811A for ; Sat, 2 Nov 2013 15:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd9FgSvFCTxO for ; Sat, 2 Nov 2013 15:10:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D757021E8118 for ; Sat, 2 Nov 2013 15:10:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EEAD4D9302 for ; Sat, 2 Nov 2013 23:10:08 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Fu6sJepCb7Fk for ; Sat, 2 Nov 2013 23:10:08 +0100 (MET) Received: from dhcp-9c26.meeting.ietf.org (dhcp-9c26.meeting.ietf.org [31.133.156.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 16AF1D9300 for ; Sat, 2 Nov 2013 23:10:07 +0100 (MET) Message-ID: <52757834.4070804@tik.ee.ethz.ch> Date: Sat, 02 Nov 2013 15:09:56 -0700 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig666F3C3549CF57C3EE007E49" Subject: [perpass] On Surveillance and Management X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 22:10:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig666F3C3549CF57C3EE007E49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Greetings, all, There has been much discussion on this list about increasing the resistance of messaging to pervasive surveillance. This is not my area of expertise, but it seems to me there are probably a few holes to plug here on the specification side, and a long, long way to go on the deployment side. Looking further, it would be nice if we could extend these efforts to post-SMTP/IMAP messaging, but most of the deployed technology here seems to involve rows stored in plaintext in proprietary databases, which is even less resistant to pervasive surveillance than anything we're talking about. That's the subject of another rant, though.= More generally, increasing the deployment of opportunistic encryption would bring content protection and security-usability benefits to messaging as well as to other traffic. Both of these continue trends already underway -- we as a community have long recognized that protecting the content of communications from eavesdropping by third parties is, on balance, a generally desirable goal, regardless of the motive of the eavesdropper. Beyond that, it is a clear-cut engineering problem, and we're pretty good at solving those. The network is apathetic to motive. What one sees as evil, another may treasure as an essential service of the state, but a third party is a third party no matter how you look at it. We have had less productive conversation to date on the intersection between surveillance and management. The tools of pervasive surveillance are the same tools we use for passive network observation for measurement, management, and troubleshooting. These tools are also apathetic to motive. At the low end of the spectrum I can use tcpdump to debug your wireless router or to read your email (if you're unfortunate enough not to have encrypted it, that is). The network measurement and management community has invested significant effort as long as there has been an Internet in making it as easy as possible to observe as much of the network as possible, so this spectrum goes well beyond tcpdump. Objections that more content encryption will hurt the practice of network management and network security are to some extent true, but pointless. Simply put, if your strategy for managing or defending your network involves observing content on the wire in plaintext, you were already going to need a new strategy. Deep packet inspection (DPI) is dead. HTTPS Everywhere killed it, and a cute little napkin sketch showing every data center operator in the world where "SSL gets removed" buried it. Metadata is a different story. Indeed, we've just published as STD 77 IPFIX, a very nice protocol (in my humble opinion) for efficiently moving network traffic metadata around. This is a vital tool in network measurement, management, and accounting. Behavioral security monitoring based thereon is part of how we're going to deal with the fact that DPI is dead. IPFIX and similar technologies are of course just as easily applicable to pervasive surveillance as they are to any of these endeavor= s. Protecting communications from metadata analysis is much harder than protecting content, since the power of inference and association increases with the amount of metadata collected, while the space of possible solutions is rather restricted, and involves costs in bandwidth and latency. Onion routing is probably the most practical of these, and has the advantage that it is already deployed and doesn't require architectural changes. It's also not particularly resistant to pervasive surveillance undertaken by a dedicated adversary willing to operate middling-large portions of the overlay network, if the adversary isn't awfully picky about who it identifies. I'd intended to go into more detail on the possibilities of metadata analysis and the cost of resistance in a draft-trammell-perpass-ppa-01, but haven't found the time to do so, and in thinking about it realized we've already published guidelines for network data anonymization -- in these terms, the practice of attempting to preserve the utility of metadata for some analysis while simultaneously reducing or eliminating its utility for identifying individuals -- as RFC 6235. Viewed from the right angle it's the same problem, and though the document is somewhat IPFIX-specific, it might be of interest to those considering the problem of metadata analysis resistance. In general, I don't think there's much win here for network and transport layer metadata simply because there's no practical universal technique for analysis resistance (beyond the trivial solution: simply not using the network.) There's higher-level "metadata", of course -- application-specific identifiers that can be bound to individuals or associations of individuals. But the problem here isn't so much large-scale metadata analysis as it is simple information leakage. This seems to be one of the directions that draft-cooper-ietf-privacy-requirements, and it's worth the effort to survey these and take a long hard look at what we really need to expose for manageability, and consider the tradeoffs involved in reengineering each protocol to leak less. Cheers, Brian --------------enig666F3C3549CF57C3EE007E49 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJSdXg8AAoJENt3nsOmbNJcNmUIAKHc3tiVT5ILzpAwAZT1UlcO XcKfu8xQT5AuKbgMKVUKkS+1awTzJd70GsobGlX1KKAE3+EZyWrHggD2PYkR05Ss El/tcua4h80Zge5cVcoWKObUhN5C5n/bL/yLthV7DGnzbfV8Or2LRzBb4Ljt1A/3 gSjIWJgnY8ZnGE+LXd1YVDV7iWGc5ACG/MzkI7PFbmnRmR5nmNmiycLpTV/OEpJd HgWRFVoC/DPu6mTnLSw3L+MdedbL9/MzZcQ/6wY1Oa+QEcKCelB4hHiVCYDtku2S y+xoyboVNlkROAVUS34y2iVD9NIKyFDy4QGJysewhhIKvuOm0fljp0wIpY97zl4= =OxQN -----END PGP SIGNATURE----- --------------enig666F3C3549CF57C3EE007E49-- From ssarbot@yahoo.com Fri Nov 1 06:04:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4501221E81AB for ; Fri, 1 Nov 2013 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrToR7USMt-l for ; Fri, 1 Nov 2013 06:04:08 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3721E83D6 for ; Fri, 1 Nov 2013 06:00:27 -0700 (PDT) Received: from [98.139.212.149] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2013 13:00:26 -0000 Received: from [98.139.212.248] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2013 13:00:26 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 01 Nov 2013 13:00:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 671771.94944.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 75772 invoked by uid 60001); 1 Nov 2013 13:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1383310826; bh=eyqjKz7QNS3rPaWGLFkPqP76aE5JA4OICd+sDQN2Ah4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=0xRrWL+XlVbfsIZc1FtYtB+62MLPVAVcxX3CQN8yb3Emqs/85bvdzAdbdys4a3ldippjWr4DdGXAF7kFr+EuXCZz3ti0EM2Z/9pHIFcnKq1cnW0R3cZ3ApaJGXBHG6P3qbWgiijxYIWuVrDUdr0+A3db3ARzaembgm11Ebk8Jeg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=x6HSHB+K2jMElvnP8KR6hRYu7DEBz7Wi0VoC/qOwJMuHz4WdRI84HNgLbPex5AwdKEL2wIj3jTFeFZ1tmAnbS1wUF/925dM+GSEweEVlW3phvnHjOgvlGKlIyrtRjUFzh6p9Da6Fq7Xya3FFauK8lFzdUwp4kInWYjMFRjB4J5I=; X-YMail-OSG: gYQYsC0VM1ltpRMEQbEIvcQkddc2hsUq.sI.k4Jw8kb3wve 3mcE9QGYh_4oLc88Rh37wUgYAw0ZYznxN_AFxiyIKBweig_2uzz5ZBOlfRsg vGi4DUKUa1Z1UHUbqPGRfuouFVceJL7xfZK85CTEepoLyh00_EruJhoM152. 5cFFhuqjbiuxo99lKQx28IWGlGS5iVBWkTzf19ftBbN7luQu22XNmjUuP4.A AVRu5COvYZIZNTpizYEBmPLjTztSmzT.gxYaE.bobcgauQdHXOxosdn6sI6z he9S9AO3Aykgvm4UeJ.owaVqheh4nRt6mglPWV2jpkWzOPthEm_TVBpzKEcp F1yydLUdaq1.BNO5mSauYLkdL2qeOJvYOn05S3e5u9DcA.9mdV0UJMEfiDJ. lLLnUSv3MuM7xqSzpIyj2Ll33memWyggUvEqhfF2AVJZlBVgjIVS7ME.377F 8qb95_T0bbCDo2rOANsnJhHrOBNGFeDAxyzxMb7Vixx60JId68itmXDoWToF RnhVW8PiD58LkVOdgoZDmiG3pZMUWz9q2AUGjbMcXxqXPpawYMpoRzYmuRh. m6AuFy68fJVE- Received: from [24.155.231.167] by web141006.mail.bf1.yahoo.com via HTTP; Fri, 01 Nov 2013 06:00:26 PDT X-Rocket-MIMEInfo: 002.001, LiAuIC7CoCBFdmVuIGJlZm9yZSBKdW5lLCBHb29nbGUgZXhlY3V0aXZlcyB3b3JyaWVkIGFib3V0IGluZmlsdHJhdGlvbiBvZiB0aGVpciBuZXR3b3Jrcy4gVGhlIFdhc2hpbmd0b24gUG9zdCByZXBvcnRlZCBvbiBXZWRuZXNkYXkgdGhhdCB0aGUgTi5TLkEuIHdhcyB0YXBwaW5nIGludG8gdGhlIGxpbmtzIGJldHdlZW4gZGF0YSBjZW50ZXJzLCB0aGUgYmVhdGluZyBoZWFydCBvZiB0ZWNoIGNvbXBhbmllcyBob3VzaW5nIHVzZXIgaW5mb3JtYXRpb24sIGNvbmZpcm1pbmcgdGhhdCB0aGVpciBzdXNwaWNpb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.161.596 Message-ID: <1383310826.75697.YahooMailNeo@web141006.mail.bf1.yahoo.com> Date: Fri, 1 Nov 2013 06:00:26 -0700 (PDT) From: Steve Sarbot To: "perpass@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1694620066-2121621149-1383310826=:75697" X-Mailman-Approved-At: Sun, 03 Nov 2013 09:01:26 -0800 Subject: [perpass] Only peer to peer, or end user to end user encryption will be most effective . . . X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Sarbot List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 02:11:41 -0000 --1694620066-2121621149-1383310826=:75697 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable . . .=C2=A0 Even before June, Google executives worried about infiltration = of their networks. The Washington Post reported on Wednesday that the N.S.A= . was tapping into the links between data centers, the beating heart of tec= h companies housing user information, confirming that their suspicions were= not just paranoia.=0A=0A. . . Yet one major caveat remains. While the IETF= might be able to secure the pipes through which users=E2=80=99 data travel= , users must also be able to trust the parties where their data is stored: = software, hardware and services.=0A=0AAlso, because the Gov't can force ISP= 's and internet companies to hand over their keys, and without notifying th= e end users, all this requires that the IETF implement peer to peer, or end= user to end user applications with strong encryption and those be engineer= ed into the fabric of the internet.=0A=0AIt is widely known that https has = been deciphered by the NSA.=0A --1694620066-2121621149-1383310826=:75697 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
. . .  Even before June, Google executives worried = about infiltration of their networks. The Washington Post reported on Wedne= sday that the N.S.A. was tapping into the links between data centers, the b= eating heart of tech companies housing user information, confirming that th= eir suspicions were not just paranoia.

. . . Yet one major caveat re= mains. While the IETF might be able to secure the pipes through which users= =E2=80=99 data travel, users must also be able to trust the parties where t= heir data is stored: software, hardware and services.

Also, because = the Gov't can force ISP's and internet companies to hand over their keys, a= nd without notifying the end users, all this requires that the IETF impleme= nt peer to peer, or end user to end user applications with strong encryptio= n and those be engineered into the fabric of the internet.

It is wide= ly known that https has been deciphered by the NSA.
--1694620066-2121621149-1383310826=:75697-- From dean.willis@softarmor.com Sun Nov 3 11:35:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6A11E8190 for ; Sun, 3 Nov 2013 11:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRq5gXpzYSSe for ; Sun, 3 Nov 2013 11:35:57 -0800 (PST) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF921F9477 for ; Sun, 3 Nov 2013 11:35:50 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id g10so910383vbg.30 for ; Sun, 03 Nov 2013 11:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y+ANYOUxldfN4t4uO9uer7pAxy5rx0KXc3hLfPZ+dgE=; b=cAq9i/LZiQXwmZyJYehyU7CzfTVSR5H+Zk3LTpPkxA2e0Ckrg0zpER6Gpku0XFehyO Ps2HpxCryhfPAgLed/YLnTyzf24T+EIeuRILhTu+wyzYSLQK3Prk3qgAhy/yuPMypv62 jtzZi7HxnYxE+OISDP7k40vv4t1y8n6Vu3URQ= 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=y+ANYOUxldfN4t4uO9uer7pAxy5rx0KXc3hLfPZ+dgE=; b=kBW71Y1X7oHxAiTJ9z/gBaM8epMLWDKsxG1/3xp/9E+teWv9Ys+cG8hmyhin/gb/jI 1dT3o2lq/r4JwW5fco3LcbUvU2ZxVUo6mjDH/48gGkdLzOY5iuwPjbuE3MBf9hkh4Ilp O2Hskn5PzbvYcz+roNe14shnpYjkSoKzIkyBLDVP1EgvzvfNylKWDzXIkJGTDOVZ8PjI m5X1eGVXA+M8frcLoLum84vSUriUQsD2vdbIoQpMFz/ljvHAq4uOCuM3kLOkIlDTSPeF vSzEcXS4jMMaaJnOlczRsMxwhqWeq8fLq6vJG82OGxWnWymI8v5DQbLqaw6bgjEglH5L f7CA== X-Gm-Message-State: ALoCoQns+BZZdcG9s4xTy1ZYQZtF0FNt60VeohNd/ATs+5INPmwIvhBbgw1pytHsJvFVsItjDBFY MIME-Version: 1.0 X-Received: by 10.52.248.197 with SMTP id yo5mr7570128vdc.0.1383507349300; Sun, 03 Nov 2013 11:35:49 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 11:35:49 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 11:35:49 -0800 (PST) In-Reply-To: <525473AC.3070007@cs.tcd.ie> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> <525473AC.3070007@cs.tcd.ie> Date: Sun, 3 Nov 2013 13:35:49 -0600 Message-ID: From: Dean Willis To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0117625d1983ee04ea4ae8ad Cc: perpass@ietf.org, Stephen Kent Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:35:59 -0000 --089e0117625d1983ee04ea4ae8ad Content-Type: text/plain; charset=ISO-8859-1 Pardon the delay. Things got busy. I intended no attack; I mean that since we (participants in the IETF and other standards bodies) are now "suspects" in the debasing of standards, that we need to be fully prepared to answer these sorts of questions. Remember that when suspicion reigns, it's not the questions (or answers) that get you. It's the mere fact of having been questioned that drags you down. We cannot afford even the least suspicion of having been co-opted by a nation-state or comparable security apparat. But it's not feasible for all of us to have perfect alibis, and potential motives abound. Better yet, if we have mechanisms in place that are obviously resistant to such manipulations. Then we have no reason to fear the Inquisition. Or to fear that they may be among us. -- Dean On Oct 8, 2013 4:05 PM, "Stephen Farrell" wrote: > On 09/13/2013 06:12 PM, Dean Willis wrote: > > Yeah, that's an ad hominem attack . > > Oops. Sorry Steve, my fault for not noticing that in Dean's > mail from a few weeks ago. Dean, please desist from ad-hominen > attacks. > > And I figure this particular thread has run its course in > terms of being productive. (A new thread on the issue of > MTI vs mandatory-to-use-or-similar would be interesting > though.) > > Thanks, > S. > > > > > --089e0117625d1983ee04ea4ae8ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Pardon the delay. Things got busy.

I intended no attack; I mean that since we (participants in = the IETF and other standards bodies) are now "suspects" in the de= basing of standards, that we need to be fully prepared to answer these sort= s of questions. Remember that when suspicion reigns, it's not the quest= ions (or answers) that get you. It's the mere fact of having been quest= ioned that drags you down.

We cannot afford even the least suspicion of having been co-= opted by a nation-state or comparable security apparat.

But it's not feasible for all of us to have perfect alib= is, and potential motives abound.

Better yet, if we have mechanisms in place that are obviousl= y resistant to such manipulations. Then we have no reason to fear the Inqui= sition. Or to fear that they may be among us.

--
Dean

On Oct 8, 2013 4:05 PM, "Stephen Farrell&qu= ot; <stephen.farrell@cs.tcd= .ie> wrote:
On 09/13/2013 06:12 PM, Dean Willis wrote:
> Yeah, that's an ad hominem attack .

Oops. Sorry Steve, my fault for not noticing that in Dean's
mail from a few weeks ago. Dean, please desist from ad-hominen
attacks.

And I figure this particular thread has run its course in
terms of being productive. (A new thread on the issue of
MTI vs mandatory-to-use-or-similar would be interesting
though.)

Thanks,
S.




--089e0117625d1983ee04ea4ae8ad-- From dean.willis@softarmor.com Sun Nov 3 11:42:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361FF21E80E8 for ; Sun, 3 Nov 2013 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuMSInb3Kirb for ; Sun, 3 Nov 2013 11:42:20 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AC77921E8102 for ; Sun, 3 Nov 2013 11:42:19 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so910407veb.4 for ; Sun, 03 Nov 2013 11:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xHjiCaDxYaP7XUwDbJceKNXVreMp4jVK4+MO2Q5pQyM=; b=JD3erAgQSFactZUcPuxBEjJ6xKUuTSo9OCm4ujHb4AxldFQNbIhPGsz7jp04a4RDqu HH9PVGIu0mSQ6vcsIqSzz9lVpjEkeCkcrCPPt01tY0fUCW3YvRirC251e8ohNsBaNy3w ptX3SPxI297YfU8IYW0CvCBpOEPLxefqmNJo8= 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=xHjiCaDxYaP7XUwDbJceKNXVreMp4jVK4+MO2Q5pQyM=; b=WOp7tDY+LkRuWsl6kMSVumI47dJOlGTkDCq/RzbXN1DMav5QJNuQ8wVAlqiBlWpWEY tg/qC3usGCj86kOwxDUEULEjtIqz7ryqGvP2oFh1uNkES9POZECET92DadXZtMKjBQ6e YkRYZ594vHgdUid2UREPK9xAm87XuaFmgnOZjZYGhbROrjTXR33W/Af0MsArk1nh+bM6 rA+OamI1zliF4Bds5zXCsO8idqze+dhH6LVrDo2Fk4uWjOyWOsUanO4j+hwyhjm2vRSp L6MLJvKfM15S1SfSdPujVakVEs9DKJs5p/6LQmcPsgllBv77smSQ41/wJSxxMvuYxRIk lcMg== X-Gm-Message-State: ALoCoQl4wCzEnNO1GXfPtMbv+D8QocLXvRE7rna5LsY+EDqmMmIcF4SO1PtTh6B7cHuXd5El/WZ2 MIME-Version: 1.0 X-Received: by 10.220.144.80 with SMTP id y16mr8974731vcu.4.1383507738839; Sun, 03 Nov 2013 11:42:18 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 11:42:18 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 11:42:18 -0800 (PST) In-Reply-To: <52544F48.7060006@bbn.com> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> <52544F48.7060006@bbn.com> Date: Sun, 3 Nov 2013 13:42:18 -0600 Message-ID: From: Dean Willis To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b34397451689704ea4aff23 Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:42:23 -0000 --047d7b34397451689704ea4aff23 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Oct 8, 2013 1:30 PM, "Stephen Kent" wrote: > > Dean, > > Here are responses to your comments: > > > > Too bad. We can try to minimize the impact, but a net that gets you killed because > the wrong person heard you say the wrong thing is worse than one with slightly less bandwidth or temporal QoS.=94 > > > > I'm not sure I understand the context of your assertion re use of deadly force. I assume you don't > mean to suggest that many/most Internet users are in physical jeopardy as a result of nation state surveillance, right? Is your argument that every user of the Internet should incur performance and convenience penalties to provide cover for the very, very tiny fraction of users who are in real, physical jeopardy as a result of such surveillance? I don=92t think that those of us who develop Internet standards are in a position to make such tradeoffs. I mean to suggest that enough Internet users are, or will become, in physical jeopardy as a result of their Internet use that we have a moral and ethical responsibility to design the protocols of the Internet so as to reasonably minimize that danger, even if it does have costs for all other users of the Internet. The extent to which we find the tradeoff reasonable is open to discussion, but I believe we're currently being excessively miserly with our support. --=20 Dean --047d7b34397451689704ea4aff23 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2013 1:30 PM, "Stephen Kent" <kent@bbn.com> wrote:
>
> Dean,
>
> Here are responses to your comments:
>
> =A0
>
> Too bad. We can try to minimize the impact, but a net that gets you ki= lled because
> the wrong person heard you say the wrong thing is worse than one with = slightly less bandwidth or temporal QoS.=94
>
> =A0
>
> I'm not sure I understand the context of your assertion re use of = deadly force. I assume you don't
> mean to suggest that many/most Internet users are in physical jeopardy= as a result of nation state surveillance, right? Is your argument that eve= ry user of the Internet should incur performance and convenience penalties = to provide cover for the very, very tiny fraction of users who are in real,= physical jeopardy as a result of such surveillance? I don=92t think that t= hose of us who develop Internet standards are in a position to make such tr= adeoffs.

I mean to suggest that enough Internet users are, or will be= come, in physical jeopardy as a result of their Internet use that we have a= moral and ethical responsibility to design the protocols of the Internet s= o as to reasonably minimize that danger, even if it does have costs for all= other users of the Internet.

The extent to which we find the tradeoff reasonable is open = to discussion, but I believe we're currently being excessively miserly = with our support.

--
Dean

--047d7b34397451689704ea4aff23-- From dean.willis@softarmor.com Sun Nov 3 12:54:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2A611E80FA for ; Sun, 3 Nov 2013 12:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.212 X-Spam-Level: X-Spam-Status: No, score=-100.212 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV2JDFkGGuRB for ; Sun, 3 Nov 2013 12:54:58 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5211E818E for ; Sun, 3 Nov 2013 12:54:57 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so961507veb.33 for ; Sun, 03 Nov 2013 12:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Feh6GbuojWEh3CUdR62PQX/NuOG2mGuACXsjgseXqwk=; b=XWQNeGs7LNyRv4eOv69cyhLh+R25POzKBwAb7FDJsRHkGGKsS7HEO9TnvLgUa1odH7 iXlyO7mPBXAqNfiBpcqck2VYoiyjJv6xvzG7chO+Dek2Bux5yVUpqawG06+VYAHBh7El vFgE9PvfYLfEw12UVcLewLYXes0judgE1oDy4= 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=Feh6GbuojWEh3CUdR62PQX/NuOG2mGuACXsjgseXqwk=; b=ltVPkx4CadjMYbeeeVaLhDeY9WJTAfAuWqni7xFwY/5fiWSUNyjamYh87KnfdTUkQv 0jKz/0CXSvPhnsX+SW5EmR1KBOF27XD4cwCCjLbqdbZtvv+P/v1O7n46UYNIXfKpN1Z5 NTHF9c/7U5zOttssFqRF+j568ONXm/mynepqP16VywlSN7l1l0HWi+L2LR8ToRhRZQqZ Bp1yHntLEz8qMthI6lRtDnt1LBAdXkOjPuoznhw+GwYzLWOMfpbCCAx5p/2mP3nf7XBe qGOtZAIjTsje1XClluxtTUjUqeLJw5ZeRPDGa7idlNsxa2kIG/i46MxfvxK2ubaIDc5H 5haw== X-Gm-Message-State: ALoCoQku9KWg7Stf4HdjCuNgkwUFfM7E0KeXJ65LO+skVp7JLK0VxE6zlR6Jusx8N5idF7+gdd23 MIME-Version: 1.0 X-Received: by 10.52.32.66 with SMTP id g2mr7922228vdi.14.1383512096805; Sun, 03 Nov 2013 12:54:56 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 12:54:56 -0800 (PST) Received: by 10.58.173.72 with HTTP; Sun, 3 Nov 2013 12:54:56 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Nov 2013 14:54:56 -0600 Message-ID: From: Dean Willis To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=bcaec51d255e12b31604ea4c03db Cc: perpass@ietf.org, Stephen Kent Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:54:59 -0000 --bcaec51d255e12b31604ea4c03db Content-Type: text/plain; charset=ISO-8859-1 On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" wrote: > > One of the issues that has been raised in the government world is how do we convince people looking in that the IETF spec have not been contaminated by some of the alleged $250 mil/yr being spent on such purposes. > > This is not a theoretical problem or even a new one, but it is one that has been ignored in the past and is now going to be very much harder to ignore. > I'm pretty sure I got "persuaded" into buggering some security in RFC3261 (sips: allowed to terminate at serving proxy rather than being e2e), at least to the extent of accepting and endorsing a flawed argument that I now believe would have made somebody's intercepts easier. Fortunately it turned out not to matter much (as the defacto deployment was "no security" rather than the piece I watered down), and it is now well-understood as an error. So it happens. Sometimes directly, sometimes indirectly as when your customer or client is influenced into influencing your standards work. I didn't even realize what it was when it happened to me, and I used to think I was pretty good at that game. Once burned, twice shy and all that. So I believe it can and does happen. Usually subtly, but I've also heard of much more overt instances. Fortunately hearsay is inadmissible. But we do have to be careful, and we really need to build up a system that anticipates and survives bad actors, even of the most deliberate sort. We live in a glass house, and people are now looking in. Rocks will be thrown. Wear your slippers and safety glasses. -- Dean --bcaec51d255e12b31604ea4c03db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>

> One of the issues that has been raised in the governmen= t world is how do we convince people looking in that the IETF spec have not= been contaminated by some of the alleged $250 mil/yr being spent on such p= urposes.
>
> This is not a theoretical problem or even a new one, but it is one tha= t has been ignored in the past and is now going to be very much harder to i= gnore.
>

I'm pretty sure I got "persuaded" into buggeri= ng some security in RFC3261 (sips: allowed to terminate at serving proxy ra= ther than being e2e), at least to the extent of accepting and endorsing a f= lawed argument that I now believe would have made somebody's intercepts= easier. Fortunately it turned out not to matter much (as the defacto deplo= yment was "no security" rather than the piece I watered down), an= d it is now well-understood as an error.

So it happens. Sometimes directly, sometimes indirectly as w= hen your customer or client is influenced into influencing your standards w= ork.

I didn't even realize what it was when it happened to me= , and I used to think I was pretty good at that game. Once burned, twice sh= y and all that.

So I believe it can and does happen. Usually subtly, but I&#= 39;ve also heard of much more overt instances. Fortunately hearsay is inadm= issible.

But we do have to be careful, and we really need to build up= a system that anticipates and survives bad actors, even of the most delibe= rate sort.

We live in a glass house, and people are now looking in. Roc= ks will be thrown. Wear your slippers and safety glasses.

--
Dean

--bcaec51d255e12b31604ea4c03db-- From melinda.shore@gmail.com Sun Nov 3 12:56:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD711E8170 for ; Sun, 3 Nov 2013 12:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4FeFzN3X26r for ; Sun, 3 Nov 2013 12:56:35 -0800 (PST) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24911E80FA for ; Sun, 3 Nov 2013 12:56:35 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id d7so1854772bkh.20 for ; Sun, 03 Nov 2013 12:56:34 -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=2AdhaZAApRX1bVXdZUt/UZh8ZtMlUPHg1vmZyr55ZMM=; b=k0Gp5+hFDRYbRO/UWGR92N5nn6TP0rGqZrtAtZGk1mz14sLCXYt/nM9uZjYzyYAunI W9m27d0aH34QmYzac60yOc5mPQbZxdCQSukDr8GIObxYifykONgrQolFb7glBU/eaMrR PB2/R+CqsBtoN/l2hOwJAqBNtS6uHVtMqXeYxssXEzv6ZqLBQ9COKpqRXKAFxiwnH+6I WiMaYwtB8Yx/P8+4H0CL7V/Qzub+ytzMuNR4WLVYQD1w9vtJibugDs9ttiLrSj7jvCWo jcrV0DlobGsW17ZRSf5vXNG82i+9Dm7u1MU//EDJrJyIogVlCjuzXwJJzEqsAYOvEZEI UWxQ== X-Received: by 10.204.171.17 with SMTP id f17mr606407bkz.38.1383512194570; Sun, 03 Nov 2013 12:56:34 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:4d45:4a68:a6c5:d83? ([2001:67c:370:160:4d45:4a68:a6c5:d83]) by mx.google.com with ESMTPSA id b6sm12549197bko.16.2013.11.03.12.56.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 12:56:34 -0800 (PST) Message-ID: <5276B880.3010007@gmail.com> Date: Sun, 03 Nov 2013 12:56:32 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: perpass@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:56:36 -0000 On 11/03/2013 12:54 PM, Dean Willis wrote: > Fortunately hearsay is inadmissible. INDEED. Melinda From hallam@gmail.com Sun Nov 3 18:01:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21A511E824D for ; Sun, 3 Nov 2013 18:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mlaBTHEsl45 for ; Sun, 3 Nov 2013 18:01:17 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0899621E8089 for ; Sun, 3 Nov 2013 18:01:09 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id l4so2767284lbv.37 for ; Sun, 03 Nov 2013 18:01: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=od9s4k/mmoBV/R1c7y58iaoEwZlPjQatu7UPDtOgVbQ=; b=ElLUIJG7642F9UXRTa9bAK9bMLrmSXfd32M5oYBmp3MVBs+Amu0UDYAOXtLIEuNIzL s/lHL/XshzydGTRa8fvsAwdIOdxTwltPiIVKbHsSZA2N1w8MbVIukx62C5CfgJHuZ4oH WkriQ8Nrx877I4MmvVPU+wiifYWpub5/CtvmNSLHSFq25/dkUPJXtGT9ZO7vdwEOMiEI uy9slsfXvx6tnF/+Xxri6N+BOD/Lw2MevnH+tnDY2wR3pqR2fubXe8dho8DsKqa/OBcc 3hedxTZynXVUju0wMMvJrXvGmigycpTl+jvqirYvTN1DmWi4bKrZEP5Z+VRA3FjJlT8M j++Q== MIME-Version: 1.0 X-Received: by 10.112.143.138 with SMTP id se10mr3066384lbb.26.1383530468502; Sun, 03 Nov 2013 18:01:08 -0800 (PST) Received: by 10.112.46.98 with HTTP; Sun, 3 Nov 2013 18:01:08 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Nov 2013 21:01:08 -0500 Message-ID: From: Phillip Hallam-Baker To: Dean Willis Content-Type: multipart/alternative; boundary=089e011828301c712004ea504ab4 Cc: perpass , Stephen Kent Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 02:01:19 -0000 --089e011828301c712004ea504ab4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis wrote: > > On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" wrote: > > > > > One of the issues that has been raised in the government world is how do > we convince people looking in that the IETF spec have not been contaminated > by some of the alleged $250 mil/yr being spent on such purposes. > > > > This is not a theoretical problem or even a new one, but it is one that > has been ignored in the past and is now going to be very much harder to > ignore. > > > > I'm pretty sure I got "persuaded" into buggering some security in RFC3261 > (sips: allowed to terminate at serving proxy rather than being e2e), at > least to the extent of accepting and endorsing a flawed argument that I now > believe would have made somebody's intercepts easier. Fortunately it turned > out not to matter much (as the defacto deployment was "no security" rather > than the piece I watered down), and it is now well-understood as an error. > > So it happens. Sometimes directly, sometimes indirectly as when your > customer or client is influenced into influencing your standards work. > > I didn't even realize what it was when it happened to me, and I used to > think I was pretty good at that game. Once burned, twice shy and all that. > > So I believe it can and does happen. Usually subtly, but I've also heard > of much more overt instances. Fortunately hearsay is inadmissible. > > But we do have to be careful, and we really need to build up a system that > anticipates and survives bad actors, even of the most deliberate sort. > > We live in a glass house, and people are now looking in. Rocks will be > thrown. Wear your slippers and safety glasses. > > -- > Dean > Have to remember that another possible mode of knobbling s spec is to persuade the WG to include a feature that will make deployment impractical. So 'weakening security' is not necessarily a sign of knobbling... -- Website: http://hallambaker.com/ --089e011828301c712004ea504ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis <<= a href=3D"mailto:dean.willis@softarmor.com" target=3D"_blank">dean.willis@s= oftarmor.com> wrote:


On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote: >

> One of the issues that has been raised in the governmen= t world is how do we convince people looking in that the IETF spec have not= been contaminated by some of the alleged $250 mil/yr being spent on such p= urposes.
>
> This is not a theoretical problem or even a new one, but it is one tha= t has been ignored in the past and is now going to be very much harder to i= gnore.
>

I'm pretty sure I got "persuaded" into b= uggering some security in RFC3261 (sips: allowed to terminate at serving pr= oxy rather than being e2e), at least to the extent of accepting and endorsi= ng a flawed argument that I now believe would have made somebody's inte= rcepts easier. Fortunately it turned out not to matter much (as the defacto= deployment was "no security" rather than the piece I watered dow= n), and it is now well-understood as an error.

So it happens. Sometimes directly, sometimes indirectly as w= hen your customer or client is influenced into influencing your standards w= ork.

I didn't even realize what it was when it happened to me= , and I used to think I was pretty good at that game. Once burned, twice sh= y and all that.

So I believe it can and does happen. Usually subtly, but I&#= 39;ve also heard of much more overt instances. Fortunately hearsay is inadm= issible.

But we do have to be careful, and we really need to build up= a system that anticipates and survives bad actors, even of the most delibe= rate sort.

We live in a glass house, and people are now looking in. Roc= ks will be thrown. Wear your slippers and safety glasses.

--
Dean


Have to remember that another possible mode of knobb= ling s spec is to persuade the WG to include a feature that will make deplo= yment impractical.

So 'weakening security' is not necessarily a sign of knobbling...


--
Website: http://hallambaker.com/
--089e011828301c712004ea504ab4-- From dean.willis@softarmor.com Mon Nov 4 10:30:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C15221F9EF6 for ; Mon, 4 Nov 2013 10:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.234 X-Spam-Level: X-Spam-Status: No, score=-101.234 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4yjhKuLY1Qh for ; Mon, 4 Nov 2013 10:30:56 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 386F011E8117 for ; Mon, 4 Nov 2013 10:30:56 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so1717767veb.37 for ; Mon, 04 Nov 2013 10:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b6aiWTcFIu0bbh9GAmq6VhydcNTm7b8cBjfeSjvNRXM=; b=NohRofvbzhOv2LyMdMBLDMyYZp32TbJwMSdPv85yTOyLw0zvKfLzip2TbSir+FGsL8 jseiNo3G5dD7VTA4BF4g+SrCuyQDjmRtVrO6tYTOv1T8rkfBiqpo3JBvYAjw2DR+qYSM wLd4mljNON8N9rtlLG1sr0pgHPeX5WL1roDqw= 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=b6aiWTcFIu0bbh9GAmq6VhydcNTm7b8cBjfeSjvNRXM=; b=lTSWOF/MNs1QZGCnieB6he4jat/FOeA7wEHo0T4jhUW29ZFGXYFimBgyN/iKS+y4of kiZ8HvTECHqoQ+hwtSoGrU8OLpzKKt0AnA9T+UugjIUnW9hwIPK6GusgH0ZtgS3r23A/ c5l+om2GYIIeMchc2DtdXCG4ll+2r5WwW28S5lzLqSDq0xGJ7zYzTSTvGDLkCwSLLcCw hBiPa6gpEbJz28siHnPypZlDG8J7Af4L7RiATXbUfHNJCq1r+XvFzMmGapBUpuoaaYV4 oQPIHzQK9kS4zdH/A9iXLpYX6tB+fgPoUgcZuRQ1WCtIWvW1VLB6usrvO9+ZUAfi6keE WMPw== X-Gm-Message-State: ALoCoQknY1SuZexwdTNdAf8WdOVXl+BKeonses/xvzb+H3qaOMhPu7SYe43ek7SCk08ptfwyrktj MIME-Version: 1.0 X-Received: by 10.220.174.200 with SMTP id u8mr12408135vcz.6.1383589855647; Mon, 04 Nov 2013 10:30:55 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 10:30:55 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 10:30:55 -0800 (PST) In-Reply-To: <20131020172006.GC23798@thunk.org> References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> Date: Mon, 4 Nov 2013 12:30:55 -0600 Message-ID: From: Dean Willis To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary=089e0149ca3adc7aed04ea5e1dbd Cc: Ted Hardie , Yoav Nir , perpass@ietf.org, Tony Rutkowski Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:30:57 -0000 --089e0149ca3adc7aed04ea5e1dbd Content-Type: text/plain; charset=ISO-8859-1 On Oct 20, 2013 12:20 PM, "Theodore Ts'o" wrote: > > On Sun, Oct 20, 2013 at 08:39:49AM -0400, Tony Rutkowski wrote: > > Perpass falls > > into the noise, except for generating new ideas > > for the above actors. > > People who feel this way certainly have no obligation to participate > in perpass. :-) But they do have such an obligation if their goal is to prevent attempts to make pervasive surveillance harder, more expensive, or less effective. There is a legitimate range for honest difference of opinion. Some folks really believe the Internet is best as a giant honeypot for identifying dissidents (or are paid to further that agenda). People like this can be reasonably expected to use every tool of argument and process available to dissuade us from doing anything. They'll tell us the effort is pointless, that it is too hard, that the changes required are too expensive, that the overheads will be too much. They'll call us traitors, thieves, and enablers of terrorism and child abuse. They'll try to sap our energy with contrary argument, divert our attention with shiny new problems, and use processes and procedures to block progress. But whether their opinions are honest or intentions malicious, they're just wrong. Their agenda is inconsistent with the future of a free and open Internet, and we must not let them stop the IETF and greater Internet community from improving operational privacy in the face of pervasive surveillance. --089e0149ca3adc7aed04ea5e1dbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 20, 2013 12:20 PM, "Theodore Ts'o" <tytso@mit.edu> wrote:
>
> On Sun, Oct 20, 2013 at 08:39:49AM -0400, Tony Rutkowski wrote:

> > Perpass falls
> > into the noise, except for generating new ideas
> > for the above actors.
>
> People who feel this way certainly have no obligation to participate > in perpass. =A0:-)

But they do have such an obligation if their goal is to prev= ent attempts to make pervasive surveillance harder, more expensive, or less= effective.

There is a legitimate range for honest difference of opinion= . Some folks really believe the Internet is best as a giant honeypot for id= entifying dissidents (or are paid to further that agenda).=A0 People like t= his can be reasonably expected to use every tool of argument and process av= ailable to dissuade us from doing anything.

They'll tell us the effort is pointless, that it is too = hard, that the changes required are too expensive, that the overheads will = be too much. They'll call us traitors, thieves, and enablers of terrori= sm and child abuse. They'll try to sap our energy with contrary argumen= t, divert our attention with shiny new problems, and use processes and proc= edures to block progress.

But whether their opinions are honest or intentions maliciou= s, they're just wrong. Their agenda is inconsistent with the future of = a free and open Internet, and we must not let them stop the IETF and greate= r Internet community from improving operational privacy in the face of perv= asive surveillance.

--089e0149ca3adc7aed04ea5e1dbd-- From melinda.shore@gmail.com Mon Nov 4 10:36:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326F21E8165 for ; Mon, 4 Nov 2013 10:36:52 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmrsQ1I+OpzP for ; Mon, 4 Nov 2013 10:36:51 -0800 (PST) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B27821E8131 for ; Mon, 4 Nov 2013 10:36:51 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id e11so797425bkh.5 for ; Mon, 04 Nov 2013 10:36:50 -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=qQoVghsdhMqfCTWHwFi7QueV7S5UpDhDmBpZ4zbLCmU=; b=AfGt/QGaNSiemMWI+h9vqxE9yfFN10blPy3ibQqiFLXKHsQhzcyd6AcfaF9bQwI4v2 ppTuUn7AqcZQhZNcOUbab0peHsokmnC/ne7KL/nfxt0B9OvOOqBsIgJZnaokNlJB1sog qzbYiKTRj57/bjX1mieMMFZpD7nOqgi5nkDhk4Z5BJsK31Ydz6tewwQXiHCyl4oyxzVI 2vJXkpFirndaCUCeCSHtGykqYn0eCUG+IdGlxh+uw1zMuUGm56LyD7ooz0pjMwJ/8Ki6 +BFxCJCPbuSvlx8N2cLPbrauX31ss81Y4QcJuRAiq7vE8ejYEGQycZrFZo80WhP1A8VH wiyw== X-Received: by 10.205.14.69 with SMTP id pp5mr10611095bkb.14.1383590210635; Mon, 04 Nov 2013 10:36:50 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:4d45:4a68:a6c5:d83? ([2001:67c:370:160:4d45:4a68:a6c5:d83]) by mx.google.com with ESMTPSA id qg7sm16318912bkb.6.2013.11.04.10.36.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 10:36:49 -0800 (PST) Message-ID: <5277E93F.4000905@gmail.com> Date: Mon, 04 Nov 2013 10:36:47 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: perpass@ietf.org References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:36:52 -0000 On 11/04/2013 10:30 AM, Dean Willis wrote: > They'll tell us the effort is pointless, that it is too hard, that the > changes required are too expensive, that the overheads will be too much. > They'll call us traitors, thieves, and enablers of terrorism and child > abuse. They'll try to sap our energy with contrary argument, divert our > attention with shiny new problems, and use processes and procedures to > block progress. I find this to be histrionic, hyperbolic, and a distraction. Most of all I find it largely irrelevant, as I don't think I've seen anybody here argue against the need to improve privacy mechanisms in IETF technologies. There appears to be consensus that this is the case; I certainly haven't seen any vigorous argument to the contrary. If you're trying to answer people outside the IETF, this is probably the wrong forum. Melinda From dean.willis@softarmor.com Mon Nov 4 10:45:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E1811E8142 for ; Mon, 4 Nov 2013 10:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.42 X-Spam-Level: X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjYKxjXpDbTG for ; Mon, 4 Nov 2013 10:45:53 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 532CD21E8064 for ; Mon, 4 Nov 2013 10:45:48 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id c14so1731200vea.14 for ; Mon, 04 Nov 2013 10:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sDgWeijqqyf9oO0TySJ+mWdf6DBaa24OOUDTcXPXJUk=; b=ML1hOWyAY9iUjOGrJ3VBkkURdYHnpLIK/Q0EPppmOOaL19iMQp2gnhF7eeuejq3aq8 sxaYtaNkvQpKZ43KA2077bD2+XlwznoqsDQeMFizaE0YPpza2iDy5fjGcbtu5xKMYpBo mg1aYXxL7Bqnsablfn6O1WCl4AGwq1Et4Kn88= 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=sDgWeijqqyf9oO0TySJ+mWdf6DBaa24OOUDTcXPXJUk=; b=Lhyw6z3v54FKb9Vfv1g6NsnA8VI8mXGOS2D/9I1T8rbNziHdz2hUkE5J75HJK41zAv +juyPWZ/ReT49lsA5vfPvfCNfQDx/Aet/k1mLrgP/nqoKmEcm175W7DNVuJCSoZdocxT XgnFH1NCcjvupQdM2B27Ozo7uj/pd/1pBWonunX8y9eBoL/alLJ70/RMEnp6uoldqIQ5 PsnXItytngqx0HTtgS2nL8eBmYPUmJj8rx8srGhD8S3zXzoZlOiDUfufyZUzCInkQK9w VDHqXtqRiRQnsGwwA5FwK7Y9+Nw0XDBhwL9GRmqZjhMVDmpDCiQBab05wfGRgfCw7R53 xKqA== X-Gm-Message-State: ALoCoQk4fe1Mh/ivdtA6Fk9FVERiNvy1uF0L4rddVACr/qPycircxEKaByDukf1gePMqd1RkFwiP MIME-Version: 1.0 X-Received: by 10.220.86.69 with SMTP id r5mr12413658vcl.9.1383590744861; Mon, 04 Nov 2013 10:45:44 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 10:45:44 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 10:45:44 -0800 (PST) In-Reply-To: <5277E93F.4000905@gmail.com> References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277E93F.4000905@gmail.com> Date: Mon, 4 Nov 2013 12:45:44 -0600 Message-ID: From: Dean Willis To: Melinda Shore Content-Type: multipart/alternative; boundary=001a11c1ff44dcfdc704ea5e52f5 Cc: perpass@ietf.org Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:45:55 -0000 --001a11c1ff44dcfdc704ea5e52f5 Content-Type: text/plain; charset=ISO-8859-1 On Nov 4, 2013 12:37 PM, "Melinda Shore" wrote: > > On 11/04/2013 10:30 AM, Dean Willis wrote: >> >> They'll tell us the effort is pointless, that it is too hard, that the >> changes required are too expensive, that the overheads will be too much. >> They'll call us traitors, thieves, and enablers of terrorism and child >> abuse. They'll try to sap our energy with contrary argument, divert our >> attention with shiny new problems, and use processes and procedures to >> block progress. > > > I find this to be histrionic, hyperbolic, and a distraction. Most of > all I find it largely irrelevant, as I don't think I've seen anybody > here argue against the need to improve privacy mechanisms in IETF > technologies. There appears to be consensus that this is the case; > I certainly haven't seen any vigorous argument to the contrary. If > you're trying to answer people outside the IETF, this is probably the > wrong forum. > Perhaps you should read more carefully. I believe I've seen every one of these techniques applied within the IETF community since the Snowden revelations began focusing our attention on pervasive security. It became even more apparent as I read through the perpass list archive over the last couple of days. I might be paranoid, but that doesn't mean they're not out to get me... --001a11c1ff44dcfdc704ea5e52f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 4, 2013 12:37 PM, "Melinda Shore" <melinda.shore@gmail.com> wrote:
>
> On 11/04/2013 10:30 AM, Dean Willis wrote:
>>
>> They'll tell us the effort is pointless, that it is too hard, = that the
>> changes required are too expensive, that the overheads will be too= much.
>> They'll call us traitors, thieves, and enablers of terrorism a= nd child
>> abuse. They'll try to sap our energy with contrary argument, d= ivert our
>> attention with shiny new problems, and use processes and procedure= s to
>> block progress.
>
>
> I find this to be histrionic, hyperbolic, and a distraction. =A0Most o= f
> all I find it largely irrelevant, as I don't think I've seen a= nybody
> here argue against the need to improve privacy mechanisms in IETF
> technologies. =A0There appears to be consensus that this is the case;<= br> > I certainly haven't seen any vigorous argument to the contrary. = =A0If
> you're trying to answer people outside the IETF, this is probably = the
> wrong forum.
>

Perhaps you should read more carefully.=A0 I believe I'v= e seen every one of these techniques applied within the IETF community sinc= e the Snowden revelations began focusing our attention on pervasive securit= y.=A0 It became even more apparent as I read through the perpass list archi= ve over the last couple of days.

I might be paranoid, but that doesn't mean they're n= ot out to get me...

--001a11c1ff44dcfdc704ea5e52f5-- From kent@bbn.com Mon Nov 4 11:16:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C7B21E8211 for ; Mon, 4 Nov 2013 11:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKCSpwg3bqlX for ; Mon, 4 Nov 2013 11:16:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CC00021E820A for ; Mon, 4 Nov 2013 11:16:46 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33236 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VdPdl-000Aah-Pr for perpass@ietf.org; Mon, 04 Nov 2013 14:16:45 -0500 Message-ID: <5277F29D.6040609@bbn.com> Date: Mon, 04 Nov 2013 14:16:45 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:16:58 -0000 Dean, > > ... > > But whether their opinions are honest or intentions malicious, they're > just wrong. > So your bottom line is that anyone who disagrees with your perception of what tradeoffs may be appropriate for security & privacy vs. performance, user convenience, etc. is "just wrong." Nice to know it's that simple. Steve From dean.willis@softarmor.com Mon Nov 4 13:20:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00FF11E8163 for ; Mon, 4 Nov 2013 13:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.531 X-Spam-Level: X-Spam-Status: No, score=-101.531 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bryEMWbTO57p for ; Mon, 4 Nov 2013 13:20:34 -0800 (PST) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7D21F9FCE for ; Mon, 4 Nov 2013 13:20:02 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id w8so1830000vbj.0 for ; Mon, 04 Nov 2013 13:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LVd0CLjkVXckRXrYqCZpIdNAUv+d9uppP/qDBQWQB28=; b=Nr4i5UAxIMW52B3WdHfJO9amAZPXjwtjm/x0pWOVo0yHf8lScvGlu2RMkbbFSiM6HH SfLaYBC8fZp3u0X8BR7qXgTulUK5S1dKWPA01jq20I+sHvoW4YxOpnG+eIGSxi+HboJP VshHxNK0OUxSDpHRqD5W4zdpJcCgVN64Hh9d8= 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=LVd0CLjkVXckRXrYqCZpIdNAUv+d9uppP/qDBQWQB28=; b=Hw1k2jhuc2nAMXPqiK6znDjbUeWHN7g91VigmF55iQY5odCbz9JSpgN5uETHZ3i1yX 6/A1NxJph6nwhEmtOk0t/ubc8RmVtUyYMtgsAEgBH4i0wQnfeSEkhxONeaQ5kRahlfPA PiPvF5yfJo3mBY34ZiJnOp5Jq8iPwo38AH4UAHsXnaajUgEfP012uyemgh4ji4VXtffg +c79zOPnWNQEK2ei6TZoxwlvzMScr4+6PzilnH17xgzCW4znBninHVt9ZC10zUcJgsFz xuzLYnGSxnK23uITAKoG1cDClc7acu2VFm01cCRW4aFme8pVCAT4xZ7KyBKj7Q8tFXFL nZSg== X-Gm-Message-State: ALoCoQkydS5HcYf0aSSry9d1a9ErLUN8HIy07P1drU/MPgZ4NUnieRQOBC53yQ+XDMYGA9D/jJe7 MIME-Version: 1.0 X-Received: by 10.52.35.20 with SMTP id d20mr1463059vdj.33.1383600001665; Mon, 04 Nov 2013 13:20:01 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 13:20:01 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 13:20:01 -0800 (PST) In-Reply-To: <7A3480BE-9791-4B80-B5B7-6B07F9F68E48@iii.ca> References: <7A3480BE-9791-4B80-B5B7-6B07F9F68E48@iii.ca> Date: Mon, 4 Nov 2013 15:20:01 -0600 Message-ID: From: Dean Willis To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf307d00ce9c671004ea607ae8 Cc: perpass@ietf.org Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:20:35 -0000 --20cf307d00ce9c671004ea607ae8 Content-Type: text/plain; charset=ISO-8859-1 One thing you don't elaborate is reduction of the metadata attack surface by reducing the amount of exposed metadata. In a messaging model, the only thing that needs to be exposed "to the cloud" is the destination locator, and possibly a random-ish (perhaps a hash of the content) message tag. See the Crowcroft SNA idea previously referenced on this list. Note that one can certainly envision an onion-routing model here that could further obfuscate peer linkages "within the cloud". Especially with randomized timing. On Oct 20, 2013 5:57 PM, "Cullen Jennings" wrote: > > I've been thinking about how to build cloud collaborations systems where > the data is encrypted and the cloud does not have the keys. Very interested > in hearing others thoughts on how to do this. > > Near the end is a list of things that it would be helpful if the IETF > standardized. > > http://www.ietf.org/id/draft-jennings-perpass-secure-rai-cloud-00.pdf > > Cullen > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --20cf307d00ce9c671004ea607ae8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

One thing you don't elaborate is reduction of the metada= ta attack surface by reducing the amount of exposed metadata. In a messagin= g model, the only thing that needs to be exposed "to the cloud" i= s the destination locator, and possibly a random-ish (perhaps a hash of the= content) message tag. See the Crowcroft SNA idea previously referenced on = this list.

Note that one can certainly envision an onion-routing model = here that could further obfuscate peer linkages "within the cloud"= ;. Especially with randomized timing.

On Oct 20, 2013 5:57 PM, "Cullen Jennings&q= uot; <fluffy@iii.ca> wrote:

I've been thinking about how to build cloud collaborations systems wher= e the data is encrypted and the cloud does not have the keys. Very interest= ed in hearing others thoughts on how to do this.

Near the end is a list of things that it would be helpful if the IETF stand= ardized.

http://www.ietf.org/id/draft-jennings-perpass-secu= re-rai-cloud-00.pdf

Cullen

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--20cf307d00ce9c671004ea607ae8-- From wilton@isoc.org Mon Nov 4 13:36:17 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0311E81F9 for ; Mon, 4 Nov 2013 13:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZT85TdtZYvC for ; Mon, 4 Nov 2013 13:36:09 -0800 (PST) Received: from smtp186.dfw.emailsrvr.com (smtp186.dfw.emailsrvr.com [67.192.241.186]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0A11E81AF for ; Mon, 4 Nov 2013 13:36:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 5B95926813A; Mon, 4 Nov 2013 16:36:06 -0500 (EST) X-Virus-Scanned: OK Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id AC247268146; Mon, 4 Nov 2013 16:36:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_4B6F34CA-C8F1-4A26-A820-CB8E29830E1C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Mon, 4 Nov 2013 13:36:27 -0800 Message-Id: <603E5585-3320-4CF8-A87E-B68F89C98930@isoc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1283) Cc: perpass , Stephen Kent , Dean Willis Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:36:17 -0000 --Apple-Mail=_4B6F34CA-C8F1-4A26-A820-CB8E29830E1C Content-Type: multipart/alternative; boundary="Apple-Mail=_97AA0E7E-6429-4CFA-859B-9FC8DAB026C7" --Apple-Mail=_97AA0E7E-6429-4CFA-859B-9FC8DAB026C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Also worth bearing in mind, I think, that in the lifecycle of any given = technology, the phases that are most laid open to a culture of peer = inspection and challenge are the R&D and the standardisation phases.=20 The subsequent implementation and deployment phases are, by their = nature, far less likely to be conducted openly or subjected to = unrestricted external review (as opposed to comparatively constrained = audit). As Dean says, the pragmatic approach isn't to try and eradicate the = possibility of bad actors, but to adopt a way of working that minimises = their chances of action and or success. My personal view is that the = current way of working is less bad in that respect than any of the = alternatives. Yrs., Robin =20 =20 Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 3 Nov 2013, at 18:01, Phillip Hallam-Baker wrote: >=20 >=20 >=20 > On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis = wrote: >=20 > On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" = wrote: > > >=20 > > One of the issues that has been raised in the government world is = how do we convince people looking in that the IETF spec have not been = contaminated by some of the alleged $250 mil/yr being spent on such = purposes. > > > > This is not a theoretical problem or even a new one, but it is one = that has been ignored in the past and is now going to be very much = harder to ignore. > > >=20 > I'm pretty sure I got "persuaded" into buggering some security in = RFC3261 (sips: allowed to terminate at serving proxy rather than being = e2e), at least to the extent of accepting and endorsing a flawed = argument that I now believe would have made somebody's intercepts = easier. Fortunately it turned out not to matter much (as the defacto = deployment was "no security" rather than the piece I watered down), and = it is now well-understood as an error. >=20 > So it happens. Sometimes directly, sometimes indirectly as when your = customer or client is influenced into influencing your standards work. >=20 > I didn't even realize what it was when it happened to me, and I used = to think I was pretty good at that game. Once burned, twice shy and all = that. >=20 > So I believe it can and does happen. Usually subtly, but I've also = heard of much more overt instances. Fortunately hearsay is inadmissible. >=20 > But we do have to be careful, and we really need to build up a system = that anticipates and survives bad actors, even of the most deliberate = sort. >=20 > We live in a glass house, and people are now looking in. Rocks will be = thrown. Wear your slippers and safety glasses. >=20 > -- > Dean >=20 >=20 > Have to remember that another possible mode of knobbling s spec is to = persuade the WG to include a feature that will make deployment = impractical. >=20 > So 'weakening security' is not necessarily a sign of knobbling... >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_97AA0E7E-6429-4CFA-859B-9FC8DAB026C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Also = worth bearing in mind, I think, that in the lifecycle of any given = technology, the phases that are most laid open to a culture of peer = inspection and challenge are the R&D and the standardisation = phases. 

The subsequent implementation and = deployment phases are, by their nature, far less likely to be conducted = openly or subjected to unrestricted external review (as opposed to = comparatively constrained audit).

As Dean says, = the pragmatic approach isn't to try and eradicate the possibility of bad = actors, but to adopt a way of working that minimises their chances of = action and or success. My personal view is that the current way of = working is less bad in that respect than any of the = alternatives.

Yrs.,
Robin =  
   
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 3 Nov 2013, at 18:01, Phillip Hallam-Baker = wrote:




On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis <dean.willis@softarmor.com> wrote:


On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>

> One of the issues that has been raised in = the government world is how do we convince people looking in that the = IETF spec have not been contaminated by some of the alleged $250 mil/yr = being spent on such purposes.
>
> This is not a theoretical problem or even a new one, but it is one = that has been ignored in the past and is now going to be very much = harder to ignore.
>

I'm pretty sure I got "persuaded" into buggering = some security in RFC3261 (sips: allowed to terminate at serving proxy = rather than being e2e), at least to the extent of accepting and = endorsing a flawed argument that I now believe would have made = somebody's intercepts easier. Fortunately it turned out not to matter = much (as the defacto deployment was "no security" rather than the piece = I watered down), and it is now well-understood as an error.

So it happens. Sometimes directly, sometimes indirectly as = when your customer or client is influenced into influencing your = standards work.

I didn't even realize what it was when = it happened to me, and I used to think I was pretty good at that game. = Once burned, twice shy and all that.

So I believe it = can and does happen. Usually subtly, but I've also heard of much more = overt instances. Fortunately hearsay is inadmissible.

But we do have to be careful, and we really need to build up = a system that anticipates and survives bad actors, even of the most = deliberate sort.

We live in a glass house, and people = are now looking in. Rocks will be thrown. Wear your slippers and safety = glasses.

--
Dean


Have to remember that another possible mode of = knobbling s spec is to persuade the WG to include a feature that will = make deployment impractical.

So 'weakening security' is not necessarily a sign of knobbling...


--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= --Apple-Mail=_97AA0E7E-6429-4CFA-859B-9FC8DAB026C7-- --Apple-Mail=_4B6F34CA-C8F1-4A26-A820-CB8E29830E1C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTA0MjEzNjI3WjAjBgkqhkiG9w0BCQQxFgQUoy6FnCA4qc8vlrJsYB8T joD6cj0wdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBADMuOUvZAPSZxZ2+9muc7gtK wKg6r8/v8xWohfJF+rnRaCVhbwnqHwF/m0WRjO3bhmQjNnweLdFYsEdoqOLNocTqgXaR+yf/3gXF 3xlkFTNaoefNWV7Kk0bBqEiaEl5vgpxrQM++z5VKd99b+OA0qdaqRVEmDzpGEkXt/DWkuTdmrN7i UxhkOBoHvkboogunbZymzhGOzVncV9h9cqOr5dqfir7DrAemnCtAp+qPb/SeMYVN1WOl5WP+PQQD JFOQAMiKRwo9t1lyzlNmWTHqUiXapsnu/n6ElzBtdtpv/Bnj+sWipVm9s9HRPOUAGTm3hzDIK2YI c04dr40RAX+o61QAAAAAAAA= --Apple-Mail=_4B6F34CA-C8F1-4A26-A820-CB8E29830E1C-- From leifj@mnt.se Mon Nov 4 13:41:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E177521E81C1 for ; Mon, 4 Nov 2013 13:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYYPwAmLbrmu for ; Mon, 4 Nov 2013 13:41:43 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CB21E81B4 for ; Mon, 4 Nov 2013 13:41:33 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so3815980lbv.0 for ; Mon, 04 Nov 2013 13:41:32 -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:content-type:content-transfer-encoding; bh=tlkotds8DUcV+VkKMmZUHGK0PprX9ebX8zXxl+mCAow=; b=UX2FKr+mbJjkbEpYpvebHERe1QjJoKvOYLtTZG2bnKj2jaG93ymamVp4twfqOWWKy1 PsoerHh82/oZYTo9reIxx+Gp8mRAE7NaXoOXcw93Dogp1cl1UQflrqxrqFg9xpBiIFow ggXbIz+j8o7hYkXJ4eJulhicG01DWHlhRwhJfKs9LgbEA1ouIkr1+IXw0Fy3k+B4jWcY qFoe02EJh+xFHUJxFqTG0hy6bkHhqErydUhFAEaxhAHcoOLEyuaz0ikJrbzxYH7MH8kc 4WUQR1SGN9gzPFOPzTnuu+ifekLRgy55idM0idbU7HUGt/Dp2OJ5YI0/hth2FBn6Q660 2axQ== X-Gm-Message-State: ALoCoQlhEmHZI+mJD4Gf8vCGhgJlnfVTvmRljyRhrIamU3Il/OLAEDwr13vyi9dMwMffgjJzOQaP X-Received: by 10.152.22.198 with SMTP id g6mr13290812laf.5.1383601292759; Mon, 04 Nov 2013 13:41:32 -0800 (PST) Received: from [31.133.152.76] (dhcp-984c.meeting.ietf.org. [31.133.152.76]) by mx.google.com with ESMTPSA id go4sm1005679lbc.3.2013.11.04.13.41.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 13:41:31 -0800 (PST) Message-ID: <52781478.6010205@mnt.se> Date: Mon, 04 Nov 2013 22:41:12 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "perpass@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:41:54 -0000 Folks, Recent revelations have called into question the integrity of some of the implementations of basic cryptographic functions and devices used to secure communications on the Internet. There are questions about some algorithms but more particularly about implementations of algorithms in software and hardware. The Internet community can and must deal with these implementation issues. A few individuals and organizations are therefore embarking on an effort to investigate and promote the development of an open-source hardware cryptographic engine that meets the needs of high assurance Internet infrastructure that use cryptography. Such an engine must also be of general use to the broad Internet community, covering the cryptographic needs for applications such as secure email, web, DNS, PKIs, etc. We are therefore hosting an informal discussion focusing on gathering use-cases for such an engine/module. Time: Thursday Lunch (11:30) Place: Plaza B Randy Bush Stephen Farrell Leif Johansson Lucy Lynch Linus Nordberg From merike@doubleshotsecurity.com Mon Nov 4 13:57:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0C21F9F97 for ; Mon, 4 Nov 2013 13:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySlGsXkVKxBc for ; Mon, 4 Nov 2013 13:57:33 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2D21F9A40 for ; Mon, 4 Nov 2013 13:57:14 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rA4LvCEv007311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Nov 2013 13:57:12 -0800 Received: from dhcp-b087.meeting.ietf.org (dhcp-b087.meeting.ietf.org [31.133.176.135]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id rA4LvBPb022789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 13:57:11 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: <52781478.6010205@mnt.se> Date: Mon, 4 Nov 2013 13:57:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> References: <52781478.6010205@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1510) X-Sonic-ID: C;dEkSD5xF4xGey1gAt3+xLg== M;pBYfD5xF4xGey1gAt3+xLg== Cc: "perpass@ietf.org" Subject: Re: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:57:38 -0000 I unfortunately have to leave Wednesday eve and can't attend this = meeting but applaud this effort. - merike On Nov 4, 2013, at 1:41 PM, Leif Johansson wrote: > Folks, >=20 > Recent revelations have called into question the integrity of > some of the implementations of basic cryptographic functions > and devices used to secure communications on the Internet.=20 >=20 > There are questions about some algorithms but more particularly > about implementations of algorithms in software and hardware. > The Internet community can and must deal with these > implementation issues. >=20 > A few individuals and organizations are therefore embarking > on an effort to investigate and promote the development of an=20 > open-source hardware cryptographic engine that meets the needs=20 > of high assurance Internet infrastructure that use cryptography. >=20 > Such an engine must also be of general use to the broad Internet > community, covering the cryptographic needs for applications > such as secure email, web, DNS, PKIs, etc. >=20 > We are therefore hosting an informal discussion focusing on gathering > use-cases for such an engine/module. >=20 > Time: Thursday Lunch (11:30) > Place: Plaza B >=20 >=20 > Randy Bush > Stephen Farrell > Leif Johansson > Lucy Lynch > Linus Nordberg >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 From kathleen.moriarty@emc.com Mon Nov 4 14:04:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE71811E81F9 for ; Mon, 4 Nov 2013 14:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0jr3FzLlwry for ; Mon, 4 Nov 2013 14:03:58 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 999B511E81E3 for ; Mon, 4 Nov 2013 14:03:30 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA4M3M0Q015564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 17:03:23 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rA4M3M0Q015564 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383602603; bh=6exYyPwwvkLFVq/PM/Axk+GNVD4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AcOKn3gKq92wdK6ZA+FilpYAiPJnT42N9v1h4tb/X8EETk3WlKdOdYS984lD1msN1 fwMJeQW4mTlZqxcHkSXIDC5birjKVT4ZxKV3w2+Jitl8DGBJoXRkZAOvuQg60eaiSn CTUNIaX2UZmfaoGImUmYICkv6MvijQs7pWE+7pX4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rA4M3M0Q015564 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 4 Nov 2013 14:03:09 -0800 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA4M39X5007450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 17:03:09 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Mon, 4 Nov 2013 17:03:09 -0500 From: "Moriarty, Kathleen" To: Merike Kaeo Date: Mon, 4 Nov 2013 17:03:05 -0500 Thread-Topic: [perpass] informal meeting on open-hardware crypto Thread-Index: Ac7ZqaVCvxqU5HQJShyjyyYD0kQ4Ag== Message-ID: <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> References: <52781478.6010205@mnt.se> <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> In-Reply-To: <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:04:02 -0000 Could a summary be provided? I am interested, but the time conflicts with = the Systers lunch. Thanks, Kathleen=20 Sent from my iPhone On Nov 4, 2013, at 1:59 PM, "Merike Kaeo" w= rote: > I unfortunately have to leave Wednesday eve and can't attend this meeting= but applaud this effort. >=20 > - merike >=20 > On Nov 4, 2013, at 1:41 PM, Leif Johansson wrote: >=20 >> Folks, >>=20 >> Recent revelations have called into question the integrity of >> some of the implementations of basic cryptographic functions >> and devices used to secure communications on the Internet.=20 >>=20 >> There are questions about some algorithms but more particularly >> about implementations of algorithms in software and hardware. >> The Internet community can and must deal with these >> implementation issues. >>=20 >> A few individuals and organizations are therefore embarking >> on an effort to investigate and promote the development of an=20 >> open-source hardware cryptographic engine that meets the needs=20 >> of high assurance Internet infrastructure that use cryptography. >>=20 >> Such an engine must also be of general use to the broad Internet >> community, covering the cryptographic needs for applications >> such as secure email, web, DNS, PKIs, etc. >>=20 >> We are therefore hosting an informal discussion focusing on gathering >> use-cases for such an engine/module. >>=20 >> Time: Thursday Lunch (11:30) >> Place: Plaza B >>=20 >>=20 >> Randy Bush >> Stephen Farrell >> Leif Johansson >> Lucy Lynch >> Linus Nordberg >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 From melinda.shore@gmail.com Mon Nov 4 14:09:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68021F99F7 for ; Mon, 4 Nov 2013 14:09:55 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OdVoHqtLyQo for ; Mon, 4 Nov 2013 14:09:54 -0800 (PST) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7C221F999C for ; Mon, 4 Nov 2013 14:09:17 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id v4so3258374bkz.9 for ; Mon, 04 Nov 2013 14:09:16 -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=Wvvq7IKMvFD+e41UwxjGFIkO4mHGqJcel9tHD2N6ZBE=; b=xlNFOD1mVbG2cULMbLYjb7j1P1QCZMREW1Zaan877EItJJbdMDUPNCi2zQJa4dlBgn OPDeujFx91c4C+qEOd6LhXpxUidQi3D3CvIGjiy3YTZLfHa1VZXL8MYypPZ6egH98A99 uxjZxD+4Gc4sVG70Z3tNgwdR5QSiZJv3LT0gK2MUBivue9Op/JGZf1yttRpFwkXUo3Qn aEJchL5+U9TT75Yhwtn2rBm1Z0Ghsxk68vpyl7itKCk6svIrPeO93+VYGtoBX55loZtW pi2AHTmfaN7gN0A3uB8xVsDTwcKaaQ8ogAUSyTYBym8jFOE6nqALQS8QlXd8bXKw9DPX EbpQ== X-Received: by 10.204.233.129 with SMTP id jy1mr5601393bkb.27.1383602956729; Mon, 04 Nov 2013 14:09:16 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:4d45:4a68:a6c5:d83? ([2001:67c:370:144:4d45:4a68:a6c5:d83]) by mx.google.com with ESMTPSA id pn6sm16916644bkb.14.2013.11.04.14.09.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:09:16 -0800 (PST) Message-ID: <52781B0A.6030507@gmail.com> Date: Mon, 04 Nov 2013 14:09:14 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52781478.6010205@mnt.se> <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> In-Reply-To: <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:09:55 -0000 On 11/04/2013 02:03 PM, Moriarty, Kathleen wrote: > Could a summary be provided? I am interested, but the time conflicts with the Systers lunch. Right, unfortunately it conflicts with both the Systers lunch and with the informal DANE confabulation. Melinda From leifj@mnt.se Mon Nov 4 14:12:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8221F9901 for ; Mon, 4 Nov 2013 14:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwYCNmeqJCAf for ; Mon, 4 Nov 2013 14:12:18 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 360E611E8225 for ; Mon, 4 Nov 2013 14:12:11 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id z5so5850658lbh.21 for ; Mon, 04 Nov 2013 14:12:09 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q0zThf9c+8kIO3K8R5dt3MVqmLDy3YFjWVsr2LO049U=; b=PHC2zny3orFeSow2+y/e8myXm7wtAxwViWzRbjv00iaaU4eVCb16426L/n/7QKC2/A Xi+oVPaG9IP7/TiS0AkXJzWF0Qq1arOIgADFDOXKRPqA4pxvfQGLRSGy7l+4nMyjDC38 FGWLXd7/IaZQDiEGCLdopHsLI3+EhG5yQGnoSho2QNYpIFO/l/9UQjnzF8qsS/qhODSz wK0Eafx/xMY/5ZMa++Y2F6fgekpwbYK7R1FqDazIq9mDJvMXI9Q5BTT7mG6Q8ZlkuU+i caCUr4QKg9bWgJJzpX6mTkQ414HFZunyiZMwKSSsCFkaP580oxxSpAImE0VIIPc+Whlw Unzg== X-Gm-Message-State: ALoCoQlRfTCg2gGVH2ePkLQ2yp+C3/PSfZBDFDWQV2b7ytu1Q3Hn00W3FErnQ1lgJxhinvglWODd X-Received: by 10.152.239.164 with SMTP id vt4mr8112094lac.8.1383603129578; Mon, 04 Nov 2013 14:12:09 -0800 (PST) Received: from [31.133.160.141] (dhcp-a08d.meeting.ietf.org. [31.133.160.141]) by mx.google.com with ESMTPSA id o1sm24762475lah.8.2013.11.04.14.12.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:12:08 -0800 (PST) Message-ID: <52781BB5.1090802@mnt.se> Date: Mon, 04 Nov 2013 23:12:05 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: <52781478.6010205@mnt.se> <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> In-Reply-To: <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" Subject: Re: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:12:24 -0000 On 11/04/2013 11:03 PM, Moriarty, Kathleen wrote: > Could a summary be provided? I am interested, but the time conflicts with the Systers lunch. > After the meeting? Certainly, we'll take notes and send to the list. Cheers Leif From kathleen.moriarty@emc.com Mon Nov 4 14:16:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E621E8153 for ; Mon, 4 Nov 2013 14:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m4hvzAUDtlR for ; Mon, 4 Nov 2013 14:16:09 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1030721E824E for ; Mon, 4 Nov 2013 14:15:36 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA4MFZCE013986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 17:15:36 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA4MFZCE013986 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383603336; bh=eLTxC7RLzjjyChKl8wLFx8Cw/9A=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TChsBEmHkAc4LFSh0uVsxfoL1lsumR52ZKhjtiuebJHeOPuLEGOUqTGWXp2W4dJFB WPx+nxPw/mEYLEdp8h0pwgnRN8x/Yeny2DFF7PHZ0PsTy6wbMez5A61KykJmD55r1s bz5Na1n5MwKYlinjEha4J7xTGg1wV76tlQ8ngU6Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA4MFZCE013986 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd54.lss.emc.com (RSA Interceptor); Mon, 4 Nov 2013 17:15:21 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA4MFLGL003283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 17:15:21 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Mon, 4 Nov 2013 17:15:21 -0500 From: "Moriarty, Kathleen" To: Leif Johansson Date: Mon, 4 Nov 2013 17:15:18 -0500 Thread-Topic: [perpass] informal meeting on open-hardware crypto Thread-Index: Ac7Zq1lpRy2dOQgjSm6KAAO6EFBkaA== Message-ID: References: <52781478.6010205@mnt.se> <415457C0-7F6A-4479-A1BD-DD78772C9A8E@doubleshotsecurity.com> <1FA0A797-9514-4957-B5BB-A0B1369C8045@emc.com> <52781BB5.1090802@mnt.se> In-Reply-To: <52781BB5.1090802@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Cc: "perpass@ietf.org" Subject: Re: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:16:22 -0000 Thank you. Sent from my iPhone On Nov 4, 2013, at 2:14 PM, "Leif Johansson" wrote: > On 11/04/2013 11:03 PM, Moriarty, Kathleen wrote: >> Could a summary be provided? I am interested, but the time conflicts wi= th the Systers lunch. > After the meeting? Certainly, we'll take notes and send to the list. >=20 > Cheers Leif >=20 From dean.willis@softarmor.com Mon Nov 4 14:42:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8321E8173 for ; Mon, 4 Nov 2013 14:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPcOz2Vq-z5c for ; Mon, 4 Nov 2013 14:42:15 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E7F1621E81BC for ; Mon, 4 Nov 2013 14:42:12 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id c14so1976417vea.27 for ; Mon, 04 Nov 2013 14:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o6B1WslWxCk8e9sFxzhxy4ZicXfv9Pqn2MyaWXgOzlA=; b=Rd+8bdzA9vikrs/vstg1PFZUS1fAUXtxmruvLe3StmNOMyaPs40ZGXm5KyXzfrSPjg l3h0jvNEXCyQ9irc9bFE8KupM9UZSomuaJqSnYfrWa4/laB15Ka4k1no2hLdv61WhmtO BCeQqmZg0hga4Uh1Zm/QsLJUmHQPRhvt53xgU= 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=o6B1WslWxCk8e9sFxzhxy4ZicXfv9Pqn2MyaWXgOzlA=; b=RfH2eHwpidN/gC0SNLxwNJhfcQ8mixsNi1zwvCoDqT9HZwBY/XLGBlLbhDXp4mOaUs mjTATH/hUMQWtNPub1aRU0UloQ4ezseASSQy0PAiAMOnvNcFjxZW7UvvqAbDFDoPgGa0 SBPb9/7s+FgP6GGhCw4W7f7IgAtyGEGzRquEXfUGqU0FyAvb5q8ix3kBbgHm0hMI2W3r pZVaO9KqGbzgS55MulTposCrJ/IfCXbbkQG8dx8Y+qc6feNhXkqJpCZfWgkAA9V2Lnla 27/u47GclIDiJZvRRtm6oCzj0wZdHPKIUKsqZ2I3uVNTHlJTLbKN/RPem+xlUlOHYRXA hDAQ== X-Gm-Message-State: ALoCoQliwNlvqPYoqia75YAdAHbr3Jth8hhRjogmebhPqfrSJ5HlX9KJnQZxBlMemNqaINNOEsvr MIME-Version: 1.0 X-Received: by 10.220.78.18 with SMTP id i18mr13163936vck.3.1383604932361; Mon, 04 Nov 2013 14:42:12 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 14:42:12 -0800 (PST) Received: by 10.58.173.72 with HTTP; Mon, 4 Nov 2013 14:42:12 -0800 (PST) In-Reply-To: <5277F29D.6040609@bbn.com> References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277F29D.6040609@bbn.com> Date: Mon, 4 Nov 2013 16:42:12 -0600 Message-ID: From: Dean Willis To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b3a8b028106af04ea61a027 Cc: perpass@ietf.org Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:42:16 -0000 --047d7b3a8b028106af04ea61a027 Content-Type: text/plain; charset=ISO-8859-1 On Nov 4, 2013 1:18 PM, "Stephen Kent" wrote: > > Dean, >> >> >> ... >> >> >> But whether their opinions are honest or intentions malicious, they're just wrong. >> > So your bottom line is that anyone who disagrees with your perception of what tradeoffs > may be appropriate for security & privacy vs. performance, user convenience, etc. is > "just wrong." > > Nice to know it's that simple. > As I said, the tradeoffs are reasonably debatable. That's a two-edged sword. Keeping the debate going, rather than delivering real incremental progress, is the technique by which progress can most easily be delayed. And I believe that the currently deployed "tradeoff settings" have been definitively proven to be out of balance. We have a reality where vast amounts of information are undeniably being inappropriately obtained by intermediaries. It appears that we have a consensus on this list and in the IETF as a whole about this imbalance. I don't trust you. I don't even trust me all that much; I know I've made mistakes that weakened protocol security. But I hope we can make substantial improvements despite that. Perhaps you don't intend it this way, but it seems to me that much of your input (as well as a few others) on this list is of the denigrating, futility inducing sort of manipulation that has produced the current state of disarray. I'm not suggesting that you change anything. But I would like other readers to consider the tone of discussions here, and ask themselves what is really being said and why. Unlike denial of service attacks on networks, DoS attacks on motivation (deliberate, or merely driven by accumulated frustration from grappling for many years with an intractable problem) are rendered much less effective when recognized for what they are. Right now we need all the motivation we can get. Ted's personal metric for evaluating success is a good motivator. Sophistric decomposition with attacks reducing it to the absurd is demotivational. I'll confess that questioning of motives might well be seen as demotivational as well. I can only respond that lancing a boil hurts, but may allow the wound to heal faster. -- Dean --047d7b3a8b028106af04ea61a027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 4, 2013 1:18 PM, "Stephen Kent" <kent@bbn.com> wrote:
>
> Dean,
>>
>>
>> ...
>>
>>
>> But whether their opinions are honest or intentions malicious, the= y're just wrong.
>>
> So your bottom line is that anyone who disagrees with your perception = of what tradeoffs
> may be appropriate for security & privacy vs. performance, user co= nvenience, etc. is
> "just wrong."
>
> Nice to know it's that simple.
>

As I said, the tradeoffs are reasonably debatable.

That's a two-edged sword. Keeping the debate going, rath= er than delivering real incremental progress, is the technique by which pro= gress can most easily be delayed.

And I believe that the currently deployed "tradeoff set= tings" have been definitively proven to be out of balance. We have a r= eality where vast amounts of information are undeniably being inappropriate= ly obtained by intermediaries. It appears that we have a consensus on this = list and in the IETF as a whole about this imbalance.

I don't trust you. I don't even trust me all that mu= ch; I know I've made mistakes that weakened protocol security. But I ho= pe we can make substantial improvements despite that.

Perhaps you don't intend it this way, but it seems to me= that much of your input (as well as a few others) on this list is of the d= enigrating, futility inducing sort of manipulation that has produced the cu= rrent state of disarray. I'm not suggesting that you change anything. B= ut I would like other readers to consider the tone of discussions here, and= ask themselves what is really being said and why. Unlike denial of service= attacks on networks, DoS attacks on motivation (deliberate, or merely driv= en by accumulated frustration from grappling for many years with an intract= able problem) are rendered much less effective when recognized for what the= y are.

Right now we need all the motivation we can get. Ted's p= ersonal metric for evaluating success is a good motivator. Sophistric decom= position with attacks reducing it to the absurd is demotivational.

I'll confess that questioning of motives might well be s= een as demotivational as well. I can only respond that lancing a boil hurts= , but may allow the wound to heal faster.

--
Dean

--047d7b3a8b028106af04ea61a027-- From martin.thomson@gmail.com Mon Nov 4 14:58:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6D021E8056 for ; Mon, 4 Nov 2013 14:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmvYn-PHWLtF for ; Mon, 4 Nov 2013 14:58:44 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B621E81BC for ; Mon, 4 Nov 2013 14:58:44 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t60so2719596wes.2 for ; Mon, 04 Nov 2013 14:58:43 -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=cKFjBFYbQnz2SvKn74J9KRGMX6eQraqdu/H0qTor8gI=; b=CTMmXGKZLmRZujeykS+gPGPzBv3/l/5+0bkCMvb+R4xcP55S+qvEx0oyHU6BNENJbY Xy1LY8odWkkgsqy3vwHMu1wlti+SRtoeX4kJNHb7IE1/TGT9e+e78h06Cmes0EfZbaeM qXkQX/eAtnxNnWda55d7NDk9hBv2EqfYiPlQiF0d9oqMXtiifXNObhZwUqKNy5BmC3Rw JBpqNp/B7ssnCjNtEnTwCp+SKJ44sya282vbBvEEFAEwk+p174xgc4qmcystDUwmdVMI RwfaKaYJ6BH82joo5Bo1HddyM3qnf4hJC2Iw8UCYTvZvV7A7OqRdq419E2Rb/tFZvmMc mQ6Q== MIME-Version: 1.0 X-Received: by 10.194.178.166 with SMTP id cz6mr3659167wjc.53.1383605923307; Mon, 04 Nov 2013 14:58:43 -0800 (PST) Received: by 10.227.202.194 with HTTP; Mon, 4 Nov 2013 14:58:43 -0800 (PST) Received: by 10.227.202.194 with HTTP; Mon, 4 Nov 2013 14:58:43 -0800 (PST) Date: Mon, 4 Nov 2013 14:58:43 -0800 Message-ID: From: Martin Thomson To: perpass@ietf.org Content-Type: multipart/alternative; boundary=089e013d1a0c91662204ea61db7e Subject: [perpass] Statement X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:58:44 -0000 --089e013d1a0c91662204ea61db7e Content-Type: text/plain; charset=UTF-8 http://tools.ietf.org/html/draft-thomson-perpass-statement-00 --089e013d1a0c91662204ea61db7e Content-Type: text/html; charset=UTF-8

http://tools.ietf.org/html/draft-thomson-perpass-statement-00

--089e013d1a0c91662204ea61db7e-- From fergdawgster@mykolab.com Mon Nov 4 15:01:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541921E81BB for ; Mon, 4 Nov 2013 15:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPpEEtZ7XwZZ for ; Mon, 4 Nov 2013 15:01:45 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED10121E80E2 for ; Mon, 4 Nov 2013 15:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52782745.40703@mykolab.com> Date: Mon, 04 Nov 2013 15:01:25 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Statement X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fergdawgster@mykolab.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:01:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/2013 2:58 PM, Martin Thomson wrote: > http://tools.ietf.org/html/draft-thomson-perpass-statement-00 > > Yeah, I think that about sums it up. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSeCdBq1pz9mNUZTMRAtHtAKC8f2kukkMBLkfU+fjNpSfqX5MNJgCgtzrz dLVdPu1bxsX1DdH09YByAXg= =fNFm -----END PGP SIGNATURE----- -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From stephen.farrell@cs.tcd.ie Mon Nov 4 15:22:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA421E82AF for ; Mon, 4 Nov 2013 15:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF1QevgEqouf for ; Mon, 4 Nov 2013 15:22:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBF21E80EC for ; Mon, 4 Nov 2013 15:22:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 30E01BEC0; Mon, 4 Nov 2013 23:22:14 +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 oy+hnwZtYGLs; Mon, 4 Nov 2013 23:22:13 +0000 (GMT) Received: from [31.133.177.91] (dhcp-b15b.meeting.ietf.org [31.133.177.91]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82BE7BEBC; Mon, 4 Nov 2013 23:22:11 +0000 (GMT) Message-ID: <52782C20.50307@cs.tcd.ie> Date: Mon, 04 Nov 2013 23:22:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dean Willis References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277F29D.6040609@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:22:42 -0000 Dean, On 11/04/2013 10:42 PM, Dean Willis wrote: > Perhaps you don't intend it this way, but it seems to me that much of your > input (as well as a few others) on this list is of the denigrating, > futility inducing sort of manipulation that has produced the current state > of disarray. I don't think that's appropriate, being strikingly ad-hominem. Folks, please keep the discussion to technical issues. Thanks, S. From york@isoc.org Mon Nov 4 16:01:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314421E831C for ; Mon, 4 Nov 2013 16:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G2ULPPb636v for ; Mon, 4 Nov 2013 16:01:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id CC3A921E82E4 for ; Mon, 4 Nov 2013 16:01:01 -0800 (PST) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 5 Nov 2013 00:00:59 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.179]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.186]) with mapi id 15.00.0800.005; Tue, 5 Nov 2013 00:00:59 +0000 From: Dan York To: Cullen Jennings Thread-Topic: [perpass] Few things the IETF might standardize for secure collaboration Thread-Index: AQHOzlacSc2fViSZd0aFROWFnKAC4JoDRPYAgBIMdYA= Date: Tue, 5 Nov 2013 00:00:58 +0000 Message-ID: In-Reply-To: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(55674002)(24454002)(479174003)(377454003)(51704005)(189002)(199002)(31966008)(80022001)(47446002)(15202345003)(56816003)(36756003)(47976001)(65816001)(74662001)(74502001)(4396001)(76796001)(63696002)(77096001)(76786001)(2656002)(76176001)(83072001)(50986001)(19580395003)(81342001)(51856001)(80976001)(81542001)(46102001)(74366001)(15395725003)(15975445006)(69226001)(54316002)(77982001)(74706001)(49866001)(47736001)(79102001)(19580405001)(81816001)(74876001)(56776001)(561944002)(53806001)(85306002)(76482001)(59766001)(54356001)(87266001)(83322001)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <29F561DD53082047B38E1C0EDE07F55C@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "perpass@ietf.org" Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:01:37 -0000 Q3VsbGVuLA0KDQoNCklubGluZS4uLiAgKGFuZCBmaW5hbGx5IGdldHRpbmcgY2F1Z2h0IHVwIG9u IHBhc3QgY29udmVyc2F0aW9ucykNCg0KT24gMTAvMjQvMTMgMTI6MjMgQU0sICJDdWxsZW4gSmVu bmluZ3MiIDxmbHVmZnlAaWlpLmNhPiB3cm90ZToNCg0KPk5vIHF1ZXN0aW9uIHRoYXQgdGhpbmdz IGFyZSBnb2luZyB0aGUgcmlnaHQgZGlyZWN0aW9uLiBMZXQgZmlndXJlIG91dCBob3cNCj53ZSBj b3VsZCB1c2UgdGhpcyBhbmQgbGlrZWx5IHdoZW4uIEluIGZhaXJuZXNzIGl0IHdpbGwgdGFrZSB0 aW1lIHRvIGJ1aWxkDQo+c29tZXRoaW5nIGxpa2UgSSBhbSBwcm9wb3NpbmcgYW5kIEROU1NFQyB3 aWxsIGJlIGJldHRlciB0aGVuIHRoYW4gaXQgaXMNCj5ub3cuDQoNCkFjay4NCg0KPiANCj5Vc2lu ZyBEQU5FIGZvciBiZWx0IGFuZCBzdXNwZW5kZXJzIG9uIENBcyBzZWVtcyBnb29kLiBJIGFsc28g dGhpbmsgaXQNCj53b3VsZCBiZSB3ZWxsIHdvcnRoIHRoaW5rIGFib3V0IHdobyBpcyBpbiB0aGUg dHJ1c3QgY2hhaW4gZm9yIGEgZG9tYWluDQo+dGhhdCB3YXMgaW4gLnVzIHZzIHNheSAuY24gYW5k IGNvbnNpZGVyIGhvdyB0aGF0IG1pZ2h0IGFsbCBwbGF5IG91dCBmcm9tDQo+c2VjdXJpdHkgcG9p bnQgb2Ygdmlldy4gSSBoYWQgbm90IHRob3VnaHQgbXVjaCBhYm91dCB0aGlzIGJ1dCBpdCBkb2Vz DQo+ZGVzZXJ2ZSB0aGlua2luZyBhYm91dCB3aGF0IHdlIGNhbiBkby4NCg0KQWdyZWVkIHRoYXQg aXQncyB3b3J0aCB0aGlua2luZyBhYm91dCBob3cgdGhlIHRydXN0IGNoYWluIG1heSBiZSBkaWZm ZXJlbnQNCmZvciBkaWZmZXJlbnQgVExEcy4NCg0KPj4gDQo+PiBUeXBvOiBzbGlkZSA4IC0gSSB0 aGluayB5b3UgbWVhbnQgImluIHRoYXQgeW91IiAtICJUaGUgQ0EgaXMgImhvbmVzdCIgaXMNCj4+ IHRoYXQgeW91IGNhbiB0ZWxsIGlmIGl0IGlzc3VlcyB5b3VyIGNlcnRp76yBY2F0ZSB0byBzb21l b25lIGVsc2UgYnV0IHRoZXJlDQo+PiBpcyBubyB3YXkgdG8gc3RvcCBpdCBmcm9tIGRvaW5nIHRo YXQiDQo+DQo+b29wcyAtIHllcyAtIFRoZSB0eXBlIG9mIHRoaW5nIEkgd2FzIHRoaW5raW5nIGFi b3V0IGhlcmUgYXJlIHZhcmlvdXMNCj5wcm9wb3NhbCB3aGVyZSBDQSBwdWJsaXNoIGFsbCB0aGUg Y2VydGlmaWNhdGVzIHRoZXkgaGF2ZSBpc3N1ZWQgYW5kIHRoZXJlDQo+YXJlIHZhcmlvdXMgY3J5 cHRvZ3JhcGhpYyBoYXNoIGNoYWlucyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IGZvciB0aGVtIHRv DQo+bGllIGFib3V0IHRoaXMuIFRoYXQgbWVhbnMgYSBDQSBtaWdodCBiZSBhYmxlIHRvIGlzc3Vl IHlvdXIgY2VydCB0byBhIGJhZA0KPmd1eSBidXQgdGhhdCBpdCB3b3VsZCBsYXRlciBiZSBwb3Nz aWJsZSB0byBkZXRlY3QgdGhhdC4NCg0KQnV0IEkgd2FudCB0byBkZXRlY3QgdGhlIGJhZCBjZXJ0 ICpiZWZvcmUqIHNvbWVvbmUgZ29lcyB0byBhIHNpdGUgKG9yIGluDQp0aGUgcHJvY2VzcyBvZiBn b2luZyB0byBhIHNpdGUpLiAgSSBhZ3JlZSB0aGF0IHRoaXMgY2FwYWJpbGl0eSBvZiB0cmFja2lu Zw0KaXNzdWVkIGNlcnRzIHdvdWxkIGJlIFZFUlkgdXNlZnVsIGluIGRldGVjdGlvbiBvZiBjb21w cm9taXNlZCBjZXJ0cy4uLiBidXQNCnRoaXMgZG9lc24ndCBuZWNlc3NhcmlseSBzZWVtIHRvIG1l IHNvbWV0aGluZyB0aGF0IGNhbiB3b3JrIGluIHJlYWwtdGltZS4NCkl0IGNhbiBiZSBzb21ldGhp bmcgdXNlZCB0byBmaWd1cmUgb3V0IHdoYXQgaGFwcGVuZWQgYWZ0ZXItdGhlLWZhY3QuLi4gYnV0 DQppbiB0aGUgbWVhbnRpbWUgc29tZW9uZSBoYXMgYWxyZWFkeSBnb25lIHRvIHRvIHRoZSBiYWQg c2l0ZSB0aGF0IHRoZXkNCnRob3VnaHQgd2FzIGxlZ2l0Lg0KDQpUaGUgYWR2YW50YWdlIG9mIERO U1NFQy9EQU5FIGlzIHRoYXQgdGhlIGJvZ3VzIGNlcnQgY2FuIGJlIGRldGVjdGVkIGJlZm9yZQ0K c29tZW9uZSBhY3R1YWxseSBnb2VzIHRvIHRoZSBzaXRlLiAgSWYgdGhlIGZpbmdlcnByaW50IG9m IHRoZSBjZXJ0IHN0b3JlZA0KaW4gdGhlIFRMU0EgcmVjb3JkIChhbmQgc2lnbmVkIHdpdGggRE5T U0VDKSBkb2Vzbid0IG1hdGNoIHRoZSBmaW5nZXJwcmludA0Kb2YgdGhlIGNlcnQgYmVpbmcgb2Zm ZXJlZCBieSB0aGUgc2VydmVyLi4uIHRoZW4gdGhlIGFwcCBrbm93cyB0aGVyZSBpcyBhDQpwcm9i bGVtLg0KDQo+Pj5OZWFyIHRoZSBlbmQgaXMgYSBsaXN0IG9mIHRoaW5ncyB0aGF0IGl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgdGhlIElFVEYNCj4+PiBzdGFuZGFyZGl6ZWQuDQo+PiANCj4+IEdvb2Qg bGlzdCENCj4NCj5UZWxsIG1lIHdoYXQgdG8gYWRkIHRvIHRoaXMgbGlzdCBmb3IgRE5TU0VDIC8g REFORSB0aGF0IHdlIGFyZSBub3QNCj5hbHJlYWR5IGRvaW5nDQoNCkZvciBEQU5FLCBJIHRoaW5r IHdlJ3JlIGRvaW5nIHByZXR0eSB3ZWxsIHJpZ2h0IG5vdyB3aXRoIHdoYXQgaXMgZGVmaW5lZA0K aW4gUkZDIDY2OTggYW5kIHNvbWUgb2YgdGhlIG90aGVyIGRyYWZ0cy4gIFRoZXJlJ3MgYSBnb29k IGRvY3VtZW50IG91dCBpbg0KdGhlIERBTkUgd29ya2luZyBncm91cCB0aGF0IGlzIGFpbWluZyB0 byBjYXB0dXJlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ugb2YNCnVzaW5nIERBTkU6DQoNCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1a2hvdm5pLWRhbmUtb3BzLTAxDQoNCg0KSSdk IG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGluaXRpYWxseSBjYW1lIGFib3V0IGluIHRoZSBwcm9j ZXNzIG9mIG9uZSBvZg0KdGhlIGF1dGhvcnMgYWRkaW5nIERBTkUgc3VwcG9ydCB0byB0aGUgcG9z dGZpeCBlbWFpbCBzZXJ2ZXIuIChBbmQgdGhlDQphdXRob3JzIGFyZSBzZWVraW5nIGNvbW1lbnQg ZnJvbSBvdGhlciBpbXBsZW1lbnRvcnMuKQ0KDQpPbiB0aGUgRE5TU0VDIHNpZGUsIGFnYWluIEkg dGhpbmsgRE5TU0VDIGlzIHdlbGwtZGVmaW5lZCBpbiB0ZXJtcyBvZg0Kc3RhbmRhcmRzLi4uIHdo YXQgaXMgaGFwcGVuaW5nIG5vdywgcHJpbWFyaWx5IGluIEROU09QLCBpcyBsb29raW5nIGF0IGhv dw0Kd2Ugc3RhbmRhcmRpemUgYW5kIGF1dG9tYXRlIHNvbWUgYXNwZWN0cyBvZiB0aGUgRE5TU0VD IHByb3Zpc2lvbmluZw0KcHJvY2Vzcy4gIChGb3IgZXhhbXBsZSwgdG9tb3Jyb3cncyBETlNPUCBk aXNjdXNzaW9uIGFyb3VuZCBtZWNoYW5pc21zIHRvDQpmYWNpbGl0YXRlIGNvbW11bmljYXRpb24g b2YgbmV3IGtleSBtYXRlcmlhbCBmcm9tIGEgY2hpbGQgem9uZSB0byBhIHBhcmVudA0Kem9uZS4p ICANCg0KU28gSSBndWVzcyB3aGF0IHdlIG5lZWQgdG8gYWRkIHRvIHlvdXIgbGlzdCBmb3IgRE5T U0VDIC8gREFORSBpcyByZWFsbHkNCmRvY3VtZW50aW5nIChhbmQgcG90ZW50aWFsbHkgc3RhbmRh cmRpemluZyBpbiBzb21lIGNhc2VzKQ0Kb3BlcmF0aW9uYWwvZGVwbG95bWVudCBleHBlcmllbmNl IG9mIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBnZXQgdGhlDQpwcm90b2NvbHMgaW4gdXNlLg0K DQpEYW4NCg0KLS0NCkRhbiBZb3JrDQpTZW5pb3IgQ29udGVudCBTdHJhdGVnaXN0LCBJbnRlcm5l dCBTb2NpZXR5DQp5b3JrQGlzb2Mub3JnIDxtYWlsdG86eW9ya0Bpc29jLm9yZz4gICArMS04MDIt NzM1LTE2MjQNCkphYmJlcjogeW9ya0BqYWJiZXIuaXNvYy5vcmcgPG1haWx0bzp5b3JrQGphYmJl ci5pc29jLm9yZz4NClNreXBlOiBkYW55b3JrICAgaHR0cDovL3R3aXR0ZXIuY29tL2RhbnlvcmsN Cg0KaHR0cDovL3d3dy5pbnRlcm5ldHNvY2lldHkub3JnL2RlcGxveTM2MC8NCg0KDQoNCg== From dean.willis@softarmor.com Mon Nov 4 16:55:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B511E825B for ; Mon, 4 Nov 2013 16:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YPqOTEQj131 for ; Mon, 4 Nov 2013 16:55:47 -0800 (PST) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B538911E8263 for ; Mon, 4 Nov 2013 16:55:45 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id r7so2679954bkg.32 for ; Mon, 04 Nov 2013 16:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=I2OL3oKSYO5MM0oSIyeqpTQSUMXnoj2IDMxZHvjNDsg=; b=g1H/j5kfNRtUYt4P6Oy56/rPtrM7qpYc4DbUsxCUCU81+X/F6aR5+iPnIV77+GHwbS NQJoGySggIT2EtYKw+2iMCK/g4dGk4VTu6xuIwjMKwnGyB0Yf+BSNeD0tGCcdhDizFTs hSOKGkBBYXLxH8WcvRFTK/yx7cHo4jxzqqW5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=I2OL3oKSYO5MM0oSIyeqpTQSUMXnoj2IDMxZHvjNDsg=; b=KZ9OUqiPalFc0frQ2Qbp1ufecKNPAC/w/psvTj0cY+wXZlsOmNFn0/6/XQO9L4wBwH Tu3LOzncnGrlxbG5gPtDqK052cS9AU0P/kumDuXu+WgDH6MNa7HEkFxLbQSikTB+SqBe svDWrcmhuNtx10tC4rSqKVgXE+VMQKtid9EZtk/hvzk1HFxCjKwwd3FSHbLI8lhOBmCG fEU35pTThm4+SEHU0gamKPKozdOxxgO5culpuP8N3woeQxkECYndqTqfuVRNki3N6LsU VWcw7vys3NMi7BGNhgxoO9RZcI9xeyPHRxHe+tzSWnCFC2ZX2L/D4b1VHcW5QLos7MM5 DDGA== X-Gm-Message-State: ALoCoQmbn/eFform0hLtsdV3DWh62hZSZeDp1J3H/wFhe5N6lc5i1XniJGekPh0VB2EbZSYwY5X6 X-Received: by 10.205.71.193 with SMTP id yl1mr8015bkb.45.1383612944550; Mon, 04 Nov 2013 16:55:44 -0800 (PST) Received: from wireless-1x-v6.meeting.ietf.org ([2001:67c:370:168:7892:c371:f322:38fa]) by mx.google.com with ESMTPSA id ny10sm17265140bkb.17.2013.11.04.16.55.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 16:55:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D955D033-8C82-4B68-B921-B32E1AC36268" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dean Willis In-Reply-To: <52782C20.50307@cs.tcd.ie> Date: Mon, 4 Nov 2013 18:55:40 -0600 Message-Id: References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277F29D.6040609@bbn.com> <52782C20.50307@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1816) Cc: perpass Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:55:48 -0000 --Apple-Mail=_D955D033-8C82-4B68-B921-B32E1AC36268 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 4, 2013, at 5:22 PM, Stephen Farrell = wrote: >=20 > Dean, >=20 > On 11/04/2013 10:42 PM, Dean Willis wrote: >=20 >> Perhaps you don't intend it this way, but it seems to me that much of = your >> input (as well as a few others) on this list is of the denigrating, >> futility inducing sort of manipulation that has produced the current = state >> of disarray.=20 >=20 > I don't think that's appropriate, being strikingly ad-hominem. >=20 > Folks, please keep the discussion to technical issues. >=20 > Thanks, > S. That=92s not ad-hominen. I=92m not saying there=92s something wrong with = the given message BECAUSE of some other defect of the author. http://en.wikipedia.org/wiki/Ad_hominem If I=92d said =93Your argument is invalid because you=92re a communist, = and everybody knows communists don=92t know anything about bananas=94, = that would be an ad-hominem attack. Rather, I=92m saying that I don=92t like the tone of the message itself. = It=92s loaded with negativity that I find disruptive to the work = process. This may be entirely unintentional, in which case pointing it = out might help. It might be intentional, which would lead me to suspect = that there might be some other defect of the author that is causative of = the behavior in question. Now, if I just straight out asked =93Why are you being so negative?=94, = that would be a loaded question. http://en.wikipedia.org/wiki/Loaded_question And properly categorizing insults is definitely a technical issue. =97 Dean= --Apple-Mail=_D955D033-8C82-4B68-B921-B32E1AC36268 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


On Nov 4, = 2013, at 5:22 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:


Dean,

On 11/04/2013 10:42 PM, Dean Willis = wrote:

Perhaps you don't intend it this = way, but it seems to me that much of your
input (as well as a few = others) on this list is of the denigrating,
futility inducing sort of = manipulation that has produced the current state
of disarray. =

I don't think that's appropriate, being strikingly = ad-hominem.

Folks, please keep the discussion to technical = issues.

Thanks,
S.

That=92s not ad-hominen. I=92m not saying there=92s = something wrong with the given message BECAUSE of some other defect of = the author.



If I=92d said =93Your = argument is invalid because you=92re a communist, and everybody knows = communists don=92t know anything about bananas=94, that would be an = ad-hominem attack.


Rather, I=92m = saying that I don=92t like the tone of the message itself. It=92s loaded = with negativity that I find disruptive to the work process. This may be = entirely unintentional, in which case pointing it out might help. It = might be intentional, which would lead me to suspect that there might be = some other defect of the author that is causative of the behavior in = question.

Now, if I just straight out asked = =93Why are you being so negative?=94, that would be a loaded = question.


And properly = categorizing insults is definitely a technical = issue.

=97
Dean
= --Apple-Mail=_D955D033-8C82-4B68-B921-B32E1AC36268-- From rutkowski.tony@gmail.com Mon Nov 4 18:46:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956921E839D for ; Mon, 4 Nov 2013 18:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsCRNtc9v4uj for ; Mon, 4 Nov 2013 18:46:04 -0800 (PST) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id D6D4021E83A7 for ; Mon, 4 Nov 2013 18:46:02 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id a11so4669975qen.36 for ; Mon, 04 Nov 2013 18:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=emxSkMbWz3qb2Pi/ulhxpqJ33a/yQU/Jpq1iFI846J0=; b=HRbMABE8iKM6mpZwqs3bkU2rGW8FY3LozHFQ1pcNMUpjBpzwqtpj2x921LtuY66dTm I2npsayLAhLUM5qh9SbVU9wsHM3V/9xIzTCDMfWFR2yEm4U265sWYxYPRPt8iYHF/Rkr O5X7/37BiRp3E3uytVO7QNBpkOFaeK5s0j2MbFYrr7pklU7kWklN5Pmiu3V5dsvJXOQN c/22S0tZ1tnWTm9Y5sXvgby4tCmkG4yaWa0c6jGCDf34uQnxtp+snUL+3h5LmRBPjAZX L7ejfEhsEbm98lhaDzhq7PxyqG/+955HIBZeuHWYW4g3GHLva4TKDSO8CRIf1UPFES87 D2OQ== X-Received: by 10.224.32.66 with SMTP id b2mr26824396qad.80.1383619562291; Mon, 04 Nov 2013 18:46:02 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id k2sm62011609qan.8.2013.11.04.18.46.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:46:01 -0800 (PST) Message-ID: <52785BE8.1060506@gmail.com> Date: Mon, 04 Nov 2013 21:46:00 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dean Willis , Stephen Farrell References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277F29D.6040609@bbn.com> <52782C20.50307@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: perpass Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:46:07 -0000 I would like to support Dean's ability to express his views here. This list seems to have from the outset been as much about catharsis than technology. The IETF has had a long history along these lines. Occasionally useful things happen. A certain amount of amusement also helps deal with the frictions engendered by the obvious considerable disparity of perspectives and views. --tony On 11/4/2013 7:55 PM, Dean Willis wrote: > Rather, I’m saying that I don’t like the tone of the message itself. > It’s loaded with negativity that I find disruptive to the work > process. This may be entirely unintentional, in which case pointing it > out might help. It might be intentional, which would lead me to > suspect that there might be some other defect of the author that is > causative of the behavior in question. > From hallam@gmail.com Mon Nov 4 23:08:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFE011E822C for ; Mon, 4 Nov 2013 23:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPa1smSefC7O for ; Mon, 4 Nov 2013 23:08:32 -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 4966311E8197 for ; Mon, 4 Nov 2013 23:07:28 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id y6so6164799lbh.39 for ; Mon, 04 Nov 2013 23:07: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:date:message-id:subject:from:to :cc:content-type; bh=qLAbac24vV4iIQA6Vk8b9Bu7+JwuLVkpPCRt+s3ZvpA=; b=AQ7A2hJORySYgAPmm+JXCQQ5tjmCWYi+mgP4uwXymqytyUMgZ4k58KkLzaDVrhW2O+ HPeOeww3nqkAZ4+TVTUh1+8D5iHXJtoQflMjuPmW4ogRwqM3vMeE6XDVPY+OQyax8OiK rHeIvZ7IjXUIY3osOHyT2oENNiM88sXxJkIn7AMJB4d/F72d4FSDtKPJgGsS2vRgziWq 8KggEcdNEI7y51Pk3fVaSIHgU0ZOmZh7Eo+uqkTB3P/o4SGjm4mtAzID9xrqYhUYSRAb BPI2KHoxgfvjKPSNfHq89L/F2vxHwhqlGM7ORhtGJ9rFTJoW8AcW9lfIsb/LjBK5FTBU 8ggQ== MIME-Version: 1.0 X-Received: by 10.152.36.170 with SMTP id r10mr16455laj.48.1383635246915; Mon, 04 Nov 2013 23:07:26 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 4 Nov 2013 23:07:26 -0800 (PST) In-Reply-To: <603E5585-3320-4CF8-A87E-B68F89C98930@isoc.org> References: <603E5585-3320-4CF8-A87E-B68F89C98930@isoc.org> Date: Tue, 5 Nov 2013 02:07:26 -0500 Message-ID: From: Phillip Hallam-Baker To: Robin Wilton Content-Type: multipart/alternative; boundary=089e0160bb046426bc04ea68af74 Cc: perpass , Stephen Kent , Dean Willis Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 07:08:35 -0000 --089e0160bb046426bc04ea68af74 Content-Type: text/plain; charset=ISO-8859-1 People seem to have missed my actual points which were that 1) We have to accept the fact that people are going to be suspicious of standards proposals and make sure that 'trust us' is not baked in. That includes specs that assume one of the i-* entities is going to be trustworthy in perpetuity. 2) People who take offense at the fact that they are under suspicion are now in the wrong business. Being in the CA business I have always had to justify the trust vested in my employer as a trusted third party, anyone who takes offense when being asked why they should be considered trustworthy should not be in the trusted third party business. 3) Yes it sucks, blame those idiot colonels whose crappy tradecraft led them to write hundreds of powerpoint slides boasting about them and leave them all on a sharepoint server administered by a 29 year old contractor whose girlfriend worked as a stripper. I do not think pervasive suspicion is really acceptable in the IETF culture at present. Well not unless the target is a CA. We also have a big problem in that there are two ways that an NSA contractor can sabotage a standard. One is to obstruct changes to make a standard secure, the other is to insist on ludicrous security requirements that ensure nobody will use the security. On the implementation side, yes, implementation errors whether fortuitous or deliberate are much more likely to be the source of insecurity than protocol errors. The number of developers is much larger than the number of designers. I get rather fed up of people who work for software vendors that patch a dozen serious security bugs every month putting up slides that ignore their own security problem but are sure to raise the DigiNotar issue. --089e0160bb046426bc04ea68af74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
People seem to have missed my actual points which were tha= t

1) We have to accept the fact that people are going to= be suspicious of standards proposals and make sure that 'trust us'= is not baked in. That includes specs that assume one of the i-* entities i= s going to be trustworthy in perpetuity.

2) People who take offense at the fact that they are un= der suspicion are now in the wrong business. Being in the CA business I hav= e always had to justify the trust vested in my employer as a trusted third = party, anyone who takes offense when being asked why they should be conside= red trustworthy should not be in the trusted third party business.

3) Yes it sucks, blame those idiot colonels whose crapp= y tradecraft led them to write hundreds of powerpoint slides boasting about= them and leave them all on a sharepoint server administered by a 29 year o= ld contractor whose girlfriend worked as a stripper.


I do not think pervasive suspicion is re= ally acceptable in the IETF culture at present. Well not unless the target = is a CA.

We also have a big problem in that there = are two ways that an NSA contractor can sabotage a standard. One is to obst= ruct changes to make a standard secure, the other is to insist on ludicrous= security requirements that ensure nobody will use the security.


On the implementation side, yes, impleme= ntation errors whether fortuitous or deliberate are much more likely to be = the source of insecurity than protocol errors. The number of developers is = much larger than the number of designers.=A0

I get rather fed up of people who work for software ven= dors that patch a dozen serious security bugs every month putting up slides= that ignore their own security problem but are sure to raise the DigiNotar= issue.

--089e0160bb046426bc04ea68af74-- From hannes.tschofenig@gmx.net Tue Nov 5 00:42:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59311E824E for ; Tue, 5 Nov 2013 00:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5OR+4gVmgRp for ; Tue, 5 Nov 2013 00:42:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id A1E1B21E80AB for ; Tue, 5 Nov 2013 00:42:23 -0800 (PST) Received: from Masham-MAC.local ([91.179.228.44]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ln8Tl-1W7SFv0zJF-00hQH4 for ; Tue, 05 Nov 2013 09:42:22 +0100 Message-ID: <5278AF67.1000704@gmx.net> Date: Tue, 05 Nov 2013 09:42:15 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Colin Perkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W8i7cem7Sz7rcHnNluH/40iZv0DNgQ7B9Kor58fksF2v7UMS+KC y5XJoEgppF3/yZeYkre3t4klJxvL9xrvkiSA0rwbd4ZCQkWKYIokGVGtQ5WPkePgvy9k6Ze BLGUutVdmSP5znmPdXU6OJsiLjOpdGDIkq2A4USNqJElS8wSMx7gqOZbDzMM58oYI1nCrDC 2jbxILag3VbdgnoWC6/gA== Cc: draft-ietf-avtcore-rtp-security-options@tools.ietf.org, Richard Barnes , perpass@ietf.org, avt@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, hannes.tschofenig@gmx.net Subject: Re: [perpass] [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 08:42:30 -0000 Hi Colin, I came across this document before and I was really wondering whether this is the best story the IETF can come up with. The argument that RTP is used in a number of different environments, as a basis for not offering a solid security story is rather weak. The same could be said about many other protocols the IETF develops, even about TLS itself. Have a look at TLS to see an alternative path that one could go instead. It mandates a certain ciphersuite and adds the following qualification: " Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). " If there are deployments or standardization organizations believe that they do not require security (because it just runs within their own "secure" network* or because it requires a different solution solution, like the 3GPP that allows lawful intercept) then that is not a good reason for the IETF not mandating something. I am wondering what motivated you write the document in this specific style. I believe I understand the motivation for Magnus. Ciao Hannes (*): As we have recently learned these assumptions may well be wrong, see: http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html Am 03.11.13 17:00, schrieb Colin Perkins: > On 2 Nov 2013, at 17:12, Richard Barnes > > wrote: >> On draft-ietf-avt-srtp-not-mandatory: >> I have reviewed this draft in preparation for IETF Last Call and IESG >> processing. Clearly, this is not the best moment in history to be >> making this sort of argument, given the increased focus on . However, >> I think this document makes the case pretty clearly. It helps to have >> draft-ietf-avtcore-rtp-security-options as a positive statement to go >> alongside this document. > > Note that the srtp-not-mandatory draft is explicitly not saying "strong > security is not mandatory", rather it's saying that "strong security is > mandatory, but the appropriate way of providing it depends on the > context, and SRTP is not always the answer". > >> On draft-ietf-avtcore-rtp-security-options: >> I have reviewed this draft in preparation for IETF Last Call and IESG >> processing. One question to discuss briefly before IETF LC: My major >> concern is that it seems like there's a lot of old stuff in here. Has >> the WG considered explicitly marking each of the mechanisms with some >> sort of recommendation level? I would like to avoid having someone >> choose SDES in a case where they could use DTLS-SRTP, for example. > > Such recommendations would be very helpful, but depend on the scenario. > Section 5 gives some pointers, but really we need security architecture > drafts for particular use cases of RTP (like the WebRTC security arch, > for example). > > Colin > > > > >> If the authors could follow up on that one point, we should be able to >> get these both into LC soon. >> >> Thanks, >> --Richard >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From hallam@gmail.com Tue Nov 5 07:02:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8979311E8294 for ; Tue, 5 Nov 2013 07:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y-5DaTg665D for ; Tue, 5 Nov 2013 07:02:00 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E812011E810F for ; Tue, 5 Nov 2013 07:01:59 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id q8so6663508lbi.33 for ; Tue, 05 Nov 2013 07:01:58 -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=QFJmD4aEe3IusPeuQZklA22Si5Yb3yTM/8x1u9UWtkk=; b=uxv+XTcn67hwqwzg5NsIWrptdZc4oJ6x1FR3tJ3mnh/uGpXQyo3/YVJTTQedD+VaS3 b2T4M22hVpfp7uqqKdh4KrmJXI6e6W312tV0w359Xkz/MG6BWxGRqcd/OLF0XEp625Mm ZTS1C0Zk9LWjTgjm9yUKvFfvv8MUo/6ZsES44icJWZFME2zjelF9LTKeah9ZAJ/5stnr k5/wvABNIJwmEEljS6BY6NBJbtEtVxcurJg7fg8GMCZ/kNloCPA8zU1lWLTEfKjmvN7z 4BSawmX0L5K0u/FwywF1dDqgLdUDhsQBNjo/0D370aOfEZTCLazlTok3d5IkinEn9978 mfSg== MIME-Version: 1.0 X-Received: by 10.112.236.97 with SMTP id ut1mr6079450lbc.37.1383663718634; Tue, 05 Nov 2013 07:01:58 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 5 Nov 2013 07:01:58 -0800 (PST) Date: Tue, 5 Nov 2013 10:01:58 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c318f6701b2304ea6f50ef Subject: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:02:01 -0000 --001a11c318f6701b2304ea6f50ef Content-Type: text/plain; charset=ISO-8859-1 One of the handicaps we are working under is that the IETF is historically the ARPANET 'End to End' working group and we define the Internet stack from the IP layer up. Some problems can't be addressed at the IP layer, in particular it is impossible to address traffic analysis efficiently or pervasively. Tor is very good at what it does but Tor can't support three billion users doing streaming video under any imaginable circumstances. A much better option would be to tell every network vendor that they have to build full speed encryption/decryption capability into every link adapter and exchange encrypted data all the time the fiber is lit. The protocol for establishing the link layer encryption need not be very fancy. It arguably does not even need to be proof against a man in the middle attack since any man in the middle is going to be forced to drink the whole fire hose. There are devices for encrypting OC-768 40Gbit links today. But they are niche products made for NSA use (now where does all that data come from??). AES in standard cell does not add a huge number of gates to a circuit. Vendors need to be trained to believe that they have to add it to every chip or won't be able to sell the product. On circuit encryption is potentially much better against traffic analysis in any case since if you bolt a hardware encryptor onto a link and feed it data, it is likely that the timing of bits at least provides hints for a timing attack. Such a scheme would be in no way a replacement for end-to-end encryption. And there would be an issue of collusion with the carriers and governments. But reducing the attack surface from every government who can rent a back hoe to one government with a subpoena is very powerful. And forcing the intelligence agencies to collude to perform traffic analysis would further limit capabilities. The payoff for this effort is a major increase in work factor and in particular, forcing an adversary attempting a traffic analysis attack to intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of data to store. It is over an exabyte per link per year. Or about a quarter million 4Tb hard drives. Or $200 million at $500 per drive (including racking etc.) And that is per link. The NSA budget is in the tens of billions a year. So we can eat up the whole pie by encrypting 50-500 links. Or the entire military budget would be 5,000 links. The only feasible attack would be to suborn the fab. But I expect that there will be a presidential executive order prohibiting that type of sabotage under the next President recognizing the fact that the cost of such activities in terms of damage to trust in international commerce is vastly greater than the benefit to the boasting generals careers. 40Gb/sec is not a vast quantity of data to encrypt with hardware support. Not for a device that is all custom VLSI anyway by its very nature. If the fiber is lit it is going to take the same power whether it sends all zeros or a mixture of ones and zeros. There would be a small degree of additional complexity introduced by the need to conceal the sizes of the underlying packets. It would not be a perfect defense against every attack and there is still the possibility that the attacker would persuade data to be sent over unencrypted links and such. But it would establish a gratifying increase in work factor which is the objective here. -- Website: http://hallambaker.com/ --001a11c318f6701b2304ea6f50ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

One of the handicaps we are working un= der is that the IETF is historically the ARPANET 'End to End' worki= ng group and we define the Internet stack from the IP layer up.

Some problems can't be addressed at the IP layer, in par= ticular it is impossible to address traffic analysis efficiently or pervasi= vely. Tor is very good at what it does but Tor can't support three bill= ion users doing streaming video under any imaginable circumstances.

A much better option would be to tell every network ven= dor that they have to build full speed encryption/decryption capability int= o every link adapter and exchange encrypted data all the time the fiber is = lit. The protocol for establishing the link layer encryption need not be ve= ry fancy. It arguably does not even need to be proof against a man in the m= iddle attack since any man in the middle is going to be forced to drink the= whole fire hose.

There are devices for encrypting OC-768 40Gbit links to= day. But they are niche products made for NSA use (now where does all that = data come from??). AES in standard cell does not add a huge number of gates= to a circuit. Vendors need to be trained to believe that they have to add = it to every chip or won't be able to sell the product.

On circuit encryption is potentially much better agains= t traffic analysis in any case since if you bolt a hardware encryptor onto = a link and feed it data, it is likely that the timing of bits at least prov= ides hints for a timing attack.

Such a scheme would be in no way a replacement for end-= to-end encryption. And there would be an issue of collusion with the carrie= rs and governments. But reducing the attack surface from every government w= ho can rent a back hoe to one government with a subpoena is very powerful. = And forcing the intelligence agencies to collude to perform traffic analysi= s would further limit capabilities.

The payoff for this effort is a major increase in work = factor and in particular, forcing an adversary attempting a traffic analysi= s attack to intercept and decrypt multiple fire hoses. 40Gb/sec is quite a = lot of data to store. It is over an exabyte per link per year. Or about a q= uarter million 4Tb hard drives. Or $200 million at $500 per drive (includin= g racking etc.)

And that is per link.

The NSA = budget is in the tens of billions a year. So we can eat up the whole pie by= encrypting 50-500 links. Or the entire military budget would be 5,000 link= s. The only feasible attack would be to suborn the fab. But I expect that t= here will be a presidential executive order prohibiting that type of sabota= ge under the next President recognizing the fact that the cost of such acti= vities in terms of damage to trust in international commerce is vastly grea= ter than the benefit to the boasting generals careers.=A0


40Gb/sec is not a vast quantity of data = to encrypt with hardware support. Not for a device that is all custom VLSI = anyway by its very nature. If the fiber is lit it is going to take the same= power whether it sends all zeros or a mixture of ones and zeros.=A0

There would be a small degree of additional complexity = introduced by the need to conceal the sizes of the underlying packets.


It would not be a perfect defense against ev= ery attack and there is still the possibility that the attacker would persu= ade data to be sent over unencrypted links and such. But it would establish= a gratifying increase in work factor which is the objective here.

--
Website: http://h= allambaker.com/
--001a11c318f6701b2304ea6f50ef-- From sxpert@sxpert.org Tue Nov 5 07:09:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E726411E826B for ; Tue, 5 Nov 2013 07:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgwqRPMGJB9H for ; Tue, 5 Nov 2013 07:09:57 -0800 (PST) Received: from pigeon.sxpert.org (flumotion.sxpert.org [IPv6:2001:67c:2200:3801::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9707311E82C0 for ; Tue, 5 Nov 2013 07:09:32 -0800 (PST) Received: by pigeon.sxpert.org (Postfix, from userid 33) id 07D771FF63; Tue, 5 Nov 2013 16:09:16 +0100 (CET) To: perpass@ietf.org X-PHP-Originating-Script: 0:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 05 Nov 2013 16:09:16 +0100 From: =?UTF-8?Q?Rapha=C3=ABl_Jacquot?= In-Reply-To: References: Message-ID: X-Sender: sxpert@sxpert.org User-Agent: Roundcube Webmail/0.9.5 Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:09:58 -0000 On 05.11.2013 16:01, Phillip Hallam-Baker wrote: > There would be a small degree of additional complexity introduced by > the need to conceal the sizes of the underlying packets. not really. sending no packets accross an encrypted link ends up sending tons of encrypted 0 bits during the time when there's no packet to send you end up transmitting "line noise" 100% of the time. From martin@millnert.se Tue Nov 5 07:30:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3821F9E37 for ; Tue, 5 Nov 2013 07:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkny67Jo0wQt for ; Tue, 5 Nov 2013 07:30:29 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id A500211E8108 for ; Tue, 5 Nov 2013 07:30:24 -0800 (PST) Received: from [172.25.90.101] (gw.ipnett.ideon.se [85.235.1.171]) by mail.millnert.se (Postfix) with ESMTPSA id 6C52BA6; Tue, 5 Nov 2013 16:32:35 +0100 (CET) Message-ID: <1383665417.5165.51.camel@galileo.millnert.se> From: Martin Millnert To: Phillip Hallam-Baker Date: Tue, 05 Nov 2013 16:30:17 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WZ98oziqiLNiYAobm8bu" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:30:35 -0000 --=-WZ98oziqiLNiYAobm8bu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Phillip, On Tue, 2013-11-05 at 10:01 -0500, Phillip Hallam-Baker wrote: >=20 >=20 > One of the handicaps we are working under is that the IETF is > historically the ARPANET 'End to End' working group and we define the > Internet stack from the IP layer up. >=20 >=20 > Some problems can't be addressed at the IP layer, in particular it is > impossible to address traffic analysis efficiently or pervasively. Tor > is very good at what it does but Tor can't support three billion users > doing streaming video under any imaginable circumstances. >=20 >=20 > A much better option would be to tell every network vendor that they > have to build full speed encryption/decryption capability into every > link adapter and exchange encrypted data all the time the fiber is > lit. The protocol for establishing the link layer encryption need not > be very fancy. It arguably does not even need to be proof against a > man in the middle attack since any man in the middle is going to be > forced to drink the whole fire hose. there are vendors selling transponder type bitstream encrypters. It's relatively easy to apply bitstream crypto at the bitstream layer, as I understand it. (How this holds for 100G serial stream, I don't know. Many 100G transceivers utilize 4x25G or 10x10G serialisation and muxing techniques, and how encryption/keying/timing would work here I'm not sure...) I would be very vary of proprietary encryption protocols however. Interoperable and openly standardized (though not bastardized), AES-type encryption would provide some safety. Key management, obviously is an issue, as well. Otherwise, I've been talking about this myself. At the optical transceiver level, it would be relatively straightforward to insert a crypt/decrypt layer. =20 Technical difficulties are to manage this on highspeed links, where integrated DWDM transceivers are using all available, or more, of the power budget of the various transceiver form factors. The further away from the core you are, the cheaper it will be to do crypt/decrypt. OTOH, core links have more paying customers behind them, so the economics are different here. Router-to-router encryption would... definitely help. =20 My 2c. /M --=-WZ98oziqiLNiYAobm8bu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJSeQ8JAAoJEKgraNdZrwxMzpoP/jtlQDq3Ok2HtX/M+KD8uuvT exaN6ZXIUak505Y2+vJPLCMl+mq/brFmyPqXMB1QJVIf9Dksa9C4rAW2G/0//J2L B1B2Yjk/p7iLqkCfrZWptZRtwnPbFnfZTl3wi21fgar0b7LbRpJ75611FlYGRJG2 yUdh3nzq6YFMCr7kUH5T84iejeTZnxLVDgXs6yHGtDiq0HrMT4YXEAuWNr1uvnJQ SpXAF8MWBaQB2YAdWHsijn8sasatYKS0MyrbKK/Hd4roKCBNbYhX6R/hvIu/ErIE L2QQKB55iRdG5Jn+X/EuxFEnJ6ImyeBXE1c2Pl0JxkKy1Y3IaiFUaTjjeQSKvzox W4JbgkUMz3llX99JTiPFlLTGkmgAekWtfZ2XYbYyFMJOsOYTBPjEc5wd5xPnOC/z +xHQFOawnRqwL33Y9zI/f50OaEkcF8vl1MR5QX0B/ggzpwPcn7ORA2nPUQMWeEfD 6bhYxggplDPITv07Jzygw65iWZiWWht3iVxgVu0JdTpSisS28eDeH/pevG/6PwTo d2QaC1467yl8z+RIazlz6xIhBgFrlFKOKz6Dc9NwGcJgFgldPGT0TeAWLSM8chZE sauG9GVvHd0Cj30onrZWZhnuTtd8iceyAhwlhj6DciQlFKj8+IUDBMo1jcw4gw2X 60fnuuf783vY/Z5xKxQE =5bxK -----END PGP SIGNATURE----- --=-WZ98oziqiLNiYAobm8bu-- From rutkowski.tony@gmail.com Tue Nov 5 07:36:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360221F9EE1 for ; Tue, 5 Nov 2013 07:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FtSdV8Is1bF for ; Tue, 5 Nov 2013 07:36:42 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECC21F9DA0 for ; Tue, 5 Nov 2013 07:36:41 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id s19so4781366qcw.7 for ; Tue, 05 Nov 2013 07:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=21ju6qI3TWMCjSc06ZlXvy85aQe/j9XBIIkU6kE7efY=; b=lJB7iTuX8XtjGCVA/g9K4sZoDjAl9955do25HG2QW4k5Evn30n8QZxN5WNG4X6MjLL jvqfYNOtx4XIWaZpHny1NmY/d/AccbLHzPZ4NVGg4DwhbgL4O9+Z7589Y0awrQ98LIL7 k+LzdtKtMJTreuPJGI4ti5RRqPOO5cqn+O2ol8p9VgBiEDpzyQCYNk8ocm5bjQF4505l flm5eiPWFZ0SbYdYjfD0S+gtXAIbyJrQHpAOW9sFGXib7sOmD5zhXPIrxL5a0m1wJ9nL PA4j6n5rpCSOJ6lZuZJsVplw1sJoXA9gi5+iIIDJPdFCWj9UQqlVdTOGehaNt+rbpNPt Ez1w== X-Received: by 10.224.12.207 with SMTP id y15mr10332244qay.101.1383665801520; Tue, 05 Nov 2013 07:36:41 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id a5sm68223066qae.2.2013.11.05.07.36.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:36:40 -0800 (PST) Message-ID: <52791087.1030803@gmail.com> Date: Tue, 05 Nov 2013 10:36:39 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , perpass References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:36:46 -0000 Hi Phill, And just how does one get from Phill and friends in perpass talking about clever schemes, to "forcing" all the governments, vendors, and providers of the world to implement those schemes? That seems like a rather large and important step to be asserting as part of your technical(?) plan! :-) You do realize that ironically at this very moment, there are ITU-T meetings occurring where some of those actors are collaborating on doing the opposite. In fact, if you examine the appendix to the original submitted Rec. Y.2770, you'll see about 34 use cases for the commercial benefits of pervasive surveillance. And, that doesn't include government use cases. One of the unintended consequences of the past couple months of exposing stolen UK and US documents is that the budgets and stature of the services of a great many other countries became substantially increased, and the providers/vendors will be subject to more extensive pervasive surveillance requirements. It's funny how the real world works. best, tony On 11/5/2013 10:01 AM, Phillip Hallam-Baker wrote: > And there would be an issue of collusion with the carriers and > governments. But reducing the attack surface from every government who > can rent a back hoe to one government with a subpoena is very > powerful. And forcing the intelligence agencies to collude to perform > traffic analysis would further limit capabilities. > From csp@csperkins.org Tue Nov 5 08:02:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D495421E811C; Tue, 5 Nov 2013 08:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoG8z5sNJnMY; Tue, 5 Nov 2013 08:02:30 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A3C11E82EE; Tue, 5 Nov 2013 08:01:52 -0800 (PST) Received: from [207.194.238.3] (port=65530 helo=[198.18.18.248]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Vdj4a-0007EZ-PZ; Tue, 05 Nov 2013 16:01:46 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <5278AF67.1000704@gmx.net> Date: Tue, 5 Nov 2013 08:01:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4CCEDF41-F28D-4F67-95B1-AE7E6765B61E@csperkins.org> References: <5278AF67.1000704@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: Richard Barnes , perpass@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-rtp-security-options@tools.ietf.org Subject: Re: [perpass] [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:02:33 -0000 Hannes, The goal of the draft is not to justify a lack of strong security. It is = to explain why SRTP is not an appropriate mechanism for providing strong = security for all use cases of RTP, and highlight that some scenarios = need alternative strong security mechanisms. The rtp-security-options = draft talks about what those options might be. If there are sections in = the draft that don't make that clear, please let me know, and we can try = to improve the text.=20 The draft says nothing about the cipher suites to be used. Both SRTP and = the other security options mandate strong cipher suites, and there are = no proposals to change that. Colin On 5 Nov 2013, at 00:42, Hannes Tschofenig = wrote: > Hi Colin, >=20 > I came across this document before and I was really wondering whether = this is the best story the IETF can come up with. >=20 > The argument that RTP is used in a number of different environments, = as a basis for not offering a solid security story is rather weak. The = same could be said about many other protocols the IETF develops, even = about TLS itself. >=20 > Have a look at TLS to see an alternative path that one could go = instead. It mandates a certain ciphersuite and adds the following = qualification: >=20 > " > Mandatory Cipher Suites >=20 > In the absence of an application profile standard specifying > otherwise, a TLS-compliant application MUST implement the cipher > suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the > definition). > " >=20 > If there are deployments or standardization organizations believe that = they do not require security (because it just runs within their own = "secure" network* or because it requires a different solution solution, = like the 3GPP that allows lawful intercept) then that is not a good = reason for the IETF not mandating something. >=20 > I am wondering what motivated you write the document in this specific = style. I believe I understand the motivation for Magnus. >=20 > Ciao > Hannes >=20 > (*): As we have recently learned these assumptions may well be wrong, = see: = http://www.washingtonpost.com/world/national-security/nsa-infiltrates-link= s-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/= e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html=20 >=20 > Am 03.11.13 17:00, schrieb Colin Perkins: >> On 2 Nov 2013, at 17:12, Richard Barnes > >> wrote: >>> On draft-ietf-avt-srtp-not-mandatory: >>> I have reviewed this draft in preparation for IETF Last Call and = IESG >>> processing. Clearly, this is not the best moment in history to be >>> making this sort of argument, given the increased focus on . = However, >>> I think this document makes the case pretty clearly. It helps to = have >>> draft-ietf-avtcore-rtp-security-options as a positive statement to = go >>> alongside this document. >>=20 >> Note that the srtp-not-mandatory draft is explicitly not saying = "strong >> security is not mandatory", rather it's saying that "strong security = is >> mandatory, but the appropriate way of providing it depends on the >> context, and SRTP is not always the answer". >>=20 >>> On draft-ietf-avtcore-rtp-security-options: >>> I have reviewed this draft in preparation for IETF Last Call and = IESG >>> processing. One question to discuss briefly before IETF LC: My = major >>> concern is that it seems like there's a lot of old stuff in here. = Has >>> the WG considered explicitly marking each of the mechanisms with = some >>> sort of recommendation level? I would like to avoid having someone >>> choose SDES in a case where they could use DTLS-SRTP, for example. >>=20 >> Such recommendations would be very helpful, but depend on the = scenario. >> Section 5 gives some pointers, but really we need security = architecture >> drafts for particular use cases of RTP (like the WebRTC security = arch, >> for example). >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>> If the authors could follow up on that one point, we should be able = to >>> get these both into LC soon. >>>=20 >>> Thanks, >>> --Richard >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >>=20 >=20 --=20 Colin Perkins http://csperkins.org/ From fluffy@iii.ca Tue Nov 5 09:11:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992611E81B9 for ; Tue, 5 Nov 2013 09:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb+jqrjbOS3X for ; Tue, 5 Nov 2013 09:11:10 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E43F711E81A3 for ; Tue, 5 Nov 2013 09:11:07 -0800 (PST) Received: from sjc-vpn6-246.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 39B6F22E1FA; Tue, 5 Nov 2013 12:11:00 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: Date: Tue, 5 Nov 2013 09:13:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9FFCCD83-7E7E-4B3A-9C4A-424813CEFF55@iii.ca> References: <7A3480BE-9791-4B80-B5B7-6B07F9F68E48@iii.ca> To: Dean Willis X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:11:15 -0000 agree - I'd like to get a better list about metadata, what is needed, = how to handle it etc =85=20 On Nov 4, 2013, at 1:20 PM, Dean Willis = wrote: > One thing you don't elaborate is reduction of the metadata attack = surface by reducing the amount of exposed metadata. In a messaging = model, the only thing that needs to be exposed "to the cloud" is the = destination locator, and possibly a random-ish (perhaps a hash of the = content) message tag. See the Crowcroft SNA idea previously referenced = on this list. >=20 > Note that one can certainly envision an onion-routing model here that = could further obfuscate peer linkages "within the cloud". Especially = with randomized timing. > On Oct 20, 2013 5:57 PM, "Cullen Jennings" wrote: >=20 > I've been thinking about how to build cloud collaborations systems = where the data is encrypted and the cloud does not have the keys. Very = interested in hearing others thoughts on how to do this. >=20 > Near the end is a list of things that it would be helpful if the IETF = standardized. >=20 > http://www.ietf.org/id/draft-jennings-perpass-secure-rai-cloud-00.pdf >=20 > Cullen >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From magnus.westerlund@ericsson.com Tue Nov 5 10:14:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E301021F9B65; Tue, 5 Nov 2013 10:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.463 X-Spam-Level: X-Spam-Status: No, score=-105.463 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMWBJ2XR+mr0; Tue, 5 Nov 2013 10:14:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 104D521F9E95; Tue, 5 Nov 2013 10:14:32 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-ba-5279358722d7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E0.12.03802.78539725; Tue, 5 Nov 2013 19:14:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Tue, 5 Nov 2013 19:14:30 +0100 Message-ID: <527935DF.3070801@ericsson.com> Date: Tue, 5 Nov 2013 10:15:59 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Hannes Tschofenig , Colin Perkins References: <5278AF67.1000704@gmx.net> In-Reply-To: <5278AF67.1000704@gmx.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW67aWWQwdf/8hYve1ayWyx/eYLR YvvulWwWS3f9ZbFYuvMeq8XdSx0sFlP7bB3YPabdv8/msXjTfjaPJUt+MnlM3jiLxePL5c9s AaxRXDYpqTmZZalF+nYJXBmLjx1hLGgSqDg7iaWBsYm3i5GDQ0LARKJ/QVEXIyeQKSZx4d56 ti5GLg4hgUOMEueer2WHcJYxShy/v4UNpIpXQFvi+NvfjCA2i4CKxPYpj1hBbDYBC4mbPxrB akQFgiXOv1rMDlEvKHFy5hMWEFtEIEzi+spzrCBDmQW2Mko8+36IGeQKYYF8ibldkRDLFjBK XL/0nw0kzimgLtF2VR3iUHGJnsYgkDHMAnoSU662MELY8hLNW2czg9hCQKc1NHWwTmAUmoVk 8ywkLbOQtCxgZF7FyJ6bmJmTXm60iREY9Ae3/FbdwXjnnMghRmkOFiVx3g9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MGattbD39Y5bcvBdkuv0+6Gq6SxzT50wCXoUUsNbu2P20ldc Sxp/z+J4pOYf80srX8TxbtMSk759yXJfzSazb5iclirU/i98dsLe/Hlb/QyrHnNySIt6sazM 4H9z2+yv5w3VQ8bHqoXjfxx+NK+AWbH8+pnCw58Cmt/c0Xh18Ny/26xr1t3KeaHEUpyRaKjF XFScCADSFCi8SAIAAA== X-Mailman-Approved-At: Tue, 05 Nov 2013 10:15:49 -0800 Cc: Richard Barnes , perpass@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-rtp-security-options@tools.ietf.org Subject: Re: [perpass] [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:14:40 -0000 On 2013-11-05 00:42, Hannes Tschofenig wrote: > > The argument that RTP is used in a number of different environments, as > a basis for not offering a solid security story is rather weak. The same > could be said about many other protocols the IETF develops, even about > TLS itself. > I strongly disagree with that. TLS is a solution you choose to apply or not. If your RTP application is a multicast one, then we can't do DTLS-SRTP, because it is can't function in such an environment. Similar observations can be made about a number of different deployment cases. > I am wondering what motivated you write the document in this specific > style. I believe I understand the motivation for Magnus. My motivation for writing SRTP-not-mandatory document was as WG chair to not have to argue with the Security ADs each time an RTP document passed the IESG about the security sections. If you are doing an RTP extensions you need to discuss what that implies security wise and what security requirements it has. However, it is not the appropriate place to mandate a particular solution and key-management. What have been missing in IETF is to write the different "This is what you shall do, given that your RTP application class is foo". There is clearly a need for such a document for SIP established sessions. But I don't volunteer to write it. If you look at draft-ietf-mmusic-rfc2326bis, that actually normatively require anyone supporting RTP with RTSP 2.0 to implement SRTP and MIKEY based keying because that makes sense for RTSP. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From hallam@gmail.com Tue Nov 5 10:20:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F011121F9C05 for ; Tue, 5 Nov 2013 10:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFFjVhAnlrdH for ; Tue, 5 Nov 2013 10:20:37 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9957421F9D1C for ; Tue, 5 Nov 2013 10:20:21 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id er20so2462003lab.31 for ; Tue, 05 Nov 2013 10:20:15 -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=ot9kWPBt5qVrRyjYzWmyevsg+Kb9eQE70OhWvrZFFqo=; b=FzvWaadZg00LD/udHQQdHCDC2R9O1hJ+K6KqaI6mVeWhRoxIqy3AGv+j4wdHtnIwit hGJd5oUwwZUoiG38ZOmq8sWTvwTHihRKs9E2Dlmp/qPvyXwgYQ3LOVooF6zYb100Jsld auPjwvBU7WmYfnfjb5idwG1KlVWkPZUje7HtnkidGytcdG8O5gn7ovUDWY1PpypDYiHm lVYhx0fdEX+0IodpmtKQA5cgZFqzCw1h4Jrr8AalwgiqIR5XuPy1hvBj/CcDT9RVZkuZ wWvfcCRezKQxuGNCRWMrANGHcyuiJx5NLsvlhTa/Zmg+OyimJz79fp/YDn9IBKuWnJMo X36Q== MIME-Version: 1.0 X-Received: by 10.152.23.137 with SMTP id m9mr17017452laf.17.1383675615261; Tue, 05 Nov 2013 10:20:15 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 5 Nov 2013 10:20:15 -0800 (PST) In-Reply-To: <52791087.1030803@gmail.com> References: <52791087.1030803@gmail.com> Date: Tue, 5 Nov 2013 13:20:15 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Rutkowski Content-Type: multipart/alternative; boundary=089e0160a676883c1904ea721524 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:20:38 -0000 --089e0160a676883c1904ea721524 Content-Type: text/plain; charset=ISO-8859-1 It all depends on whether the enemy is s bunch of authoritarian governments with their gulags for political prisoners or a bunch on religious fanatics who can clean a Kalashnikov and milk a goat. I suspect that the truth of the matter is that there is no enemy at all and all the surveillance is just a bunch of boasting generals polishing their egos and pouring billions of dollars of taxpayer money into vanity projects to do so. Can't necessarily stop the intercepts but we can end the careers of a few militarists wo fogot who the enemy was and decided to go to war on their own citizens instead. Their tradecraft stinks, their code names are ludicrous aggrandizing showboats popping powerpoint slides that they keep unencrypted on a server run by the guy with a stripper girlfriend. The NSA is not a police force, they are not a law enforcement agency. They have no business having any involvement in civil police functions. The Snowden issue is going to be a campaign issue in 2016 regardless of what the parties want. On Tue, Nov 5, 2013 at 10:36 AM, Tony Rutkowski wrote: > Hi Phill, > > And just how does one get from Phill and friends > in perpass talking about clever schemes, to "forcing" > all the governments, vendors, and providers of the > world to implement those schemes? That seems > like a rather large and important step to be asserting > as part of your technical(?) plan! :-) > > You do realize that ironically at this very moment, > there are ITU-T meetings occurring where some of > those actors are collaborating on doing the opposite. > In fact, if you examine the appendix to the original > submitted Rec. Y.2770, you'll see about 34 use cases > for the commercial benefits of pervasive surveillance. > And, that doesn't include government use cases. > > One of the unintended consequences of the past > couple months of exposing stolen UK and US > documents is that the budgets and stature of the > services of a great many other countries became > substantially increased, and the providers/vendors > will be subject to more extensive pervasive > surveillance requirements. It's funny how the > real world works. > > best, > tony > > > On 11/5/2013 10:01 AM, Phillip Hallam-Baker wrote: > >> And there would be an issue of collusion with the carriers and >> governments. But reducing the attack surface from every government who can >> rent a back hoe to one government with a subpoena is very powerful. And >> forcing the intelligence agencies to collude to perform traffic analysis >> would further limit capabilities. >> >> > -- Website: http://hallambaker.com/ --089e0160a676883c1904ea721524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It all depends on whether the enemy is s bunch of authorit= arian governments with their gulags for political prisoners or a bunch on r= eligious fanatics who can clean a Kalashnikov and milk a goat.

I suspect that the truth of the matter is that there is no enemy at al= l and all the surveillance is just a bunch of boasting generals polishing t= heir egos and pouring billions of dollars of taxpayer money into vanity pro= jects to do so.

Can't necessarily stop the intercepts but we can en= d the careers of a few militarists wo fogot who the enemy was and decided t= o go to war on their own citizens instead.

Their t= radecraft stinks, their code names are ludicrous aggrandizing showboats pop= ping powerpoint slides that they keep unencrypted on a server run by the gu= y with a stripper girlfriend.=A0

The NSA is not a police force, they are not a law enfor= cement agency. They have no business having any involvement in civil police= functions.


The Snowden issue is go= ing to be a campaign issue in 2016 regardless of what the parties want.=A0<= /div>




On Tue, Nov 5, 2013 at 10:36 AM, Tony Rutkowski <rutkowski.tony@gmail.com> wrote:
Hi Phill,

And just how does one get from Phill and friends
in perpass talking about clever schemes, to =A0"forcing"
all the governments, vendors, and providers of the
world to implement those schemes? =A0 That seems
like a rather large and important step to be asserting
as part of your technical(?) plan! :-)

You do realize that ironically at this very moment,
there are ITU-T meetings occurring where some of
those actors are collaborating on doing the opposite.
In fact, if you examine the appendix to the original
submitted Rec. Y.2770, you'll see about 34 use cases
for the commercial benefits of pervasive =A0surveillance.
And, that doesn't include government use cases.

One of the unintended consequences of the past
couple months of exposing stolen UK and US
documents is that the budgets and stature of the
services of a great many other countries became
substantially increased, and the providers/vendors
will be subject to more extensive pervasive
surveillance requirements. =A0It's funny how the
real world works.

best,
tony


On 11/5/2013 10:01 AM, Phillip Hallam-Baker wrote:
And there would be an issue of collusion with the carriers and governments.= But reducing the attack surface from every government who can rent a back = hoe to one government with a subpoena is very powerful. And forcing the int= elligence agencies to collude to perform traffic analysis would further lim= it capabilities.





--
= Website: http://hallambaker.com/
--089e0160a676883c1904ea721524-- From hallam@gmail.com Tue Nov 5 10:33:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC4F11E81C3 for ; Tue, 5 Nov 2013 10:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iTsmgfNa4zk for ; Tue, 5 Nov 2013 10:33:25 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4356411E80DE for ; Tue, 5 Nov 2013 10:33:24 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ep20so2244164lab.15 for ; Tue, 05 Nov 2013 10:33:24 -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=7ZvOS9qNkXfKBg/vxXDa2/Ca0vJOfTgKWRcray5nJXg=; b=UWOTUuhSW3mER0hRJ3eXJSzC0Hx5p5DCJTgT66CT/jVtWLrIyl7ENuwI4CDBDodgEz sVX9AAOdbl47XiXE4FAL3jk+gUCtxd2FPQQN145y3n11nwg6pnLlDemkrW7W/wIPVOhx opCfI5iDhzXGZ/Ukjk78+++TiZYxOV+4YG7g3N6as7J4QmjSzcEMrq7BAgmPdTz6sEEw Jkj3TcsmsufxwW0MQbXv7jyuIfYbOGVoisQ2zlVPrrrN+jSP03sYsDxKwX2VgvoCSHCb zZc5mhvdqPHyIV/wDwx5r+WzO2NWfECjkPvJu6AqFtUFrtHGO0IpcvgMaJglsYwvFqRy ND9A== MIME-Version: 1.0 X-Received: by 10.152.28.105 with SMTP id a9mr2467678lah.41.1383676403967; Tue, 05 Nov 2013 10:33:23 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 5 Nov 2013 10:33:23 -0800 (PST) In-Reply-To: <1383665417.5165.51.camel@galileo.millnert.se> References: <1383665417.5165.51.camel@galileo.millnert.se> Date: Tue, 5 Nov 2013 13:33:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Martin Millnert Content-Type: multipart/alternative; boundary=089e0160a2408aecdd04ea7244d2 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:33:26 -0000 --089e0160a2408aecdd04ea7244d2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 10:30 AM, Martin Millnert wrote: > there are vendors selling transponder type bitstream encrypters. It's > relatively easy to apply bitstream crypto at the bitstream layer, as I > understand it. (How this holds for 100G serial stream, I don't know. > Many 100G transceivers utilize 4x25G or 10x10G serialisation and muxing > techniques, and how encryption/keying/timing would work here I'm not > sure...) > I am aware that there are existing products designed to prevent data disclosure. But I am not certain that they are designed to prevent traffic analysis or qualified for that role. To be effective in that capacity, the links have to be designed to prevent timing attacks and be qualified in that role. Yes, it will require some work. But I think it is quite practical. All that it takes is for some of the major purchasers to put this down as a requirement in their RFPs and features will appear in the silicon. In fact the requirement is even weaker, the manufacturers merely need to suspect that this might be the case. Yes, I agree that a very likely outcome is that some governments will issue an order telling their ISPs to encrypt the links and give them the decryption keys. But moving from a world where the PLA and the NSA are both tapping Google's links in the US to one where only the NSA can do that is still an advance. There is a limit to the amount of data that the PLA mole's in the NSA and their stripper girlfriends can extract from the system, they can only carry so many USB sticks out the gate of Fort Meade every day. > I would be very vary of proprietary encryption protocols however. > Interoperable and openly standardized (though not bastardized), AES-type > encryption would provide some safety. > Key management, obviously is an issue, as well. > +1 Yes, it has to be done right. And it might well be a job for IEEE rather than IETF but I think it needs to be something that the IETF is involved in setting requirements for and integrating into the IP stack. -- Website: http://hallambaker.com/ --089e0160a2408aecdd04ea7244d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2013 at 10:30 AM, Martin Millnert <martin= @millnert.se> wrote:
=A0
there are vendors selling tran= sponder type bitstream encrypters. =A0It's
relatively easy to apply bitstream crypto at the bitstream layer, as I
understand it. (How this holds for 100G serial stream, I don't know. Many 100G transceivers utilize 4x25G or 10x10G serialisation and muxing
techniques, and how encryption/keying/timing would work here I'm not sure...)

I am aware that there are exis= ting products designed to prevent data disclosure. But I am not certain tha= t they are designed to prevent traffic analysis or qualified for that role.=

To be effective in that capacity, the links have to be = designed to prevent timing attacks and be qualified in that role.=A0
<= div>
Yes, it will require some work. But I think it is quite = practical. All that it takes is for some of the major purchasers to put thi= s down as a requirement in their RFPs and features will appear in the silic= on. In fact the requirement is even weaker, the manufacturers merely need t= o suspect that this might be the case.


Yes, I agree that a very likely outcome = is that some governments will issue an order telling their ISPs to encrypt = the links and give them the decryption keys. But moving from a world where = the PLA and the NSA are both tapping Google's links in the US to one wh= ere only the NSA can do that is still an advance. There is a limit to the a= mount of data that the PLA mole's in the NSA and their stripper girlfri= ends can extract from the system, they can only carry so many USB sticks ou= t the gate of Fort Meade every day.

=A0
I would be very vary of proprietary encryption protocols however.
Interoperable and openly standardized (though not bastardized), AES-type encryption would provide some safety.
Key management, obviously is an issue, as well.

+1=A0

Yes, it has to be done right. And i= t might well be a job for IEEE rather than IETF but I think it needs to be = something that the IETF is involved in setting requirements for and integra= ting into the IP stack.


--
Website: http://hallambaker.com/
--089e0160a2408aecdd04ea7244d2-- From rutkowski.tony@gmail.com Tue Nov 5 10:44:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF221E8089 for ; Tue, 5 Nov 2013 10:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er2f+sFnH-rq for ; Tue, 5 Nov 2013 10:44:41 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DFF9C21E8085 for ; Tue, 5 Nov 2013 10:44:35 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id k18so5028940qcv.38 for ; Tue, 05 Nov 2013 10:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DUeXR4mIDat8T+LL/11gghkLipLsJbAMTysEox41ufs=; b=kSnf8diEmlJah7xulC17hxggmKRFepsZhh2+lIWfVw1w8VXMH2tGT7KTlHTpwFtJR4 W4JN2mQtYle8h04HruuYIFbVFytM0I1ZfVFWPU9du3BkHgRhceX3fJBYyYKnDibi5q6X IYciBaY/NSK14M2ivEw/1prOYwy90lSvONbJ+FYQ02KC3npcvP+hjdtGu/s0eiJE/2/j QJtVNuPXOLPhzLg1A0egQNa/MKEVjq4bbaxQDCgc0vZYyCCQOTLaIUkJ6bj4GZbs6FDL ygHxCmAOouIb9OLjns8VmM4TJr5sPJJvRQtx2KmzuIhzu5cD0BhHWP3KSoRPlCl4IaNO 1BAg== X-Received: by 10.229.65.201 with SMTP id k9mr31370067qci.11.1383677075233; Tue, 05 Nov 2013 10:44:35 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id n7sm69991485qai.1.2013.11.05.10.44.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:44:34 -0800 (PST) Message-ID: <52793C91.9080102@gmail.com> Date: Tue, 05 Nov 2013 13:44:33 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <52791087.1030803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:44:45 -0000 Phill, Might I suggest that your characterizations are far from accurate here, and I would certainly not denigrate the UK government in this fashion. You are, however, evading the key question repeated below: > And just how does one get from Phill and friends > in perpass talking about clever schemes, to "forcing" > all the governments, vendors, and providers of the > world to implement those schemes? ...especially when most those other governments governments and a great many providers are now scaling up their activities to instantiate more pervasive surveillance in the infrastructure. Or, is this all just an academic exercise? --tony From brian.e.carpenter@gmail.com Tue Nov 5 10:52:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1182C21E809F for ; Tue, 5 Nov 2013 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMXEy-cKyQox for ; Tue, 5 Nov 2013 10:52:04 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E521F9E1D for ; Tue, 5 Nov 2013 10:50:02 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id u16so15346609iet.21 for ; Tue, 05 Nov 2013 10:49:58 -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 :subject:content-type:content-transfer-encoding; bh=9nwO/9Crn02SmtQ19ik1+sz/hlIBFaYvYJeN4QMCcNo=; b=TKOyV+sM4BuHmaxgLZNS0rdu5x0mNwo5wfPZ/39zF4I/pF1Tu3uGmaKH+nKvAhyvfz TXc8SbmVZLQeEXB2Ub9aA7buuc35ivg8HM5D1kUdfNvAOIJHBVox/O3dYpU5Ege9Z52j P0fJjHZoYLjnO5XGT2xpGcYDPvBuF9yueClbL/ZU9RPQgRAA0A7s77v/n3ilzcGjWzqY q44RPyK3Wk38ySvSE6pTYRCE9tfDkyA/nWx4W9r/e8Me+HFODdOQnhyN44OzRWDyKxL1 kRMt5qJNYqPp+mOHAGt3vtz0npdt7KMvYixwR0wgJI6WKM8VxAdccLqZgAs4qRgzmuXP hkRg== X-Received: by 10.43.57.79 with SMTP id wf15mr14578272icb.14.1383677398627; Tue, 05 Nov 2013 10:49:58 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id w7sm9770660igp.1.2013.11.05.10.49.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:49:58 -0800 (PST) Message-ID: <52793DDA.3040804@gmail.com> Date: Wed, 06 Nov 2013 07:50:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [perpass] Progress, of a kind X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:52:06 -0000 I realise this is off-topic except that it documents the threat model, but I think it's worth noting that legislators are sticking their noses in. (This law is a reaction to the Kim Dotcom case, not to the Snowden revelations.) http://www.stuff.co.nz/national/politics/9364767/Spying-bill-passes-into-law Brian From lars@netapp.com Tue Nov 5 10:52:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BC221E81AF for ; Tue, 5 Nov 2013 10:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.373 X-Spam-Level: X-Spam-Status: No, score=-4.373 tagged_above=-999 required=5 tests=[AWL=-2.573, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytILCyOhU6Zn for ; Tue, 5 Nov 2013 10:52:18 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA711E8276 for ; Tue, 5 Nov 2013 10:50:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,640,1378882800"; d="asc'?scan'208";a="69960369" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 05 Nov 2013 10:50:33 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 10:50:33 -0800 From: "Eggert, Lars" To: perpass Thread-Topic: Final agenda for the IRTF Open Meeting at IETF-88 Thread-Index: AQHO2lamINQeVjfl2kmu0x0to19K6g== Date: Tue, 5 Nov 2013 18:50:32 +0000 Message-ID: <365BDA36-83B9-44A8-A816-EC30DBAF6588@netapp.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_A718383B-E704-42BF-9F52-3F18E2E74FD0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [perpass] Fwd: Final agenda for the IRTF Open Meeting at IETF-88 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:52:23 -0000 --Apple-Mail=_A718383B-E704-42BF-9F52-3F18E2E74FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The final (reordered) agenda for the IRTF Open Meeting at IETF-88 is = now online: = https://www.ietf.org/proceedings/88/agenda/agenda-88-irtfopen >=20 > In addition to the ANRP talk, we'll have a PERPASS-related talk by = Nick Feamster, and a pitch by Eliot Lear. >=20 > Lars >=20 > -- >=20 > Agenda > IRTF Open Meeting @ IETF-88 > Vancouver, Canada > 1420-1550 PST > Tuesday Afternoon Session II >=20 > [Slot lengths below indicate presentation+discussion time.] >=20 > State of the IRTF > Lars Eggert > 5+5 min >=20 > Applied Networking Prize (ANRP) Award Talk > 30+10 min >=20 > *** IDILIO DRAGO *** for characterizing traffic and workloads of = the > Dropbox cloud storage system: >=20 > Idilio Drago, Marco Mellia, Maurizio M. Munafo, Anna Sperotto, > Ramin Sadre and Aiko Pras. Inside Dropbox: Understanding Personal > Cloud Storage Services. Proc. ACM Internet Measurement Conference > (IMC), November 2012, Boston, MA, USA. >=20 >=20 > Measuring and Circumventing Internet Censorship and Control > Nick Feamster > 25+5 min > =09 > =09 > Internet Research Grand Challenges > Eliot Lear > 10 min=09 --Apple-Mail=_A718383B-E704-42BF-9F52-3F18E2E74FD0 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----- iQCVAwUBUnk999ZcnpRveo1xAQKkEwQAgLvZHl3OaSiILdHTBeAvBOTnvhrmYE+z eOkf5gDVvRgxZ46v9jyElyuHN8f0ygWbvfXyWNB3Tep0cKBofQKB2/4YdHkFg1dh E2O7J1pJ9K1CSKNbrMK5Ep6h+KqyIzyI8zm3z6T1ju2rGTvRz0XPWii913zwKOXu DfS6C1+IlLY= =GKv0 -----END PGP SIGNATURE----- --Apple-Mail=_A718383B-E704-42BF-9F52-3F18E2E74FD0-- From rutkowski.tony@gmail.com Tue Nov 5 11:30:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E9F11E8119 for ; Tue, 5 Nov 2013 11:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubtmWsn1Bqbb for ; Tue, 5 Nov 2013 11:30:39 -0800 (PST) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9421F99F4 for ; Tue, 5 Nov 2013 11:30:06 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so5231964qej.21 for ; Tue, 05 Nov 2013 11:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=j/sIqoyLEr2yLiag6ZTh7UxIMwAMRgrg5/ijCTxl5iw=; b=saJFw1ABY8ayYdy9iGgxvecFpIBxYrWzacamxGOujELbMc9kDEBAectT7I/tRPOlQZ nZCpXdxSFlg5GDEVkTLPKeMuIYip+XLC7Lx3PqgIp87c+1HcR9U9GkNWls5YZRpJ92ai 5tCGD7vc7ILBS6eanmH68mjM/jL/vJLjScNplb/we70FKb2+ZCGv+plGVHM+sg09eOM6 eszqfApalNhMj+vlGOVqkkFc038DbrqDnzr7D8s42FbfsR6SaBnd77/0YtSFUu4K65r5 /wPSw1rbkyDkLS/tmPfDJHrrLw1T1LrG2HMXPfOc15M/6Z4NilHdHgTaK4DCeJSmlBIE TziA== X-Received: by 10.49.24.74 with SMTP id s10mr32231299qef.24.1383679805462; Tue, 05 Nov 2013 11:30:05 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id h9sm70390392qaq.9.2013.11.05.11.30.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 11:30:04 -0800 (PST) Message-ID: <5279473B.2000400@gmail.com> Date: Tue, 05 Nov 2013 14:30:03 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Brian E Carpenter , perpass@ietf.org References: <52793DDA.3040804@gmail.com> In-Reply-To: <52793DDA.3040804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Progress, of a kind X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:30:41 -0000 Hi Brian, A bit more on topic were the proposals just submitted by Saudia Arabia, Russia, and Brazil into the ITU's principal continuing intergovernmental body, the Council, and it's Working Group on international Internet-related public policy issues, to have the ITU take over "Internet Governance" of security matters including "legal and enforcement issues related to criminal activity and other abuses of the Internet." This all presages it's major treaty conference next November. They are reacting to concerns about pervasive surveillance. That's an interesting threat model as well. :-) --tony On 11/5/2013 1:50 PM, Brian E Carpenter wrote: > I realise this is off-topic except that it documents the threat model, > but I think it's worth noting that legislators are sticking their noses > in. (This law is a reaction to the Kim Dotcom case, not to the Snowden > revelations.) > > http://www.stuff.co.nz/national/politics/9364767/Spying-bill-passes-into-law > > Brian From eburger@standardstrack.com Tue Nov 5 12:49:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52BD21E80E4 for ; Tue, 5 Nov 2013 12:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XbaayM8X+rb for ; Tue, 5 Nov 2013 12:49:01 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4084021E8093 for ; Tue, 5 Nov 2013 12:49:01 -0800 (PST) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52660 helo=[192.168.15.194]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VdnYX-000268-Nl; Tue, 05 Nov 2013 12:49:00 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_DC816035-D7E3-4A03-9DF1-FC2F00371407"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Eric Burger In-Reply-To: Date: Tue, 5 Nov 2013 15:48:52 -0500 Message-Id: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1816) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:49:06 -0000 --Apple-Mail=_DC816035-D7E3-4A03-9DF1-FC2F00371407 Content-Type: multipart/alternative; boundary="Apple-Mail=_B854CE03-7355-4F0A-8E3F-83ADD04C13E4" --Apple-Mail=_B854CE03-7355-4F0A-8E3F-83ADD04C13E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I do not see how this can help. In fact, I see this as a very DANGEROUS = proposal. The reason is precisely because all this proposal does is mean that ONLY = the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their = secrets stay secret, so there is no accountability. Why do I say this? Because these organizations have the capability to = take the full firehose. They do not need to tap anything, they just = insert an extra router and they are in. No need for messy warrants, = paid-off corporations, or undercover ISP employees that are actually in = the employ of the government. I do not get how link encryption helps at all. Please illuminate. On Nov 5, 2013, at 10:01 AM, Phillip Hallam-Baker = wrote: >=20 > One of the handicaps we are working under is that the IETF is = historically the ARPANET 'End to End' working group and we define the = Internet stack from the IP layer up. >=20 > Some problems can't be addressed at the IP layer, in particular it is = impossible to address traffic analysis efficiently or pervasively. Tor = is very good at what it does but Tor can't support three billion users = doing streaming video under any imaginable circumstances. >=20 > A much better option would be to tell every network vendor that they = have to build full speed encryption/decryption capability into every = link adapter and exchange encrypted data all the time the fiber is lit. = The protocol for establishing the link layer encryption need not be very = fancy. It arguably does not even need to be proof against a man in the = middle attack since any man in the middle is going to be forced to drink = the whole fire hose. >=20 > There are devices for encrypting OC-768 40Gbit links today. But they = are niche products made for NSA use (now where does all that data come = from??). AES in standard cell does not add a huge number of gates to a = circuit. Vendors need to be trained to believe that they have to add it = to every chip or won't be able to sell the product. >=20 > On circuit encryption is potentially much better against traffic = analysis in any case since if you bolt a hardware encryptor onto a link = and feed it data, it is likely that the timing of bits at least provides = hints for a timing attack. >=20 > Such a scheme would be in no way a replacement for end-to-end = encryption. And there would be an issue of collusion with the carriers = and governments. But reducing the attack surface from every government = who can rent a back hoe to one government with a subpoena is very = powerful. And forcing the intelligence agencies to collude to perform = traffic analysis would further limit capabilities. >=20 > The payoff for this effort is a major increase in work factor and in = particular, forcing an adversary attempting a traffic analysis attack to = intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of = data to store. It is over an exabyte per link per year. Or about a = quarter million 4Tb hard drives. Or $200 million at $500 per drive = (including racking etc.) >=20 > And that is per link. >=20 > The NSA budget is in the tens of billions a year. So we can eat up the = whole pie by encrypting 50-500 links. Or the entire military budget = would be 5,000 links. The only feasible attack would be to suborn the = fab. But I expect that there will be a presidential executive order = prohibiting that type of sabotage under the next President recognizing = the fact that the cost of such activities in terms of damage to trust in = international commerce is vastly greater than the benefit to the = boasting generals careers.=20 >=20 >=20 > 40Gb/sec is not a vast quantity of data to encrypt with hardware = support. Not for a device that is all custom VLSI anyway by its very = nature. If the fiber is lit it is going to take the same power whether = it sends all zeros or a mixture of ones and zeros.=20 >=20 > There would be a small degree of additional complexity introduced by = the need to conceal the sizes of the underlying packets. >=20 >=20 > It would not be a perfect defense against every attack and there is = still the possibility that the attacker would persuade data to be sent = over unencrypted links and such. But it would establish a gratifying = increase in work factor which is the objective here. >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_B854CE03-7355-4F0A-8E3F-83ADD04C13E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I do = not see how this can help. In fact, I see this as a very DANGEROUS = proposal.

The reason is precisely because all this = proposal does is mean that ONLY the NSA, GCHQ, MSS (PRC), and GRU gets = to analyze all data. Worse, their secrets stay secret, so there is no = accountability.

Why do I say this? Because = these organizations have the capability to take the full firehose. They = do not need to tap anything, they just insert an extra router and they = are in. No need for messy warrants, paid-off corporations, or undercover = ISP employees that are actually in the employ of the = government.

I do not get how link encryption = helps at all. Please illuminate.

On Nov 5, 2013, = at 10:01 AM, Phillip Hallam-Baker <hallam@gmail.com> = wrote:


One of the handicaps = we are working under is that the IETF is historically the ARPANET 'End = to End' working group and we define the Internet stack from the IP layer = up.

Some problems can't be addressed at the IP layer, in = particular it is impossible to address traffic analysis efficiently or = pervasively. Tor is very good at what it does but Tor can't support = three billion users doing streaming video under any imaginable = circumstances.

A much better option would be to tell every network = vendor that they have to build full speed encryption/decryption = capability into every link adapter and exchange encrypted data all the = time the fiber is lit. The protocol for establishing the link layer = encryption need not be very fancy. It arguably does not even need to be = proof against a man in the middle attack since any man in the middle is = going to be forced to drink the whole fire hose.

There are devices for encrypting OC-768 40Gbit links = today. But they are niche products made for NSA use (now where does all = that data come from??). AES in standard cell does not add a huge number = of gates to a circuit. Vendors need to be trained to believe that they = have to add it to every chip or won't be able to sell the product.

On circuit encryption is potentially much better = against traffic analysis in any case since if you bolt a hardware = encryptor onto a link and feed it data, it is likely that the timing of = bits at least provides hints for a timing attack.

Such a scheme would be in no way a replacement for = end-to-end encryption. And there would be an issue of collusion with the = carriers and governments. But reducing the attack surface from every = government who can rent a back hoe to one government with a subpoena is = very powerful. And forcing the intelligence agencies to collude to = perform traffic analysis would further limit capabilities.

The payoff for this effort is a major increase in = work factor and in particular, forcing an adversary attempting a traffic = analysis attack to intercept and decrypt multiple fire hoses. 40Gb/sec = is quite a lot of data to store. It is over an exabyte per link per = year. Or about a quarter million 4Tb hard drives. Or $200 million at = $500 per drive (including racking etc.)

And that is per link.

The = NSA budget is in the tens of billions a year. So we can eat up the whole = pie by encrypting 50-500 links. Or the entire military budget would be = 5,000 links. The only feasible attack would be to suborn the fab. But I = expect that there will be a presidential executive order prohibiting = that type of sabotage under the next President recognizing the fact that = the cost of such activities in terms of damage to trust in international = commerce is vastly greater than the benefit to the boasting generals = careers. 


40Gb/sec is not a vast quantity of = data to encrypt with hardware support. Not for a device that is all = custom VLSI anyway by its very nature. If the fiber is lit it is going = to take the same power whether it sends all zeros or a mixture of ones = and zeros. 

There would be a small degree of additional = complexity introduced by the need to conceal the sizes of the underlying = packets.


It would not be a perfect = defense against every attack and there is still the possibility that the = attacker would persuade data to be sent over unencrypted links and such. = But it would establish a gratifying increase in work factor which is the = objective here.

--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= --Apple-Mail=_B854CE03-7355-4F0A-8E3F-83ADD04C13E4-- --Apple-Mail=_DC816035-D7E3-4A03-9DF1-FC2F00371407 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 iQIcBAEBAgAGBQJSeVm1AAoJEORoZaSQsc1IALoQAOiVTqNlQdALWWGRGnt2PArz J14paowFJf9ACOlfpiBtSR4zRVAPRuDI2iuN4FWXe7Li8FvQvhEYBw4iSJ6M1UdR e1BAUra7Y82SsF1O99znS8dPd0NN7Wz6YMEsb07NPnvCVjlbgdr0h3BkW6wAhUmD JkY7yQjaRLoC7O3bIMWFz9DqGP6xUQWd2h7kro+mq1So4vtqvNEk7CCxkbNCVe5Z fjGgeTq1EwiMjHaiL35Dcbfc5BLQawh7KZtdpIywRGuq4q5h9/X8svbW/vv/LpUG MN4hbZA9mMe2/k20/TI9NySgL8TP5XdtNl1mdCtpHwcnqyDSEvYussag6xR4wrvV kDpR/fiDGtIEj+9mVhXaap2YMbyouG/oFwIhEqC8SWpY3oOrG9PG3n93v4+mdMch 2tWCHQzQ8Y5JP5O211bhhQsbJwszM7h2tQdnHAl4TMQdS4hRPg3eN0x7OCu0IbRB NocXv158fXUOJQ5ON1aKM9mdPh6kSNYT+6lKlQdpLr2ZCmF8mqLxAH8dorTckP9s V0oZTm2BGikSCg1ZLQi7zSrqIXunr5vpysbjgJkWA6T/hwe6FyoT5OA2gc6kKqc2 mVtaNRZFoip8R5167PsOedXx3dYFRiXfD52zzHhkUBFfDnWR3UwandbTtfxf5B5C hTZtYYskCODF2C/Dzc0x =CZMQ -----END PGP SIGNATURE----- --Apple-Mail=_DC816035-D7E3-4A03-9DF1-FC2F00371407-- From ynir@checkpoint.com Tue Nov 5 12:56:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8D11E8177 for ; Tue, 5 Nov 2013 12:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+8oGXSBIRzB for ; Tue, 5 Nov 2013 12:56:28 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90911E8156 for ; Tue, 5 Nov 2013 12:56:17 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA5KuCBx019646; Tue, 5 Nov 2013 22:56:12 +0200 X-CheckPoint: {52795A05-1E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 22:56:12 +0200 From: Yoav Nir To: Eric Burger Thread-Topic: [perpass] Encrypt all lit fiber 24x365 Thread-Index: AQHO2jgAYNmqa4qVkUaDsiqnt8K8lZoW+ucAgAACCgA= Date: Tue, 5 Nov 2013 20:56:11 +0000 Message-ID: <6FCD4B62-CF46-40E3-8DC3-E5D483A4F5D8@checkpoint.com> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> In-Reply-To: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.49] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_6FCD4B62CF4640E38DC3E5D483A4F5D8checkpointcom_" MIME-Version: 1.0 Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:56:32 -0000 --_000_6FCD4B62CF4640E38DC3E5D483A4F5D8checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tapping the link can be done passively - no warrant, no paid-off corporatio= n, no undercover government agents posing as ISP employees. Tapping at the end requires one of these things. Nothing has been said abou= t key exchange and/or authentication. On Nov 5, 2013, at 12:48 PM, Eric Burger > wrote: I do not see how this can help. In fact, I see this as a very DANGEROUS pro= posal. The reason is precisely because all this proposal does is mean that ONLY th= e NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their secr= ets stay secret, so there is no accountability. Why do I say this? Because these organizations have the capability to take = the full firehose. They do not need to tap anything, they just insert an ex= tra router and they are in. No need for messy warrants, paid-off corporatio= ns, or undercover ISP employees that are actually in the employ of the gove= rnment. I do not get how link encryption helps at all. Please illuminate. On Nov 5, 2013, at 10:01 AM, Phillip Hallam-Baker > wrote: One of the handicaps we are working under is that the IETF is historically = the ARPANET 'End to End' working group and we define the Internet stack fro= m the IP layer up. Some problems can't be addressed at the IP layer, in particular it is impos= sible to address traffic analysis efficiently or pervasively. Tor is very g= ood at what it does but Tor can't support three billion users doing streami= ng video under any imaginable circumstances. A much better option would be to tell every network vendor that they have t= o build full speed encryption/decryption capability into every link adapter= and exchange encrypted data all the time the fiber is lit. The protocol fo= r establishing the link layer encryption need not be very fancy. It arguabl= y does not even need to be proof against a man in the middle attack since a= ny man in the middle is going to be forced to drink the whole fire hose. There are devices for encrypting OC-768 40Gbit links today. But they are ni= che products made for NSA use (now where does all that data come from??). A= ES in standard cell does not add a huge number of gates to a circuit. Vendo= rs need to be trained to believe that they have to add it to every chip or = won't be able to sell the product. On circuit encryption is potentially much better against traffic analysis i= n any case since if you bolt a hardware encryptor onto a link and feed it d= ata, it is likely that the timing of bits at least provides hints for a tim= ing attack. Such a scheme would be in no way a replacement for end-to-end encryption. A= nd there would be an issue of collusion with the carriers and governments. = But reducing the attack surface from every government who can rent a back h= oe to one government with a subpoena is very powerful. And forcing the inte= lligence agencies to collude to perform traffic analysis would further limi= t capabilities. The payoff for this effort is a major increase in work factor and in partic= ular, forcing an adversary attempting a traffic analysis attack to intercep= t and decrypt multiple fire hoses. 40Gb/sec is quite a lot of data to store= . It is over an exabyte per link per year. Or about a quarter million 4Tb h= ard drives. Or $200 million at $500 per drive (including racking etc.) And that is per link. The NSA budget is in the tens of billions a year. So we can eat up the whol= e pie by encrypting 50-500 links. Or the entire military budget would be 5,= 000 links. The only feasible attack would be to suborn the fab. But I expec= t that there will be a presidential executive order prohibiting that type o= f sabotage under the next President recognizing the fact that the cost of s= uch activities in terms of damage to trust in international commerce is vas= tly greater than the benefit to the boasting generals careers. 40Gb/sec is not a vast quantity of data to encrypt with hardware support. N= ot for a device that is all custom VLSI anyway by its very nature. If the f= iber is lit it is going to take the same power whether it sends all zeros o= r a mixture of ones and zeros. There would be a small degree of additional complexity introduced by the ne= ed to conceal the sizes of the underlying packets. It would not be a perfect defense against every attack and there is still t= he possibility that the attacker would persuade data to be sent over unencr= ypted links and such. But it would establish a gratifying increase in work = factor which is the objective here. -- Website: http://hallambaker.com/ _______________________________________________ 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 --_000_6FCD4B62CF4640E38DC3E5D483A4F5D8checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <772525031FA0E144A9861A928D6071C9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Tapping the link can be done passively - no warrant, no paid-off corporatio= n, no undercover government agents posing as ISP employees. 

Tapping at the end requires one of these things. Nothing has been said= about key exchange and/or authentication.


On Nov 5, 2013, at 12:48 PM, Eric Burger <eburger@standardstrack.com>
 wrote:

I do not see how this can help. In fact, I see this as a very DANGEROUS pro= posal.

The reason is precisely because all this proposal does is mean that ON= LY the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their= secrets stay secret, so there is no accountability.

Why do I say this? Because these organizations have the capability to = take the full firehose. They do not need to tap anything, they just insert = an extra router and they are in. No need for messy warrants, paid-off corpo= rations, or undercover ISP employees that are actually in the employ of the government.

I do not get how link encryption helps at all. Please illuminate.

On Nov 5, 2013, at 10:01 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:


One of the handicaps we are working under is that the IETF is historic= ally the ARPANET 'End to End' working group and we define the Internet stac= k from the IP layer up.

Some problems can't be addressed at the IP layer, in particular it is = impossible to address traffic analysis efficiently or pervasively. Tor is v= ery good at what it does but Tor can't support three billion users doing st= reaming video under any imaginable circumstances.

A much better option would be to tell every network vendor that they h= ave to build full speed encryption/decryption capability into every link ad= apter and exchange encrypted data all the time the fiber is lit. The protoc= ol for establishing the link layer encryption need not be very fancy. It arguably does not even need to be pr= oof against a man in the middle attack since any man in the middle is going= to be forced to drink the whole fire hose.

There are devices for encrypting OC-768 40Gbit links today. But they a= re niche products made for NSA use (now where does all that data come from?= ?). AES in standard cell does not add a huge number of gates to a circuit. = Vendors need to be trained to believe that they have to add it to every chip or won't be able to sell the produc= t.

On circuit encryption is potentially much better against traffic analy= sis in any case since if you bolt a hardware encryptor onto a link and feed= it data, it is likely that the timing of bits at least provides hints for = a timing attack.

Such a scheme would be in no way a replacement for end-to-end encrypti= on. And there would be an issue of collusion with the carriers and governme= nts. But reducing the attack surface from every government who can rent a b= ack hoe to one government with a subpoena is very powerful. And forcing the intelligence agencies to collud= e to perform traffic analysis would further limit capabilities.

The payoff for this effort is a major increase in work factor and in p= articular, forcing an adversary attempting a traffic analysis attack to int= ercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of data to = store. It is over an exabyte per link per year. Or about a quarter million 4Tb hard drives. Or $200 million= at $500 per drive (including racking etc.)

And that is per link.

The NSA budget is in the tens of billions a year. So we can eat up the= whole pie by encrypting 50-500 links. Or the entire military budget would = be 5,000 links. The only feasible attack would be to suborn the fab. But I = expect that there will be a presidential executive order prohibiting that type of sabotage under the next President= recognizing the fact that the cost of such activities in terms of damage t= o trust in international commerce is vastly greater than the benefit to the= boasting generals careers. 


40Gb/sec is not a vast quantity of data to encrypt with hardware suppo= rt. Not for a device that is all custom VLSI anyway by its very nature. If = the fiber is lit it is going to take the same power whether it sends all ze= ros or a mixture of ones and zeros. 

There would be a small degree of additional complexity introduced by t= he need to conceal the sizes of the underlying packets.


It would not be a perfect defense against every attack and there is still t= he possibility that the attacker would persuade data to be sent over unencr= ypted links and such. But it would establish a gratifying increase in work = factor which is the objective here.

--
Website: http://hallambaker.com/
_______________________________________________
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

--_000_6FCD4B62CF4640E38DC3E5D483A4F5D8checkpointcom_-- From tytso@thunk.org Tue Nov 5 14:10:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523EF21F9C89 for ; Tue, 5 Nov 2013 14:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD7UL0P3fKlT for ; Tue, 5 Nov 2013 14:10:18 -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 2640211E8125 for ; Tue, 5 Nov 2013 14:09:59 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1Vdoow-0008VZ-32; Tue, 05 Nov 2013 22:09:58 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 9F4C0580A22; Tue, 5 Nov 2013 17:09:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1383689397; bh=CF9yKuT7F3ngcbOEeogLfwYyiaSq0zQyW8kqAxPTy+8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Tm6xv2W2IuzNbeb5xMA+6GP5HP/LmrT+ItKdhPIlQ17oSouXkxPrZW6LxYiySuTFz St+vh5+XEJ4A77CvPEYBgBbWSicWF8rdHpQI8VgOpl0twPRAqvnGXT1y46lfB+gieN GIFY8NQcuwjkoz683FUhbi3BgzfJ6DCgnW6HxRpc= Date: Tue, 5 Nov 2013 17:09:57 -0500 From: Theodore Ts'o To: Phillip Hallam-Baker Message-ID: <20131105220957.GC14235@thunk.org> References: 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: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:10:19 -0000 On Tue, Nov 05, 2013 at 10:01:58AM -0500, Phillip Hallam-Baker wrote: > The payoff for this effort is a major increase in work factor and in > particular, forcing an adversary attempting a traffic analysis attack to > intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of data > to store. It is over an exabyte per link per year. Or about a quarter > million 4Tb hard drives. Or $200 million at $500 per drive (including > racking etc.) That's assuming the attacker is going to attack link-level security --- which to me sounds like the French assuming the Germans would make a full frontal assault on the Maginot Line. It would seem that a much more intelligent thing for the adversary to do is to force/induce/send a national security letter/FISA warrant so as to put the tap between the decryption gear and the default-free zone router. - Ted From kent@bbn.com Tue Nov 5 14:24:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2A211E81E9 for ; Tue, 5 Nov 2013 14:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oWw5nREqKG5 for ; Tue, 5 Nov 2013 14:24:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0CADB11E80E3 for ; Tue, 5 Nov 2013 14:24:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55004 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vdp38-0006zf-Kj for perpass@ietf.org; Tue, 05 Nov 2013 17:24:38 -0500 Message-ID: <52797026.60907@bbn.com> Date: Tue, 05 Nov 2013 17:24:38 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <3D3E3D53-96C9-4A2E-9751-A088183CFB4B@checkpoint.com> <11AC03FC-E1A1-4533-8CDF-EB64E466F4B2@checkpoint.com> <5263CF15.6020407@gmail.com> <20131020172006.GC23798@thunk.org> <5277F29D.6040609@bbn.com> <52782C20.50307@cs.tcd.ie> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090801040202050600000301" Subject: Re: [perpass] Some personal thoughts on the impact of pervasive monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:24:45 -0000 This is a multi-part message in MIME format. --------------090801040202050600000301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean, > That's not ad-hominen. I'm not saying there's something wrong with the > given message BECAUSE of some other defect of the author. Some "other defect?" Somebody does not know how to play well with others. > Rather, I'm saying that I don't like the tone of the message itself. > It's loaded with negativity that I find disruptive to the work > process. This may be entirely unintentional, in which case pointing it > out might help. It might be intentional, which would lead me to > suspect that there might be some other defect of the author that is > causative of the behavior in question. IETF WG (and BoF) lists enable individuals to express opinions, bot positive and negative, about technical topics under discussion. Such exchanges facilitate improvement of proposals being put forth, as advocates are encouraged to address concerns raised by those who may not be convinced of the proposals put forth. Your comments suggest that no one should be allowed to disagree with your position, because the resulting negativism impairs your aura. Moreover, you ascribe malicious intent to such disagreements, because no reasonable individual could disagree with you? Get over it. Steve --------------090801040202050600000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dean,
That’s not ad-hominen. I’m not saying there’s something wrong with the given message BECAUSE of some other defect of the author.
Some "other defect?" Somebody does not know how to play well with others.
Rather, I’m saying that I don’t like the tone of the message itself. It’s loaded with negativity that I find disruptive to the work process. This may be entirely unintentional, in which case pointing it out might help. It might be intentional, which would lead me to suspect that there might be some other defect of the author that is causative of the behavior in question.

IETF WG (and BoF) lists enable individuals to express opinions, bot positive and negative,
about technical topics under discussion. Such exchanges facilitate improvement of proposals
being put forth, as advocates are encouraged to address concerns raised by those who may
not be convinced of the proposals put forth. Your comments suggest that no one should be
allowed to disagree with your position, because the resulting negativism impairs your aura.
Moreover, you ascribe malicious intent to such disagreements, because no reasonable individual could disagree with you?

Get over it.

Steve

--------------090801040202050600000301-- From hallam@gmail.com Tue Nov 5 16:33:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EF911E8196 for ; Tue, 5 Nov 2013 16:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td9Vyb54O4pw for ; Tue, 5 Nov 2013 16:33:35 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDF11E818C for ; Tue, 5 Nov 2013 16:33:34 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id eo20so3726947lab.37 for ; Tue, 05 Nov 2013 16:33: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=OpzsgDNC+j9pd72vFOu3fqtPtUA0KhLxoVfaPZdjLr4=; b=hT1qQT4OCc+H9tcT1uH+NYtkaTRi/hkooYZgAMrNI+n5LhzFNKi8QbgYIg4VBNEr17 N98td5d2O6iyB6ER3p/PnjYbWVn+ZJI2Yu0jHfGlR/YRJz+g9EdH76H6O3dbmPu9dVKx bV8eWBRrypxZw8hgJZhkGZ85sCdXSZL5siETxdIAdJWHoTJUucapFxUQtzK2kawkB0Vi vgEqfTMqljn9cc+huTv5Xmni8VtBG5EHncXsZxyIM8ONcGK+6Hr2txltwQScnB3wXSq+ MQW57mvSRmptc37Qpe4a/WqFoSvZJ5YHxrm7fGjzkrY4ilyaO6XhmFE1H4ZsjVbEOzi5 vjsw== MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr639802lbb.8.1383698013826; Tue, 05 Nov 2013 16:33:33 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 5 Nov 2013 16:33:33 -0800 (PST) In-Reply-To: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> Date: Tue, 5 Nov 2013 19:33:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Eric Burger Content-Type: multipart/alternative; boundary=089e0116136a9734b604ea774c17 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:33:36 -0000 --089e0116136a9734b604ea774c17 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger wrote: > I do not see how this can help. In fact, I see this as a very DANGEROUS > proposal. > > The reason is precisely because all this proposal does is mean that ONLY > the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their > secrets stay secret, so there is no accountability. > > Why do I say this? Because these organizations have the capability to take > the full firehose. They do not need to tap anything, they just insert an > extra router and they are in. No need for messy warrants, paid-off > corporations, or undercover ISP employees that are actually in the employ > of the government. > > I do not get how link encryption helps at all. Please illuminate. > I am taking it as granted that someone who deploys a $500K router knows how to initialize the crypto securely and that the systems would be performing the usual PFS/ephemeral do-winkies. So inserting an extra router should be immediately visible. -- Website: http://hallambaker.com/ --089e0116136a9734b604ea774c17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger <<= a href=3D"mailto:eburger@standardstrack.com" target=3D"_blank">eburger@stan= dardstrack.com> wrote:
I do not= see how this can help. In fact, I see this as a very DANGEROUS proposal.
The reason is precisely because all this proposal does is me= an that ONLY the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Wo= rse, their secrets stay secret, so there is no accountability.

Why do I say this? Because these organizations have the capa= bility to take the full firehose. They do not need to tap anything, they ju= st insert an extra router and they are in. No need for messy warrants, paid= -off corporations, or undercover ISP employees that are actually in the emp= loy of the government.

I do not get how link encryption helps at all. Please i= lluminate.

I am taking it as gr= anted that someone who deploys a $500K router knows how to initialize the c= rypto securely and that the systems would be performing the usual PFS/ephem= eral do-winkies.=A0

So inserting an extra router should be immedia= tely visible.


--
Website: http://hallambaker.com/
--089e0116136a9734b604ea774c17-- From eburger@standardstrack.com Tue Nov 5 17:00:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6421F9C70 for ; Tue, 5 Nov 2013 17:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLwsuCDnGIzP for ; Tue, 5 Nov 2013 17:00:44 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFD511E8199 for ; Tue, 5 Nov 2013 17:00:44 -0800 (PST) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:51154 helo=[192.168.15.194]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VdrTx-0003MA-4s; Tue, 05 Nov 2013 17:00:37 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_E1B30290-901A-410A-94FD-173EA088D978"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Eric Burger In-Reply-To: Date: Tue, 5 Nov 2013 20:00:27 -0500 Message-Id: References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1816) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:00:52 -0000 --Apple-Mail=_E1B30290-901A-410A-94FD-173EA088D978 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA972DBB-5DE8-484C-B9FB-0E4C9F0B69FA" --Apple-Mail=_AA972DBB-5DE8-484C-B9FB-0E4C9F0B69FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Immediately visible and OK. That is the problem. For state surveillance, = there is no need for secrecy. On Nov 5, 2013, at 7:33 PM, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger = wrote: > I do not see how this can help. In fact, I see this as a very = DANGEROUS proposal. >=20 > The reason is precisely because all this proposal does is mean that = ONLY the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, = their secrets stay secret, so there is no accountability. >=20 > Why do I say this? Because these organizations have the capability to = take the full firehose. They do not need to tap anything, they just = insert an extra router and they are in. No need for messy warrants, = paid-off corporations, or undercover ISP employees that are actually in = the employ of the government. >=20 > I do not get how link encryption helps at all. Please illuminate. >=20 > I am taking it as granted that someone who deploys a $500K router = knows how to initialize the crypto securely and that the systems would = be performing the usual PFS/ephemeral do-winkies.=20 >=20 > So inserting an extra router should be immediately visible. >=20 >=20 > --=20 > Website: http://hallambaker.com/ --Apple-Mail=_AA972DBB-5DE8-484C-B9FB-0E4C9F0B69FA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Immediately visible and OK. That is the problem. For state surveillance, there is no need for secrecy.

On Nov 5, 2013, at 7:33 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:




On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger <eburger@standardstrack.com> wrote:
I do not see how this can help. In fact, I see this as a very DANGEROUS proposal.

The reason is precisely because all this proposal does is mean that ONLY the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their secrets stay secret, so there is no accountability.

Why do I say this? Because these organizations have the capability to take the full firehose. They do not need to tap anything, they just insert an extra router and they are in. No need for messy warrants, paid-off corporations, or undercover ISP employees that are actually in the employ of the government.

I do not get how link encryption helps at all. Please illuminate.

I am taking it as granted that someone who deploys a $500K router knows how to initialize the crypto securely and that the systems would be performing the usual PFS/ephemeral do-winkies. 

So inserting an extra router should be immediately visible.


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

--Apple-Mail=_AA972DBB-5DE8-484C-B9FB-0E4C9F0B69FA-- --Apple-Mail=_E1B30290-901A-410A-94FD-173EA088D978 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPOTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTYwggQeoAMC AQICEQCwcaHVUMvQr+uhWE6z/ys+MA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMDkxMDAwMDAwMFoXDTE0MDkxMDIzNTk1OVowKzEpMCcGCSqG SIb3DQEJARYaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxsTeCcKu2DcGpn/1av3deopvE+iZNMeV5D7uryZzJJlW78DX6Ugtm5v7fDQM0 w+ijJ7JXyIBmjuZMIZVAP/U5NTZ4GpRD3moBiBKHWW/MBDspwVzryfDASZloZIx+8HGefXE6Vstj xJ0q8NnGnCHv7Id6g3ZePlE+2BIvqgLDcQNCa37lC9Yj0/Whac6OCP6Tcy+ezMywoAghNu/FbDY9 HQNLeCBmW+kMTt6vNfUu6roR4Iy2hS9PNsjoZF4x71LIuXIwupFgYBzV3/LnEz0iEKvBTiOf/b1s 5cnNpoTV2Lq784IF+1D1o4HdO5xWId+RrEmev6sLDxGh0VfS1BQ3AgMBAAGjggHqMIIB5jAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUlcezSUOqYMzJfC7DgAgDnv2C ZSowDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpl YnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEARA5ce+WEvcpqZkn1 T6t5U8yN9pwldHwp473Xt552deVY+o0X9iWnjlKqiFSJBKR0jD1/qEmQR4NJiMnak+aP3bxZtAlJ RH/DcmzCFuj9MSAVuiMGLVwYURDtz69M8MuWG3JHXqyyKyTM2dfVnNPv3od58ysHRnD6Sau9jIhi JO18BAV3usIfzGaiiwk/WFP3JuRssfkMFTGAeXzMuDm4smaxb2FMtZTsJIY8yZEOwjg7SnhP6MOr zTLbVOxIBjLsrpWZR4+XJqptgntH8Ic5yjx7d1Oh+zh2uBnOPbQEVC8OL6eoN+BIP1JpUnSG1Ajc ky0WGPCq2V1T8yqVjCqWtDGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAsHGh1VDL0K/roVhOs/8rPjAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMDYwMTAwMjdaMCMGCSqGSIb3DQEJBDEW BBQveXXQXJR6XW8ZJi65aBrEWIJYcTCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsHGh1VDL0K/roVhOs/8rPjCBvAYLKoZIhvcNAQkQAgsx gayggakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCwcaHVUMvQr+uhWE6z /ys+MA0GCSqGSIb3DQEBAQUABIIBAC1NZhfp+fhlBFNPXp4539nIzeBt8Ft7oBhmf8iC8wonJH46 pQUyWXdpsFROHDrHjjALrz7PyH5KpyDI0gqHamJS0rzqr1QBkBLL/WlTkrwYWZHfPQqSouR1ngBc AulUI14fw6I0Po8KCXSKSjjwfAAfyJ5bOdBv45zvCe4mUM7PQ9HYk7u3x5nyREciA765rIXHtUh8 91Abw58gqrAIh4hvqV7wmsEMnXEOZwDg2Y0phUXSUt19hOriRQZiPfNl8ULANguEEu5WVbXJdYU6 9n4zJ7bJNkX7rQiPDxN/RwzSV+ysfaBDWpA1mVygyBSAlb4FpjTk8lR/H2iClpU66O4AAAAAAAA= --Apple-Mail=_E1B30290-901A-410A-94FD-173EA088D978-- From dean.willis@softarmor.com Tue Nov 5 17:01:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A531011E8163 for ; Tue, 5 Nov 2013 17:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppj+oacqzQ7f for ; Tue, 5 Nov 2013 17:01:18 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A17C221F9C55 for ; Tue, 5 Nov 2013 17:00:51 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id q10so9467400pdj.27 for ; Tue, 05 Nov 2013 17:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=odSCrYRCWuDiSLxkYnOZxS3uDtWnBr+N4N6vDiA9TBM=; b=Ngtkia6TSM+8FkqDWH5Vz3hhe78Vz8I0fQSTos6YWPfi6SQAQJGsRQ0lENSFrZcIZ2 rL7iWdTWf1e3Q6byr54VEL46keAFcTE5g0XmiHbV9ekEKBR03LKi7YLrgjjYds7QPvCL dbjFwV2I+FYW9FYRkg39Jto9DBq7zi/sS/xHc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=odSCrYRCWuDiSLxkYnOZxS3uDtWnBr+N4N6vDiA9TBM=; b=JPkI6fRPPfWV31SgodlGaGKTaIqhdm3Iq7/DeUyT5Vi/9FgJ3xv2BRodCAHzhlQXaH Dm8uk5f4k4uKxPNqWznARjiWVVuUJVyaAyaB+ke1yiS8Mmt8UkwkoTJw1a2giAGGtn/S eILf97qb12mds/WRVgeG8kNAL8JkLCV9OGYaNu4izwVhSYLmWy4GUHoy6SznFcdulCCp k16dYNONZM1Q0p1rnT6XafEt3gnqE/2OEyl94Z/nEgMh3milFALPuLkCoxs6LpbRpa92 /WhzhDlyyLNZp1+VAf3RJmmDSv800gGjdQgfbGwVciKdhrsYLvqFHD62vcnuRMTrNPLw mDyw== X-Gm-Message-State: ALoCoQk9IEtfZe4qhNknWK1u+GuAeuUAFkwfaYMDZePTRIz5VtoCh98sE2WLtjSnAUco1vM5Y61J X-Received: by 10.68.28.5 with SMTP id x5mr518335pbg.72.1383699650901; Tue, 05 Nov 2013 17:00:50 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:ddb4:b560:70ef:1c11]) by mx.google.com with ESMTPSA id qf7sm43567710pac.14.2013.11.05.17.00.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 17:00:49 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dean Willis In-Reply-To: <52793C91.9080102@gmail.com> Date: Tue, 5 Nov 2013 19:00:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52791087.1030803@gmail.com> <52793C91.9080102@gmail.com> To: rutkowski.tony@gmail.com X-Mailer: Apple Mail (2.1816) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:01:19 -0000 On Nov 5, 2013, at 12:44 PM, Tony Rutkowski = wrote: > Phill, >=20 > Might I suggest that your characterizations > are far from accurate here, and I would certainly > not denigrate the UK government in this fashion. >=20 > You are, however, evading the key question > repeated below: >> And just how does one get from Phill and friends >> in perpass talking about clever schemes, to "forcing" >> all the governments, vendors, and providers of the >> world to implement those schemes? > ...especially when most those other governments > governments and a great many providers are now > scaling up their activities to instantiate more pervasive > surveillance in the infrastructure. Or, is this all just > an academic exercise? It=92s a matter of setting GAAP-like =93generally accepted best = practices=94 for fiber operations that expose fiber operators to = shareholder and customer lawsuits for failure to implement those best = practices. If Google implements continuous-flow encryption on its fiber, it won=92t = be long before somebody sues Yahoo for not doing the same. If all the US = fiber is secured, it won=92t be long before French companies seek the = same competitive advantage. All we have to do is set the baseline best-practice (possibly in = collaboration with other standards bodies), and market forces will do = the rest. =97 Dean From hallam@gmail.com Tue Nov 5 17:01:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8983E11E8163 for ; Tue, 5 Nov 2013 17:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMkeaWe1n50n for ; Tue, 5 Nov 2013 17:01:19 -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 27ED421F9D8D for ; Tue, 5 Nov 2013 17:00:56 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id z5so7093029lbh.21 for ; Tue, 05 Nov 2013 17:00: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=ZGaKsB2KYyA4Uus9mFxRwp1lU16aFUp6207Sngh5vYA=; b=TpYlsZT+KT3EvHpLjSFxi/Dq1Q8T4URGXRSQFYkSfESxhE3f2sWwfgVRgA1mwjWAuQ ZLO+0kGj33PN0/gsdCY6bxGSMINAL3Y+iYAe9uWLZ3b7V7PbgZMXsOh1SCaYEoEsWBt9 ncHwdB3+dKBV73fzBpP/nopJJhEkatibWSzH95MjfUax5ADrWOIgbc3ik1mHRMwqpv3c jyvKGQy0Jv9u4+8pw/pv99Wa0q5osrEZmk/oSn1YYFdTBd475JSbWK2K4tHdi5rVigFJ DRqJR62aLGUloVbLa8IVFobbgiqZdVxjlK6TDGo8lNIyBCCajE43PHl9SxtEbaWyXYJW 56uw== MIME-Version: 1.0 X-Received: by 10.152.5.162 with SMTP id t2mr255704lat.1.1383699655943; Tue, 05 Nov 2013 17:00:55 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 5 Nov 2013 17:00:55 -0800 (PST) In-Reply-To: <20131105220957.GC14235@thunk.org> References: <20131105220957.GC14235@thunk.org> Date: Tue, 5 Nov 2013 20:00:55 -0500 Message-ID: From: Phillip Hallam-Baker To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary=089e0141a16e77ebe404ea77ae80 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:01:20 -0000 --089e0141a16e77ebe404ea77ae80 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 5:09 PM, Theodore Ts'o wrote: > On Tue, Nov 05, 2013 at 10:01:58AM -0500, Phillip Hallam-Baker wrote: > > The payoff for this effort is a major increase in work factor and in > > particular, forcing an adversary attempting a traffic analysis attack to > > intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of > data > > to store. It is over an exabyte per link per year. Or about a quarter > > million 4Tb hard drives. Or $200 million at $500 per drive (including > > racking etc.) > > That's assuming the attacker is going to attack link-level security > --- which to me sounds like the French assuming the Germans would make > a full frontal assault on the Maginot Line. > > It would seem that a much more intelligent thing for the adversary to > do is to force/induce/send a national security letter/FISA warrant so > as to put the tap between the decryption gear and the default-free > zone router. > And then when the packets cut across multiple jurisdictions, the traffic patterns are hidden unless the governments are willing to cooperate. The technical layer and the political layer are separate. Forcing an attacker to obtain a legal warrant is the desired outcome because that forces a measure of accountability. I note that others have expressed skepticism as to my understanding of the political realities. I suggest that their experience in national politics in general and US politics in particular is almost certainly less than mine. These events have cost Microsoft, Google and the other major US providers of cloud services several billion dollars in lost revenues as customers ask if they can trust US companies. Those companies have plenty of political clout to protect their interests. While corporate interests don't always win in the US system, this is an issue where the corporate interest and public opinion are in very strong agreement. For reasons that will not apply to his successor, the current President had particular reason to rely on the intelligence services, specifically the need to wind down two wars that the US had been losing due to the utter incompetence of his predecessor. Whoever wins in 2016 is not going to be facing those same needs but to get elected they will have to answer the questions raised by the civil rights abuses of the intelligence services now that the Snowden documents have made the issues apparent to the population at large. Gen Alexander has been fired, so has Clapper and so have much of their support staffs. Now that was for the political embarrassment that their incompetent tradecraft has caused the politicians but their successors are not going to be engaging in business as usual. I believe that they are going to have little choice but to concentrate on what should be the core mission of the NSA: defending the US and its allies. -- Website: http://hallambaker.com/ --089e0141a16e77ebe404ea77ae80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 5:09 PM, Theodore Ts'o <tytso@mit.edu&g= t; wrote:
On Tue, Nov 05, 2013 at 10:01:58AM -0500= , Phillip Hallam-Baker wrote:
> The payoff for this effort is a major increase in work factor and in > particular, forcing an adversary attempting a traffic analysis attack = to
> intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of = data
> to store. It is over an exabyte per link per year. Or about a quarter<= br> > million 4Tb hard drives. Or $200 million at $500 per drive (including<= br> > racking etc.)

That's assuming the attacker is going to attack link-level securi= ty
--- which to me sounds like the French assuming the Germans would make
a full frontal assault on the Maginot Line.

It would seem that a much more intelligent thing for the adversary to
do is to force/induce/send a national security letter/FISA warrant so
as to put the tap between the decryption gear and the default-free
zone router.

And then when the packets = cut across multiple jurisdictions, the traffic patterns are hidden unless t= he governments are willing to cooperate.

The techn= ical layer and the political layer are separate. Forcing an attacker to obt= ain a legal warrant is the desired outcome because that forces a measure of= accountability.=A0


I note that others have expressed skepti= cism as to my understanding of the political realities. I suggest that thei= r experience in national politics in general and US politics in particular = is almost certainly less than mine.=A0

These events have cost Microsoft, Google and the = other major US providers of cloud services several billion dollars in lost = revenues as customers ask if they can trust US companies. Those companies h= ave plenty of political clout to protect their interests. While corporate i= nterests don't always win in the US system, this is an issue where the = corporate interest and public opinion are in very strong agreement.

For reasons that will not apply to his successor, the c= urrent President had particular reason to rely on the intelligence services= , specifically the need to wind down two wars that the US had been losing d= ue to the utter incompetence of his predecessor. Whoever wins in 2016 is no= t going to be facing those same needs but to get elected they will have to = answer the questions raised by the civil rights abuses of the intelligence = services now that the Snowden documents have made the issues apparent to th= e population at large.


Gen Alexander has been fired, so has Cla= pper and so have much of their support staffs. Now that was for the politic= al embarrassment that their incompetent tradecraft has caused the politicia= ns but their successors are not going to be engaging in business as usual. = I believe that they are going to have little choice but to concentrate on w= hat should be the core mission of the NSA: defending the US and its allies.=

--
Website: ht= tp://hallambaker.com/
--089e0141a16e77ebe404ea77ae80-- From dean.willis@softarmor.com Tue Nov 5 17:10:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E00921E808F for ; Tue, 5 Nov 2013 17:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-42d7ULZVDz for ; Tue, 5 Nov 2013 17:10:02 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3B21E80CA for ; Tue, 5 Nov 2013 17:10:01 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id w10so9349413pde.2 for ; Tue, 05 Nov 2013 17:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CVKmn03K506tvVncxnE2bVJiQWs40sBdsSigyqzcuwc=; b=gCES4Q/9kk9dm9/4PwTaINhVhFfa2nLI4Q+KnuA8cJ7f7AqYBOwDFI4UOF+P2pmdrN TRAkg/ol4I99oqsgFPZACb6fpn5r3sYRkssQEp/dztj1emUJ1biFfI8a/A5ixYcwGEgs CrE1LqwtWIyKSPcJ6z30qK7Ly2RuShVft3EcM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CVKmn03K506tvVncxnE2bVJiQWs40sBdsSigyqzcuwc=; b=R697w2S8ayxTNXtFVrTVDngen5gkqZz8SYzpSzHhhhYWGfkkS3bHIR80267Q9cw3u+ IWEYr3fmUmnwJ2CVGVa3lqg/BfQs/YiH0f1VOUNkxasuAe7K84BQ/7wLNIXvJ8RoRKYA A//10HYoaJAF4M1clY7MPkKl0lFE4qkZLNUsyVuyYjJDEmK2DZqp2V346yovhOR+2Trw 987MPB3lMZie1/UwfZcsDrdU16POBz+g3cFnigX5EkcpTFgJr7GvuqO2HyeqYLlouy1W Q0nkdT2VzuTfaplIJnBHXDUdcDn3OXXdvEgO0B56C56p0P+zYDwfoTprrryYXTaR7JNN QGUA== X-Gm-Message-State: ALoCoQm9HUFBLPjqSbxrAjgTCscUbNhfYxvUEkrxwTd0kXH0b4lRT4oKTtU8h0YRkMwIB6BV/5hq X-Received: by 10.66.147.9 with SMTP id tg9mr1164433pab.5.1383700201482; Tue, 05 Nov 2013 17:10:01 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:ddb4:b560:70ef:1c11]) by mx.google.com with ESMTPSA id gh3sm16762202pbb.2.2013.11.05.17.10.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 17:10:00 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dean Willis In-Reply-To: <20131105220957.GC14235@thunk.org> Date: Tue, 5 Nov 2013 19:09:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131105220957.GC14235@thunk.org> To: Theodore Ts'o X-Mailer: Apple Mail (2.1816) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:10:03 -0000 On Nov 5, 2013, at 4:09 PM, Theodore Ts'o wrote: > On Tue, Nov 05, 2013 at 10:01:58AM -0500, Phillip Hallam-Baker wrote: >> The payoff for this effort is a major increase in work factor and in >> particular, forcing an adversary attempting a traffic analysis attack = to >> intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of = data >> to store. It is over an exabyte per link per year. Or about a quarter >> million 4Tb hard drives. Or $200 million at $500 per drive (including >> racking etc.) >=20 > That's assuming the attacker is going to attack link-level security > --- which to me sounds like the French assuming the Germans would make > a full frontal assault on the Maginot Line. >=20 Every national security unit with submarine capability implements = undersea fiber taps. Literally, they send out a sub, tap a fiber, mirror = its data onto another =93dark=94 fiber in the bundle (or a fiber leased = to a puppet), and start scraping data =97 mostly =93metadata=94 from the = pipe. Scambling every fiber is going to seriously mess with that sort of = intercept. This is believed to be the attack model executed on Google, tapping = fibers between their data centers. > It would seem that a much more intelligent thing for the adversary to > do is to force/induce/send a national security letter/FISA warrant so > as to put the tap between the decryption gear and the default-free > zone router. Sure. But at least somebody knows who is scraping the data that way. = This requires =93legal=94 mechanisms be deployed. Much of the current = concern is about illegal (or =93secret quasi-legal with no review and no = recourse") intercepts. =97 Dean From dean.willis@softarmor.com Tue Nov 5 17:12:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E6111E81F8 for ; Tue, 5 Nov 2013 17:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIAZXVoOz829 for ; Tue, 5 Nov 2013 17:12:51 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13D21E80D9 for ; Tue, 5 Nov 2013 17:12:49 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so9689605pab.5 for ; Tue, 05 Nov 2013 17:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=L3X7SBZyEyCu1kovoUwMJzdcg3O1YU8i0GBCp/0qfPw=; b=FF+hhJGsrwTlBS1+EFQWuEfNzSjBPTlqnfW2IuFxtkppqYxuifCzXZwNTyL+X/oX2n x7Tee4kiWgyEuuM02Q3pN1CpZbWtRVVe3/tGIY9QsxWV7x/hZcjlfkrrgTl1aWOmArIM kTN/f38PVn3VINnx1WK8Q/DSRhciAe4JTlE54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=L3X7SBZyEyCu1kovoUwMJzdcg3O1YU8i0GBCp/0qfPw=; b=YqPKOxBmc7bjQIg+53/TXU+yMtpx5c4fp2mnFXvJt6HBc6RH1bgN5nO2xQ5CWy00i2 6LFK+LQUNSJDie2dmPbMERxTsy+dwH8mbfrn1jGOXH94wniHZTVsbS0DZlciZrNcqVD/ iOQGhz5sc1GpReIbJjfbxZr/Ggq8ni2mG2ovgL/6Dq3aS7cVXBAsVf3FgHumwRaQSsia qHGCAkDo8i2s/fMoK7tD2c9ZnCtMGkNOEX3lPX89Q6VX7ka3o5ByD+j7Wu8mRlHg9Bbt /xjb61lNVvVshF1rx4rbs2ZScUFynVuE+51J+i4v2E0OZgeExpAjqF4vluaIVfYM9VVL iaeQ== X-Gm-Message-State: ALoCoQkvrac3Cf539iHxGZBxYrBDlOhhkpg1xdeyfoDy36TC+6+etQDB/1fM7FE9mjlyBhqz5nWJ X-Received: by 10.68.236.103 with SMTP id ut7mr535975pbc.118.1383700368922; Tue, 05 Nov 2013 17:12:48 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:ddb4:b560:70ef:1c11]) by mx.google.com with ESMTPSA id gg10sm37369594pbc.46.2013.11.05.17.12.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 17:12:47 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_45D40515-1EA5-4317-8533-9D8D56868413"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dean Willis In-Reply-To: Date: Tue, 5 Nov 2013 19:12:44 -0600 Message-Id: References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1816) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:12:52 -0000 --Apple-Mail=_45D40515-1EA5-4317-8533-9D8D56868413 Content-Type: multipart/alternative; boundary="Apple-Mail=_0382C943-DF99-4CD7-BCCB-08A13008ED32" --Apple-Mail=_0382C943-DF99-4CD7-BCCB-08A13008ED32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 5, 2013, at 7:00 PM, Eric Burger = wrote: > Immediately visible and OK. That is the problem. For state = surveillance, there is no need for secrecy. >=20 Wrong. See, the GCHQ has been surveilling US citizens using taps, and = the NSA has been surveilling UK citizens using taps. Both are allowed to = use covert mechanisms to surveil foreigners. Then they trade data sets = with each other. This is state surveillance, but since it=92s quite reasonably =93illegal=94= , it also requires secrecy. Securing the transit links such that a = =93legal order=94 is required would significantly impact the = interception. =97 Dean --Apple-Mail=_0382C943-DF99-4CD7-BCCB-08A13008ED32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 5, 2013, at 7:00 PM, Eric = Burger <eburger@standardstrack.com&= gt; wrote:

Immediately visible and OK. That is the = problem. For state surveillance, there is no need for = secrecy.


Wrong. See, the = GCHQ has been surveilling US citizens using taps, and the NSA has been = surveilling UK citizens using taps. Both are allowed to use covert = mechanisms to surveil foreigners. Then they trade data sets with each = other.

This is state surveillance, but since = it=92s quite reasonably =93illegal=94, it also requires secrecy. =  Securing the transit links such that a =93legal order=94 is = required would significantly impact the = interception.

=97
Dean

= = --Apple-Mail=_0382C943-DF99-4CD7-BCCB-08A13008ED32-- --Apple-Mail=_45D40515-1EA5-4317-8533-9D8D56868413 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----- iEYEARECAAYFAlJ5l4wACgkQSE0vSqCaet/1RgCdG5Bs5bmRL6E9dh1cKRusYCGZ YEcAoLyrx2kuCmchyK7c1IJ/PKuC2Ap1 =ry1v -----END PGP SIGNATURE----- --Apple-Mail=_45D40515-1EA5-4317-8533-9D8D56868413-- From nweaver@icsi.berkeley.edu Tue Nov 5 17:17:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933F821F9CB5 for ; Tue, 5 Nov 2013 17:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oNX9PatbOI8 for ; Tue, 5 Nov 2013 17:17:22 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id EBF1121F9CAC for ; Tue, 5 Nov 2013 17:17:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 865AC2C403C; Tue, 5 Nov 2013 17:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YRgMgmqL6vIN; Tue, 5 Nov 2013 17:17:21 -0800 (PST) Received: from [10.0.1.14] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0FA132C4011; Tue, 5 Nov 2013 17:17:21 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1557AE4A-AC04-413E-8DF4-86E865F1535D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Tue, 5 Nov 2013 17:17:23 -0800 Message-Id: <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> To: Dean Willis X-Mailer: Apple Mail (2.1510) Cc: Phillip Hallam-Baker , perpass , Nicholas Weaver , Eric Burger Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:17:26 -0000 --Apple-Mail=_1557AE4A-AC04-413E-8DF4-86E865F1535D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 5, 2013, at 5:12 PM, Dean Willis = wrote: >=20 > Wrong. See, the GCHQ has been surveilling US citizens using taps, and = the NSA has been surveilling UK citizens using taps. Both are allowed to = use covert mechanisms to surveil foreigners. Then they trade data sets = with each other. >=20 > This is state surveillance, but since it=92s quite reasonably = =93illegal=94, it also requires secrecy. Securing the transit links = such that a =93legal order=94 is required would significantly impact the = interception. Except that its clear that they already HAVE gotten "legal" orders for = such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, = etc... -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_1557AE4A-AC04-413E-8DF4-86E865F1535D 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 iQIcBAEBCgAGBQJSeZijAAoJEG2B1w+SDi/uJpQP/1kx5JZ0b3I6fHKn9M+1d+Lj bZb+t63UxaUL8FTlkQ9xisPpbJnOFU2I2xRDgd15FASlxE7o8O6fBJEObFeZnvKe Ww5VM5IJ66IILOt6VXhwiecJYzmSIX0iso5r52gvp7Mnwgs7esOQ/Ln3I/gMDaBa 0aSMCFgTcnnMl7KmzJuA+YJzgESUetiPHH+DfYs7QfSuN4fZJ0z3BGh26p6shgSd /rrUjs4GHP00WLokjUPYjga/koFOoRAeUJmFDw1IVupngeimOG92tX0wyaWDBBSM Ai+Y4NcUjjjp593dMlBSCX1g9OENv0RIiPAjelzodkXy611oE64pQREnSe4trqK+ dgr/8wV/NnH/LnINXiSCLSIMmDG1T2MRL3TNSYggdWuMBeRzSgPKsh8swZhd5fnZ dfJQpdfWgmwHuEtdrfO//QaX/memOvGYPmmpcqFrgeBVDaqR3fL4ZbsuACNj6hvu I5mbY6p9U8E+aW3eaVvj+TAzrdibvRm1dmJVsIQ9u5zs6exUVYhBRc8qJ7GEGu05 lx+SQ0I8dA9oGnH+H0SwpqJMxTO227XISPpVAbIKI4qrcA184Jp3qSuoxr60wKEN rmwt7EJgdm0p+LvVlLJqZs/alF9xwnpgJ6Kap8eeNpb0VrVxOvEdwLedEV9Rk2HC RXf/5HkD9d2dKqGuQKst =1HEl -----END PGP SIGNATURE----- --Apple-Mail=_1557AE4A-AC04-413E-8DF4-86E865F1535D-- From eburger@standardstrack.com Tue Nov 5 17:23:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036121E808F for ; Tue, 5 Nov 2013 17:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYhw8IKqIFSi for ; Tue, 5 Nov 2013 17:23:28 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32D21E80F1 for ; Tue, 5 Nov 2013 17:23:26 -0800 (PST) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:51254 helo=[192.168.15.194]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Vdrq8-0007AQ-GP for perpass@ietf.org; Tue, 05 Nov 2013 17:23:25 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_8594BAF6-781F-4A19-8340-2FD5069C32DA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <7D829E9A-6ECC-4A02-A694-F02ED522BC3E@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Date: Tue, 5 Nov 2013 20:23:15 -0500 References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> To: perpass In-Reply-To: <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> X-Mailer: Apple Mail (2.1816) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:23:33 -0000 --Apple-Mail=_8594BAF6-781F-4A19-8340-2FD5069C32DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That=92s my point. On Nov 5, 2013, at 8:17 PM, Nicholas Weaver = wrote: >=20 > On Nov 5, 2013, at 5:12 PM, Dean Willis = wrote: >>=20 >> Wrong. See, the GCHQ has been surveilling US citizens using taps, and = the NSA has been surveilling UK citizens using taps. Both are allowed to = use covert mechanisms to surveil foreigners. Then they trade data sets = with each other. >>=20 >> This is state surveillance, but since it=92s quite reasonably = =93illegal=94, it also requires secrecy. Securing the transit links = such that a =93legal order=94 is required would significantly impact the = interception. >=20 > Except that its clear that they already HAVE gotten "legal" orders for = such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, = etc... >=20 >=20 > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_8594BAF6-781F-4A19-8340-2FD5069C32DA 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 iQIcBAEBAgAGBQJSeZoFAAoJEORoZaSQsc1I6CUP/0N2mluGShpdXMBZa+QPMcVA aJIBUm1ZInsrVXRe6BGfT3dkaBgKE/cIK/NCcPDhDgFwAkKqRu1ejtVMZlPeZ/sx yTacf2olBCoeVVNl6HOynyFAmvDLqy2FauRme/ycodpqcsGbRL5s5K54x/iPN/QI +VBAdIqhH4ivGRCE7hcRQAv8h/KcKxAQFRUkUdST30lMXPW/xCQGPNsz5izvJ7P9 0zHwRbcifkbwyyjioPvG6fiKjTEqioJ2mwBJ89JXrHwGaw6i/XxpYliibKLURzli E5W5HeibcPRsyiZtHP5Pv3zcMbNGu4FGjR4ufMGyUme5fFqJSBx+vDFv5Dh2k3tx ualib42JmhFAHSEZBN7V7PP9yRRAjpsEhhxR5UY0qpalKKj6I4XfiFpQ+9uX2QI7 WLGWzyz5AOA/JNAs2SvT3PreMOOVKLDPGCj+m2rEMHx95KAIUPRBdicgihcxSBlk guwZFysiKiCPQW1BaqMqf4+P2IIhM6xh0XklzM8DFfPUnCf78XrL29PhSbAGStF0 XbaxA9qRxfCOFGjq0yrzjxoY2ttixsqUNUJw6SMPjUAx5sb+szMl3hiJeErDa86b ygkJ/EEmGekfZ8I2IODtdoIx/kNXEGyvl6yHve6tB3iwcceDWZM3P6/krnskqDQ1 k65fDBcF7tWP1M0Svv+R =rt44 -----END PGP SIGNATURE----- --Apple-Mail=_8594BAF6-781F-4A19-8340-2FD5069C32DA-- From huitema@huitema.net Tue Nov 5 17:55:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD611E81B2 for ; Tue, 5 Nov 2013 17:55: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=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1biWLa202bc for ; Tue, 5 Nov 2013 17:55:40 -0800 (PST) Received: from xsmtp02.mail2web.com (xsmtp22.mail2web.com [168.144.250.185]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDDD21E8113 for ; Tue, 5 Nov 2013 17:55:34 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VdsJG-0001fF-G4 for perpass@ietf.org; Tue, 05 Nov 2013 20:55:33 -0500 Received: (qmail 29653 invoked from network); 6 Nov 2013 01:53:26 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[64.114.24.114]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Nov 2013 01:53:26 -0000 From: "Christian Huitema" To: "'Nicholas Weaver'" , "'Dean Willis'" References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> In-Reply-To: <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> Date: Tue, 5 Nov 2013 17:53:24 -0800 Message-ID: <00d201ceda92$fba3a7d0$f2eaf770$@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: AQFa+VvDu2XvulGPHFZM1TwfLkUAZAI2hrkSAfwt+Z8CAFr44wHdSGH5AntlwPSaqtOqUA== Content-Language: en-us Cc: 'perpass' , 'Phillip Hallam-Baker' , 'Eric Burger' Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:55:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Except that its clear that they already HAVE gotten "legal" orders for = such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, = etc... If it was purely legal they would do it above the table, installing a = tap inside the data center themselves. They don=E2=80=99t, and most = companies would find that a wide overreach. Encrypting the links that transport lots of private data to faraway = places look like a reasonable practice. But it is one of many possible = solutions. It may well be more practical to use a form of end-to-end = encryption between the components of the data centers. See classic = debate on end-to-end versus link-by-link, in which end-to-end tends to = win most of the time. - -- Christian Huitema -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSeaESAAoJELba05IUOHVQ754H/0Vkcm9bt45ynKUIMuyPsdTW azAj3LI4gKbPzAdcPiEzbrgDzQAM9BAoLbt3pQybCxMUb99VRzLGZPI8XJDXjLT5 OnEglGSrJcyqAn6fjCE+CHIrppWiTXrrhA+zP85Gc7r4bnVtCXAFcOUf9mfbbAbb cS1sSJA9mFGn7ZjiYd9Mn/a0Jm/JulxZ8FYmmtSzw7hTQbMUq8vm6Z2JOAaIxbZc xSWGcSc2xwYkFaQKvTY5Vj7iNiw66wmmsHg3jMMTGW8RW8LX5BTQMTaqi8gqPdVv YkvyHQErrlKIzWFwfovVWtVvKxzp3fGspfB6pInqf4QfaqM3ESGdoxggFcJw4Zs=3D =3D0UDg -----END PGP SIGNATURE----- From huitema@huitema.net Tue Nov 5 21:27:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB6121E816B for ; Tue, 5 Nov 2013 21:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMUG7fHW-RcS for ; Tue, 5 Nov 2013 21:26:55 -0800 (PST) Received: from xsmtp06.mail2web.com (xsmtp26.mail2web.com [168.144.250.193]) by ietfa.amsl.com (Postfix) with ESMTP id 852DC21E80A8 for ; Tue, 5 Nov 2013 21:26:55 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Vdvdl-0003wN-Oj for perpass@ietf.org; Wed, 06 Nov 2013 00:26:54 -0500 Received: (qmail 28347 invoked from network); 6 Nov 2013 05:26:52 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[64.114.24.114]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Nov 2013 05:26:51 -0000 From: "Christian Huitema" To: "'perpass'" References: <20131106052509.29536.9023.idtracker@ietfa.amsl.com> In-Reply-To: <20131106052509.29536.9023.idtracker@ietfa.amsl.com> Date: Tue, 5 Nov 2013 21:26:51 -0800 Message-ID: <00fe01cedab0$ccafdde0$660f99a0$@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: AQHvSSmOITzeQuY0wZf/Kf0XGTt39JnWzu4A Content-Language: en-us Subject: [perpass] FW: New Version Notification for draft-huitema-perpass-trafficanalysis-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:27:00 -0000 The submission window reopened, I just published the draft that I was = preparing. No change from the version on my personal server, except the = date. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, November 5, 2013 9:25 PM To: Christian Huitema Subject: New Version Notification for = draft-huitema-perpass-trafficanalysis-00.txt A new version of I-D, draft-huitema-perpass-trafficanalysis-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Filename: draft-huitema-perpass-trafficanalysis Revision: 00 Title: Passive Traffic Analysis Threats and Defense Creation date: 2013-11-06 Group: Individual Submission Number of pages: 14 URL: = http://www.ietf.org/internet-drafts/draft-huitema-perpass-trafficanalysis= -00.txt Status: = http://datatracker.ietf.org/doc/draft-huitema-perpass-trafficanalysis Htmlized: = http://tools.ietf.org/html/draft-huitema-perpass-trafficanalysis-00 Abstract: Traffic analysis is used by various entities to derive "meta data" about Internet communications, such as who communicates with whom or what, and when. We analyze how meta-data can be extracted by monitoring IP headers, DNS traffic, and clear-text headers of commonly used protocols. We then propose a series of actions that would make traffic analysis more difficult. = =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. The IETF Secretariat From martin@millnert.se Tue Nov 5 22:21:17 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB4511E820E for ; Tue, 5 Nov 2013 22:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3Er1xqgnKE5 for ; Tue, 5 Nov 2013 22:21:12 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id B9CCB11E8189 for ; Tue, 5 Nov 2013 22:21:11 -0800 (PST) Received: from [192.168.42.188] (c-2ec2d713-74736162.cust.telenor.se [46.194.215.19]) by mail.millnert.se (Postfix) with ESMTPSA id 3C28FB1; Wed, 6 Nov 2013 07:23:20 +0100 (CET) Message-ID: <1383718861.5165.79.camel@galileo.millnert.se> From: Martin Millnert To: Christian Huitema Date: Wed, 06 Nov 2013 07:21:01 +0100 In-Reply-To: <00d201ceda92$fba3a7d0$f2eaf770$@huitema.net> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> <00d201ceda92$fba3a7d0$f2eaf770$@huitema.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4U+KtdfXjOSTeNzqHBj9" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Cc: 'Phillip Hallam-Baker' , 'perpass' , 'Nicholas Weaver' , 'Eric Burger' , 'Dean Willis' Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 06:21:17 -0000 --=-4U+KtdfXjOSTeNzqHBj9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2013-11-05 at 17:53 -0800, Christian Huitema wrote: > Encrypting the links that transport lots of private data to faraway > places look like a reasonable practice. But it is one of many possible > solutions. It may well be more practical to use a form of end-to-end > encryption between the components of the data centers. See classic > debate on end-to-end versus link-by-link, in which end-to-end tends to > win most of the time. If the applications and the complexity of adding end-to-end encryption to them is low in the DC interconnect case, it may be the easiest approach. Also, defense-in-depth. However, with MAC PHY's already available with 802.1AE - MacSEC, doing AES-128 or AES-256 (switches available today!), it's also quite low-hanging-fruit for the data link layer. And this applies for all traffic on a link, and some links are obviously more interesting than others. If for example ISPs renting trans-oceanic wavelengths from cable system operators were to encrypt their router-to-router links, the defensive surface against pervasive surveillance would drastically grow in terms of number of organizations to engage with secret laws. This does make tapping much more complex, and expensive, and really is quite low hanging fruit. Decreasing pervasive surveillance is not an all-or-nothing project. However, before ISPs could begin encrypting their backbone links, there would have to be a business case for doing it, e.g. customers demanding it. What would help, I believe, is some form of standard on how operators do the encryption, that could be included as a MUST in RFQs. This could very well be an RFC. It would also definitely help to get this going that a couple of really large networking enterprises made vendors create/expand products. These would be IEEE, and I wonder if 802.1AE is sufficient already? /M --=-4U+KtdfXjOSTeNzqHBj9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJSed/NAAoJEKgraNdZrwxMHdIP/if0oEISe/ViL+VPRzcHpQ46 coMAr6DEJPdOPQP0+LKdPN1ttZ1swaSYM+GMXxGKahPG9LCJ50WAXmsSuzMaNkaT ghrcf9n0qSnti9dc8DFRCtf8ZX06Wi87VO1odjr/2g+9Lk22uNNKjRf0F0obUlAZ kEZeIM/6W46i+Wb5XHjClP00TU9Pud7qUKj9LA9vy8buwqilf8Ee4n1766UDn2ew OdrKw7TQ8aXnt4zPRtiCryDhNN5XE85HanCVhv2zstYvCOvyfGjM79I/Sg3jcYnd TcsmBuRCR5/sV9qQhnzO0vdFhqeFzkz4IADGFt7bdpH6YTbL9oLYJmbT5qgvCx5u aCAuJKLDi92HM5bn8ZFMM/n6X0lt1lp5CwHo8JxUlDRcGxihmaCy89KusQECwdak z1DhhDyqdCK+oparHVIEnSYPMNWzidb64Cq+dRT4z+zF7nyrtBftprfsqVduT2yE 4CBGdUJhwHW/NDgJ6Yn11vp5AiPauieR2+3IcRw4wyowz+NHdMRZklvVPQnv0TIt Gw/L1v569RbIFQ8iLieZQT9U0c/GrzU3CSa43rkh88J0XHm0qDucFiT3eNeqcYr7 jXh33tIb3T5DCkj7asKz53HUHPj2ggURjQLpYgglbOX18nKr9cRDLojYp8qFKAa0 q+CeWFc/bJaCJYQLvjPk =ekqi -----END PGP SIGNATURE----- --=-4U+KtdfXjOSTeNzqHBj9-- From nb@bollow.ch Wed Nov 6 03:13:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BF921E8088 for ; Wed, 6 Nov 2013 03:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8TPNsKqG38v for ; Wed, 6 Nov 2013 03:13:41 -0800 (PST) Received: from beta.bollow.ch (beta.bollow.ch [193.37.152.11]) by ietfa.amsl.com (Postfix) with ESMTP id 194EA21F9C68 for ; Wed, 6 Nov 2013 03:13:40 -0800 (PST) Received: from quill (66-175.62-81.cust.bluewin.ch [81.62.175.66]) by beta.bollow.ch (Postfix) with ESMTPSA id A5D2A140434; Wed, 6 Nov 2013 12:20:14 +0100 (CET) Date: Wed, 6 Nov 2013 12:13:49 +0100 From: Norbert Bollow To: 'perpass' Message-ID: <20131106121349.0c223af3@quill> In-Reply-To: <00d201ceda92$fba3a7d0$f2eaf770$@huitema.net> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> <00d201ceda92$fba3a7d0$f2eaf770$@huitema.net> Organization: ZielBaum Beratung N. Bollow X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 11:13:47 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpDaHJpc3Rp YW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4gd3JvdGU6DQoNCj4gPiBFeGNlcHQgdGhh dCBpdHMgY2xlYXIgdGhhdCB0aGV5IGFscmVhZHkgSEFWRSBnb3R0ZW4gImxlZ2FsIiBvcmRlcnMN Cj4gPiBmb3Igc3VjaCBzdXJ2ZWlsbGFuY2UuICBFLmcuIEFUJlQgc2VjcmV0IHJvb20sIEdDSFEn cyBkZWFsIHdpdGgNCj4gPiBMZXZlbCAzLCBldGMuLi4NCj4gDQo+IElmIGl0IHdhcyBwdXJlbHkg bGVnYWwgdGhleSB3b3VsZCBkbyBpdCBhYm92ZSB0aGUgdGFibGUsIGluc3RhbGxpbmcgYQ0KPiB0 YXAgaW5zaWRlIHRoZSBkYXRhIGNlbnRlciB0aGVtc2VsdmVzLiBUaGV5IGRvbuKAmXQsIGFuZCBt b3N0IGNvbXBhbmllcw0KPiB3b3VsZCBmaW5kIHRoYXQgYSB3aWRlIG92ZXJyZWFjaC4NCg0KWWVz LCBhbmQgaW4gYWRkaXRpb24gcHVibGljIG9waW5pb24gaXMgcmVsZXZhbnQgaGVyZSB0b28uIA0K DQpXZSBkZWZpbml0ZWx5IG5lZWQgdG8gd29yayBvbiBmb3JjaW5nIGFsbCBzdXJ2ZWlsbGFuY2Ug aW50ZXJjZXB0aW9uIHRvDQpiZSBkb25lIGV4cGxpY2l0bHkgYWJvdmUgdGhlIHRhYmxlLCB0aGF0 IHdpbGwgYmUgYW4gaW1wb3J0YW50IHN0ZXANCmZvcndhcmQuDQoNCj4gRW5jcnlwdGluZyB0aGUg bGlua3MgdGhhdCB0cmFuc3BvcnQgbG90cyBvZiBwcml2YXRlIGRhdGEgdG8gZmFyYXdheQ0KPiBw bGFjZXMgbG9vayBsaWtlIGEgcmVhc29uYWJsZSBwcmFjdGljZS4gQnV0IGl0IGlzIG9uZSBvZiBt YW55DQo+IHBvc3NpYmxlIHNvbHV0aW9ucy4gSXQgbWF5IHdlbGwgYmUgbW9yZSBwcmFjdGljYWwg dG8gdXNlIGEgZm9ybSBvZg0KPiBlbmQtdG8tZW5kIGVuY3J5cHRpb24gYmV0d2VlbiB0aGUgY29t cG9uZW50cyBvZiB0aGUgZGF0YSBjZW50ZXJzLiBTZWUNCj4gY2xhc3NpYyBkZWJhdGUgb24gZW5k LXRvLWVuZCB2ZXJzdXMgbGluay1ieS1saW5rLCBpbiB3aGljaCBlbmQtdG8tZW5kDQo+IHRlbmRz IHRvIHdpbiBtb3N0IG9mIHRoZSB0aW1lLg0KDQpFdmVuIHdoZW4gZW5kLXRvLWVuZCBlbmNyeXB0 aW9uIG9mIGFsbCBjb21tdW5pY2F0aW9ucyBjb250ZW50IGlzDQppbXBsZW1lbnRlZCwgdGhlcmUg aXMgc3RpbGwgdGhlIGlzc3VlIG9mIHRyYWZmaWMgYW5hbHlzaXMgcmV2ZWFsaW5nIOKAnHdobw0K Y29tbXVuaWNhdGVkIHdpdGggd2hvbS93aXRoIHdoYXQgc2VydmljZeKAnSBpbmZvcm1hdGlvbi4N Cg0KRW5jcnlwdGluZyBsaW5rcyB3aWxsIHJlZHVjZSB0aGUgYXR0YWNrIHN1cmZhY2UgaW4gcmVn YXJkIHRvIHRoYXQuDQoNCkdyZWV0aW5ncywNCk5vcmJlcnQNCi0tLS0tQkVHSU4gUEdQIFNJR05B VFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjEyIChHTlUvTGludXgpDQoNCmlEOERCUUZT ZWlSdEdBOUMzRFNBM1pvUkFndkJBS0N4MzBEOVlyeTFhTmY0NkFUb0M3NmNUR0kxK1FDZU03UTkN ClZldEkzaFM1czhERHcyOHlOamk5dThvPQ0KPVBnN1kNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUt LS0tLQ0K From hhalpin@w3.org Wed Nov 6 03:48:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605ED21E80AD for ; Wed, 6 Nov 2013 03:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIJmAa49aLaQ for ; Wed, 6 Nov 2013 03:48:42 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id ECDE521E8088 for ; Wed, 6 Nov 2013 03:48:41 -0800 (PST) Received: from men75-11-88-175-104-179.fbx.proxad.net ([88.175.104.179] helo=[192.168.1.44]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ve1bE-0000MO-Bn for perpass@ietf.org; Wed, 06 Nov 2013 06:48:40 -0500 Message-ID: <527A2C91.2030001@w3.org> Date: Wed, 06 Nov 2013 12:48:33 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [perpass] Great Critique of Lavabit - Client-encryption in the Web? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 11:48:46 -0000 I'm not sure what the plan is with the much hyped "Darkmail Initiative to replace email", but here's a great essay on how absurd Lavabit's security measures were as regards securing email: http://www.thoughtcrime.org/blog/lavabit-critique/ In essence, sending everything around in plaintext and then encrypting on the server obviously doesn't count as secure email. I'd be interested in what people think are the best methods for doing client-side encrypted email. In particular, Moxie notes that encrypted email is impossible to do due to lack of a usable non-Web mail client (I used to use Mutt, then moved to Thunderbird+Enigmail, but with every passing day Thunderbird gets worse and worse - perhaps due to Mozilla abandoning it.) since "Despite what anyone tells you, end to end encrypted email is not possible in a webmail world." My question is: What could the W3C due to encourage client-side encryption? In particular, could we one day have encrypted communications in the webworld? Right now the Web Security Model essentially states that the host is trusted 100%, but after the NSA revelations, for some use-cases this is obviously no longer enough, and it would be better to store data on the server client-encrypted. The W3C WebCrypto Working Group [1]'s API should enable client-side use of trusted crypto primitivies, but that's only one piece of the puzzle. What other parts are needed? For example, currently the Web Crypto API allow JS to set the private key, then some simple JS tricks can be used to achieve everything that a developer might want: effective key extraction, effective supercookie, etc. due to the fact that currently the API does not guarantee on providing secure key storage with the user agent and there is no user dialogue required to set a private key to extractable. Another example would be that updates on the Web require trusting the website to always update the Javascript code correctly. However, one is often not sure how much Javascript is being imported from foreign sources, or even if the server is attempting to maliciously rewrite the Javascript Code. While work such as Thandy/TUF allows this problem to be solved for normal software updates [2], there is no secure updating mechanism for Javascript. One option would be for code to have integrity checks and be signed, and allow a diverse set of Javascript repositories then check the integrity check and signature via network perspectives across multiple repositories before executing the code. There's obviously a lot of work to do. While the W3C has been fairly silent so far on this list, as a personal position I am completely against mass surveillance as I believe it's against the principles of a free society. We need to improve our standards to make mass surveillance much, much more difficult. Good luck today everyone at IETF - wish I was there! yours, harry [1] http://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html [2] http://google-opensource.blogspot.fr/2009/03/thandy-secure-update-for-tor.html From rutkowski.tony@gmail.com Wed Nov 6 04:34:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6958C11E8107 for ; Wed, 6 Nov 2013 04:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY24MZrK1tIQ for ; Wed, 6 Nov 2013 04:34:00 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D56A811E8104 for ; Wed, 6 Nov 2013 04:33:59 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id i7so5718102qcq.2 for ; Wed, 06 Nov 2013 04:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YJuJPXDRPtNOItbtCw8lNGtrMMdfGhgm44mLIall9Sg=; b=lzhMMCUJlMD3TbQz2KVXyQCppOFJWvCNnB4yijIIBiTdV5alib6b4O1dPQSa2/lbc3 804AjfHKuexqAJYsOh1YJMQcTiPM2225cFuQhk+F8yWsAVrSqYNVwcFxhatYT5+QHxsU 6El3JWoiIf72btKo0CuXSP7w7whsje93QmhqjsuyK6PmsUw5PovaXgR8ec9MwWHB6Jq6 k/0qUBs6iZ7Wx384sSw+auuyuwsTS3TBWMVaDBTkfisynHjnOse1KmewzH5UcXpPMIhE DyWhVrFlY3AVhTzbCkbTar3bwia+tEUeuGl7KB7tloQyx3MHMTTrVVnSg58aC7xCtkZk n7Ww== X-Received: by 10.49.70.129 with SMTP id m1mr3855124qeu.69.1383741239404; Wed, 06 Nov 2013 04:33:59 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id r5sm78898634qaj.13.2013.11.06.04.33.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 04:33:58 -0800 (PST) Message-ID: <527A3734.4080708@gmail.com> Date: Wed, 06 Nov 2013 07:33:56 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christian Huitema , 'perpass' References: <20131106052509.29536.9023.idtracker@ietfa.amsl.com> <00fe01cedab0$ccafdde0$660f99a0$@huitema.net> In-Reply-To: <00fe01cedab0$ccafdde0$660f99a0$@huitema.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] FW: New Version Notification for draft-huitema-perpass-trafficanalysis-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 12:34:00 -0000 Hi Christian, How do you plan to evade the EU Data Retention Directive? There are also clones in most other regions. If you don't collect the metadata, you are not in business. It is probably represents the world's largest metadata store. The eDiscovery requirements being implemented by judicial systems worldwide require similar large metadata stores to deal with civil litigation evidential requests. The major networks in the U.S. ran a major bust of Internet based pedophiles, estimating the active population in excess of 1/2 million. The call was for more pervasive surveillance, and a new global initiative was announced. Lastly, KitKat seems to have more cool features announced every day that provide linkages to large commercial data stores. Seems like it's worth considering Scott McNealy's admonition to "get over it." On the other hand, it is fun at the wonk level to see all the schemes that someone might pick up for some closed user group. They just won't be in the public infrastructure. --tony From rutkowski.tony@gmail.com Wed Nov 6 04:55:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09B811E819F for ; Wed, 6 Nov 2013 04:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSYwXFPr7VXX for ; Wed, 6 Nov 2013 04:55:27 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 213D011E8195 for ; Wed, 6 Nov 2013 04:55:27 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id n9so5828651qcw.15 for ; Wed, 06 Nov 2013 04:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=n4JJvmqzVi6eXMzMJEbcA0+nEJrqxtNYzJMw1OwwQck=; b=XoUuZHq7GYQbKN8jT9t2bzxB+nj7d+zi/X39Zr0JRhmM/ulIDV/SHJIGaGHkTM0p6+ zvc9u2AJbseNRNYsRYoH7+s9pmlmbAs559WXLHw0nJOojjgZckJayWC3uvAEI5cRau6w 4zQsur/8OAnyI+D3GRfwoyA8KRXMm4TXA1qQDUmz15NjcufPouyL9P9VcyPZHN5YmM+O JbQusEDsYYOTmxsEjnBE7VftEgDo3MBr9gO7h3kidG3XPiPj5zO24pIH7BNOAJOm93B8 JEQZfJlTEVRQUzkqJwmQv+0+Ir8Z+M2Ljh21Vt1BUYyDxeFyqETN82rTUvpcAP/+MGkN O0Uw== X-Received: by 10.229.65.201 with SMTP id k9mr4243408qci.11.1383742526710; Wed, 06 Nov 2013 04:55:26 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id ge5sm69306466qeb.5.2013.11.06.04.55.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 04:55:26 -0800 (PST) Message-ID: <527A3C3D.1070209@gmail.com> Date: Wed, 06 Nov 2013 07:55:25 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Norbert Bollow , 'perpass' References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> <00d201ceda92$fba3a7d0$f2eaf770$@huitema.net> <20131106121349.0c223af3@quill> In-Reply-To: <20131106121349.0c223af3@quill> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 12:55:27 -0000 You might want to consider getting on the new EC advisory committee in Brussels that is dealing with expanding the Data Retention Directive. You can go via Berne where Switzerland has already decided to be in full compliance. But you can always express your views there. --tony On 11/6/2013 6:13 AM, Norbert Bollow wrote: > Even when end-to-end encryption of all communications content is > implemented, there is still the issue of traffic analysis revealing “who > communicated with whom/with what service†information. > > Encrypting links will reduce the attack surface in regard to that. From rutkowski.tony@gmail.com Wed Nov 6 05:25:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C00121E8116 for ; Wed, 6 Nov 2013 05:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 628xlmBruZbX for ; Wed, 6 Nov 2013 05:25:52 -0800 (PST) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1A19A21E80D3 for ; Wed, 6 Nov 2013 05:25:52 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id a11so6058620qen.8 for ; Wed, 06 Nov 2013 05:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yfhNR1JI05zPL5HsXZNBp/weM8Y1GEptahkghQnp/l0=; b=M0dyqSSZAksKHW5cwWF4StysOBznmcvFCcxZxKiI8ObYAGp0cGLGsbKjbQ5jqZA5ZR KHFZUJWm2EQOqGkuZPQLi8EjdEPnJCTZXrrMQqSQ/eqbzomJpyKQqvRuF5xU+gqZnUir 8vyOwL6GEziabgZrY+3JrPP3lzndFkNZpWFEN1HwgBHCwSunRMWtmhMtBPkAh1cLz3IX f0DPj6iiYYA76amOsPusSkNF4FGSKtccCi6W048PB0jCXCvz9YmvrQk4evOxEn6BOhwc evdRh1nMWDTSfNU+CY1v3o5ByAqh2+QKjqJagBOO9dv9k9YY/DDk09LvX9vhvrnwFa+p B3zg== X-Received: by 10.224.151.140 with SMTP id c12mr1691305qaw.125.1383744351322; Wed, 06 Nov 2013 05:25:51 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id r5sm69529136qeh.1.2013.11.06.05.25.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 05:25:50 -0800 (PST) Message-ID: <527A435D.9050204@gmail.com> Date: Wed, 06 Nov 2013 08:25:49 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20131105220957.GC14235@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:25:52 -0000 Wow, this list is getting deeply technical. :-) What it does provide, however, is some insight into underlying motivations and use cases. Pervasive surveillance exists in every nation. It has existed since the first bit went over a transport path. The value of pervasive surveillance for commercial and governmental purposes is scaling dramatically worldwide. It's value is being constantly demonstrated, and end users seem to appreciate it. It is required my multiple legal and regulatory mandates. To raise another Scott McNealy metaphor - what is occurring here is like someone going down to the Amazon river near its mouth, dipping one's hand into the water, and shouting stop. Have fun at your session. --tony From york@isoc.org Wed Nov 6 06:32:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E53F21E8114 for ; Wed, 6 Nov 2013 06:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inf4N83Xc8XX for ; Wed, 6 Nov 2013 06:32:39 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 175C611E8195 for ; Wed, 6 Nov 2013 06:32:39 -0800 (PST) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.800.7; Wed, 6 Nov 2013 14:32:27 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.179]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.186]) with mapi id 15.00.0800.005; Wed, 6 Nov 2013 14:32:27 +0000 From: Dan York To: "perpass@ietf.org" Thread-Topic: Additional jabber scribes for today's perpass session? (primarily to sit near microphones and capture people's names) Thread-Index: AQHO2v0D+DxOZ1TvU0y1F94gfbpXGw== Date: Wed, 6 Nov 2013 14:32:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(189002)(199002)(31966008)(80022001)(47976001)(36756003)(15202345003)(56816003)(47446002)(74502001)(74662001)(76796001)(4396001)(76176001)(2656002)(76786001)(63696002)(83072001)(77096001)(65816001)(50986001)(19580395003)(81342001)(51856001)(80976001)(81542001)(16236675002)(46102001)(74366001)(15395725003)(15975445006)(69226001)(54316002)(49866001)(74706001)(77982001)(47736001)(79102001)(19580405001)(74876001)(81816001)(56776001)(53806001)(85306002)(76482001)(59766001)(54356001)(87266001)(81686001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.5; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE9F92F83E5C9yorkisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: [perpass] Additional jabber scribes for today's perpass session? (primarily to sit near microphones and capture people's names) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:32:43 -0000 --_000_CE9F92F83E5C9yorkisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would anyone else be willing to help out as an additional jabber scribe for= today's perpass session in Regency D at 1:00pm? Stephen has me listed as = the Jabber scribe for today's session... and I'm definitely glad to do that= ... but I'd love to have some assistance. In particular, I suspect that th= is session is going to have: 1. a good number of remote attendees (meaning more questions/comments to re= lay to the mic); 2. a good number of people going to the microphones. It's this second point that's a challenge. I know for remote attendees (an= d for the record) it is very helpful to get the names in the jabber room bu= t even when people say their names clearly at the microphone it's not alway= s easy to capture that for the chat room[1]. I'm going to sit by the front= microphone where it will be easier to see people's nametags... but there i= s also a back microphone in Regency D (assuming the same configuration as y= esterday). Would someone be willing to sit near that back microphone and capture names= for the jabber room of people who speak there? Also, just having someone else near both microphones would be helpful for t= he times when I (or another jabber scribe) am going to the mic to relay a q= uestion or comment. So if we had two other people willing to act as backup= s for myself and whoever is near the back mic that would also be helpful. = I'm glad to get in line and do relays so I just really need people willing= to capture names for the chat. If you are willing to help, please let me know. Thanks, Dan [1] And yes, we can now have the zillion conversations about how this would= be so much better if we had some kind of name reading device at the microp= hones using bar codes, QR codes, RFID chips, tattoos, IPv6 addresses, spec= ial buttons or whatever other technology we want... but none of those conve= rsations help us with the perpass session at 13:00 today. :-) -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_CE9F92F83E5C9yorkisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <5EFFA4A277BA614C99943910BFEBDC34@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Would anyone else be willing to help out as an additional jabber scrib= e for today's perpass session in Regency D at 1:00pm?  Stephen has me = listed as the Jabber scribe for today's session... and I'm definitely glad = to do that... but I'd love to have some assistance.  In particular, I suspect that this session is going to h= ave:

1. a good number of remote attendees (meaning more questions/comments = to relay to the mic);
2. a good number of people going to the microphones.

It's this second point that's a challenge.  I know for remote att= endees (and for the record) it is very helpful to get the names in the jabb= er room but even when people say their names clearly at the microphone it's= not always easy to capture that for the chat room[1].  I'm going to sit by the front microphone where it = will be easier to see people's nametags... but there is also a back microph= one in Regency D (assuming the same configuration as yesterday).  &nbs= p;

Would someone be willing to sit near that back microphone and capture = names for the jabber room of people who speak there?

Also, just having someone else near both microphones would be helpful = for the times when I (or another jabber scribe) am going to the mic to rela= y a question or comment.  So if we had two other people willing to act= as backups for myself and whoever is near the back mic that would also be helpful.   I'm glad to get in li= ne and do relays so I just really need people willing to capture names for = the chat.

If you are willing to help, please let me know.

Thanks,
Dan


[1] And yes, we can now have the zillion conversations about how this = would be so much better if we had some kind of name reading device at the m= icrophones using bar codes, QR codes, RFID chips,  tattoos, IPv6 addre= sses, special buttons or whatever other technology we want... but none of those conversations help us with the per= pass session at 13:00 today.  :-)

--
Dan York
Senior Content Strategist, Internet = Society
york@isoc.org <mailto:york@isoc.o= rg>   +1-802-735-1624
Jabber: york@jabber.isoc.org <mai= lto:york@jabber.isoc.org>
Skype: danyork   http://twitter= .com/danyork

http://www.internetsociety.org/deplo= y360/ 
--_000_CE9F92F83E5C9yorkisocorg_-- From stephen.farrell@cs.tcd.ie Wed Nov 6 07:37:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A3B11E8150 for ; Wed, 6 Nov 2013 07:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgdN8IDy5Fq1 for ; Wed, 6 Nov 2013 07:37:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC711E80E6 for ; Wed, 6 Nov 2013 07:37:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8105BBE9A; Wed, 6 Nov 2013 15:37: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 U6NF3ZzRl+Zx; Wed, 6 Nov 2013 15:37:39 +0000 (GMT) Received: from [31.133.165.162] (dhcp-a5a2.meeting.ietf.org [31.133.165.162]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A78D0BE8A; Wed, 6 Nov 2013 15:37:38 +0000 (GMT) Message-ID: <527A6240.1010703@cs.tcd.ie> Date: Wed, 06 Nov 2013 15:37:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dan York , "perpass@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Additional jabber scribes for today's perpass session? (primarily to sit near microphones and capture people's names) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:38:00 -0000 Thanks you Dan - good idea. S. On 11/06/2013 02:32 PM, Dan York wrote: > Would anyone else be willing to help out as an additional jabber scribe for today's perpass session in Regency D at 1:00pm? Stephen has me listed as the Jabber scribe for today's session... and I'm definitely glad to do that... but I'd love to have some assistance. In particular, I suspect that this session is going to have: > > 1. a good number of remote attendees (meaning more questions/comments to relay to the mic); > 2. a good number of people going to the microphones. > > It's this second point that's a challenge. I know for remote attendees (and for the record) it is very helpful to get the names in the jabber room but even when people say their names clearly at the microphone it's not always easy to capture that for the chat room[1]. I'm going to sit by the front microphone where it will be easier to see people's nametags... but there is also a back microphone in Regency D (assuming the same configuration as yesterday). > > Would someone be willing to sit near that back microphone and capture names for the jabber room of people who speak there? > > Also, just having someone else near both microphones would be helpful for the times when I (or another jabber scribe) am going to the mic to relay a question or comment. So if we had two other people willing to act as backups for myself and whoever is near the back mic that would also be helpful. I'm glad to get in line and do relays so I just really need people willing to capture names for the chat. > > If you are willing to help, please let me know. > > Thanks, > Dan > > > [1] And yes, we can now have the zillion conversations about how this would be so much better if we had some kind of name reading device at the microphones using bar codes, QR codes, RFID chips, tattoos, IPv6 addresses, special buttons or whatever other technology we want... but none of those conversations help us with the perpass session at 13:00 today. :-) > > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stpeter@stpeter.im Wed Nov 6 07:42:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D946821E8120 for ; Wed, 6 Nov 2013 07:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OruwzwmG2H93 for ; Wed, 6 Nov 2013 07:41:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 941DE21E811D for ; Wed, 6 Nov 2013 07:41:57 -0800 (PST) Received: from [192.168.0.42] (unknown [96.49.119.200]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BE354032B; Wed, 6 Nov 2013 08:41:57 -0700 (MST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9EDEF96E-5C06-465A-A642-EBB2C2FF1E2B Content-Transfer-Encoding: 7bit Message-Id: <6D1752EF-4281-410C-9B96-419CA833137D@stpeter.im> X-Mailer: iPhone Mail (10B329) From: Peter Saint-Andre Date: Wed, 6 Nov 2013 07:41:55 -0800 To: Dan York Cc: "perpass@ietf.org" Subject: Re: [perpass] Additional jabber scribes for today's perpass session? (primarily to sit near microphones and capture people's names) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:42:02 -0000 --Apple-Mail-9EDEF96E-5C06-465A-A642-EBB2C2FF1E2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dan, I can cover the back mic.=20 Sent from mobile, might be terse=20 On Nov 6, 2013, at 6:32 AM, Dan York wrote: > Would anyone else be willing to help out as an additional jabber scribe fo= r today's perpass session in Regency D at 1:00pm? Stephen has me listed as t= he Jabber scribe for today's session... and I'm definitely glad to do that..= . but I'd love to have some assistance. In particular, I suspect that this s= ession is going to have: >=20 > 1. a good number of remote attendees (meaning more questions/comments to r= elay to the mic); > 2. a good number of people going to the microphones. >=20 > It's this second point that's a challenge. I know for remote attendees (a= nd for the record) it is very helpful to get the names in the jabber room bu= t even when people say their names clearly at the microphone it's not always= easy to capture that for the chat room[1]. I'm going to sit by the front m= icrophone where it will be easier to see people's nametags... but there is a= lso a back microphone in Regency D (assuming the same configuration as yeste= rday). =20 >=20 > Would someone be willing to sit near that back microphone and capture name= s for the jabber room of people who speak there? >=20 > Also, just having someone else near both microphones would be helpful for t= he times when I (or another jabber scribe) am going to the mic to relay a qu= estion or comment. So if we had two other people willing to act as backups f= or myself and whoever is near the back mic that would also be helpful. I'm= glad to get in line and do relays so I just really need people willing to c= apture names for the chat. >=20 > If you are willing to help, please let me know. >=20 > Thanks, > Dan >=20 >=20 > [1] And yes, we can now have the zillion conversations about how this woul= d be so much better if we had some kind of name reading device at the microp= hones using bar codes, QR codes, RFID chips, tattoos, IPv6 addresses, speci= al buttons or whatever other technology we want... but none of those convers= ations help us with the perpass session at 13:00 today. :-) >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-9EDEF96E-5C06-465A-A642-EBB2C2FF1E2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Dan, I can cover the back mic. 

Sent from mobile, might be terse 

On Nov 6, 2013, at 6:32 AM, Dan York <york@isoc.org> wrote:

Would anyone else be willing to help out as an additional jabber scribe for today's perpass session in Regency D at 1:00pm?  Stephen has me listed as the Jabber scribe for today's session... and I'm definitely glad to do that... but I'd love to have some assistance.  In particular, I suspect that this session is going to have:

1. a good number of remote attendees (meaning more questions/comments to relay to the mic);
2. a good number of people going to the microphones.

It's this second point that's a challenge.  I know for remote attendees (and for the record) it is very helpful to get the names in the jabber room but even when people say their names clearly at the microphone it's not always easy to capture that for the chat room[1].  I'm going to sit by the front microphone where it will be easier to see people's nametags... but there is also a back microphone in Regency D (assuming the same configuration as yesterday).   

Would someone be willing to sit near that back microphone and capture names for the jabber room of people who speak there?

Also, just having someone else near both microphones would be helpful for the times when I (or another jabber scribe) am going to the mic to relay a question or comment.  So if we had two other people willing to act as backups for myself and whoever is near the back mic that would also be helpful.   I'm glad to get in line and do relays so I just really need people willing to capture names for the chat.

If you are willing to help, please let me know.

Thanks,
Dan


[1] And yes, we can now have the zillion conversations about how this would be so much better if we had some kind of name reading device at the microphones using bar codes, QR codes, RFID chips,  tattoos, IPv6 addresses, special buttons or whatever other technology we want... but none of those conversations help us with the perpass session at 13:00 today.  :-)

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org <mailto:york@isoc.org>   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--Apple-Mail-9EDEF96E-5C06-465A-A642-EBB2C2FF1E2B-- From stephen.farrell@cs.tcd.ie Wed Nov 6 07:46:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95A621F9DAD for ; Wed, 6 Nov 2013 07:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adV8j-WNwp8i for ; Wed, 6 Nov 2013 07:45:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2534511E8155 for ; Wed, 6 Nov 2013 07:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4CD4FBE9C; Wed, 6 Nov 2013 15:45:57 +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 xs8CNCZywULt; Wed, 6 Nov 2013 15:45:55 +0000 (GMT) Received: from [31.133.165.162] (dhcp-a5a2.meeting.ietf.org [31.133.165.162]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCF4EBE8A; Wed, 6 Nov 2013 15:45:54 +0000 (GMT) Message-ID: <527A6430.50309@cs.tcd.ie> Date: Wed, 06 Nov 2013 15:45:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Peter Saint-Andre , Dan York References: <6D1752EF-4281-410C-9B96-419CA833137D@stpeter.im> In-Reply-To: <6D1752EF-4281-410C-9B96-419CA833137D@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" Subject: Re: [perpass] Additional jabber scribes for today's perpass session? (primarily to sit near microphones and capture people's names) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:46:02 -0000 On 11/06/2013 03:41 PM, Peter Saint-Andre wrote: > Dan, I can cover the back mic. And thanks Peter, S > > Sent from mobile, might be terse > > On Nov 6, 2013, at 6:32 AM, Dan York wrote: > >> Would anyone else be willing to help out as an additional jabber scribe for today's perpass session in Regency D at 1:00pm? Stephen has me listed as the Jabber scribe for today's session... and I'm definitely glad to do that... but I'd love to have some assistance. In particular, I suspect that this session is going to have: >> >> 1. a good number of remote attendees (meaning more questions/comments to relay to the mic); >> 2. a good number of people going to the microphones. >> >> It's this second point that's a challenge. I know for remote attendees (and for the record) it is very helpful to get the names in the jabber room but even when people say their names clearly at the microphone it's not always easy to capture that for the chat room[1]. I'm going to sit by the front microphone where it will be easier to see people's nametags... but there is also a back microphone in Regency D (assuming the same configuration as yesterday). >> >> Would someone be willing to sit near that back microphone and capture names for the jabber room of people who speak there? >> >> Also, just having someone else near both microphones would be helpful for the times when I (or another jabber scribe) am going to the mic to relay a question or comment. So if we had two other people willing to act as backups for myself and whoever is near the back mic that would also be helpful. I'm glad to get in line and do relays so I just really need people willing to capture names for the chat. >> >> If you are willing to help, please let me know. >> >> Thanks, >> Dan >> >> >> [1] And yes, we can now have the zillion conversations about how this would be so much better if we had some kind of name reading device at the microphones using bar codes, QR codes, RFID chips, tattoos, IPv6 addresses, special buttons or whatever other technology we want... but none of those conversations help us with the perpass session at 13:00 today. :-) >> >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >> >> http://www.internetsociety.org/deploy360/ >> _______________________________________________ >> 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 > From benl@google.com Wed Nov 6 08:05:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4821E8142 for ; Wed, 6 Nov 2013 08:05:21 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5pR+lsW6Jmb for ; Wed, 6 Nov 2013 08:05:21 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC621E8140 for ; Wed, 6 Nov 2013 08:05:20 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id jz11so3739994veb.34 for ; Wed, 06 Nov 2013 08:05:20 -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=qZIs2K+tzxB1n+0O0PONsMWaxF6Fh4zfVwvHGDUd5L0=; b=ULQJS6ZySyO2BSjyg3JNpiBFtatHfdeJrcx9OXj5/YGTxdm++8Hdr2Jn2shR01XA0I bXIMoJwi3Y98kTi8gGvXqjGZKbSlFf7xGYpjYsnfoaE7VwWRNcOP9TY0iu8rAp1mJCub k+G/+YSDnGcGAr6MN2Ec42lFHAd/80UY2NwwWswbHmbp9P+IEocj3CNqwbVHF3bVkIP9 Ik37oWseaZvOTpg9a9i/qKpE7gz6vDEdzJZoenfIjQfUxYG1I+X/vnbWij8ltf+30GnH +qnu/qswcAlYvLvohTzCO6HXIaQiotmtduvU2lk7kTDBm+hOMBQz59WNft+r1LXK1cG4 KLzw== 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=qZIs2K+tzxB1n+0O0PONsMWaxF6Fh4zfVwvHGDUd5L0=; b=mZUi+zfdiPYTtnpt6NPHKG1osJFVz7OBHppiI3Bl0QHO0iicBwSzSfoJNykZtdag2c 03GU6bqXEq15BvYDDC3XRYotogNWOcke5NZb4rNASlpFHA0+v2/5bmxdpC376AbANqk6 MfQdA6Mv/YtXZUObjjpFxXrnpUxgRYbfErPWAoLpp2uO5GzO6T0jgmXMnS0L2Ayqu9dO YGwBUMMYMugIa0C8vfnJhmYaFGP7vYu6M6CM+dvRSo/Qd8Lv1ig7RdDwWb4RTuUAGeq6 EVwtvjopZexIZj7yyqauIvfLOx6RhTcm5ytP3AA3Jc5COq3DGHZubBPKeIX5muJzFQZr 0Jnw== X-Gm-Message-State: ALoCoQnOIKAdc0CkyTIGjm6SsrVwoghuo1pgCcwDh3VFFLy6yZcKulR/ZWx9q+PQpa+aS/EUZFcWy+BYpUhjeeVarB8DmwlyawTDhlYJZRM3pW5VCfwBaTvsRVBAUzy2I0gZ8HcVf63p6Cahz5CC4TjmCk7snGufGI36V1VJ9YmeIdmRO3+9KLQ/eJQsSUpsTyG6OuGITVRZ MIME-Version: 1.0 X-Received: by 10.58.156.106 with SMTP id wd10mr3040528veb.7.1383753920416; Wed, 06 Nov 2013 08:05:20 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 6 Nov 2013 08:05:20 -0800 (PST) In-Reply-To: References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> Date: Wed, 6 Nov 2013 16:05:20 +0000 Message-ID: From: Ben Laurie To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Cc: "perpass@ietf.org" , Cullen Jennings Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:05:21 -0000 On 5 November 2013 00:00, Dan York wrote: > But I want to detect the bad cert *before* someone goes to a site (or in > the process of going to a site). I agree that this capability of tracking > issued certs would be VERY useful in detection of compromised certs... but > this doesn't necessarily seem to me something that can work in real-time. > It can be something used to figure out what happened after-the-fact... but > in the meantime someone has already gone to to the bad site that they > thought was legit. > > The advantage of DNSSEC/DANE is that the bogus cert can be detected before > someone actually goes to the site. If the fingerprint of the cert stored > in the TLSA record (and signed with DNSSEC) doesn't match the fingerprint > of the cert being offered by the server... then the app knows there is a > problem. However. there are several real-world downsides. Most glaring: 1. In quite a lot of cases (experiments suggest around 4%), clients cannot fetch DNSSEC records (nor TLSA records). 2. DNSSEC has its equivalent of CAs: registries and registrars. Their track records on misissuance are not better than CAs. From kent@bbn.com Wed Nov 6 09:06:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57DA21F9E0B for ; Wed, 6 Nov 2013 09:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8TLUl-OntNJ for ; Wed, 6 Nov 2013 09:06:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDD21F9E68 for ; Wed, 6 Nov 2013 09:06:44 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48821 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ve6Z1-0006OZ-6W for perpass@ietf.org; Wed, 06 Nov 2013 12:06:44 -0500 Message-ID: <527A7720.7050008@bbn.com> Date: Wed, 06 Nov 2013 12:06:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:06:50 -0000 Ben, > However. there are several real-world downsides. Most glaring: > > 1. In quite a lot of cases (experiments suggest around 4%), clients > cannot fetch DNSSEC records (nor TLSA records). > > 2. DNSSEC has its equivalent of CAs: registries and registrars. Their > track records on misissuance are not better than CAs. I don't argue with your first point, but I expect this problem to diminish over time The second statement, though, is not a reasonable comparison. registrars operate with the equivalent of name constraints, from a cert issuance perspective, which makes it much better that the WebPKI TA model. Even if the TAs in that model were to issue certs including a name constraints extension, the effect would not be as good as what we have in the DNSSEC/DANE environment. Steve From benl@google.com Wed Nov 6 09:32:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1521E814F for ; Wed, 6 Nov 2013 09:32:36 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQylgD39VV3i for ; Wed, 6 Nov 2013 09:32:32 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A322E21E814D for ; Wed, 6 Nov 2013 09:32:32 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so3785393veb.4 for ; Wed, 06 Nov 2013 09:32:32 -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=x/q7gnyXum+7O4/P7GZUzL8SXcs+xQpWxBWi3pJCZxM=; b=O1Z2zCfgmQEeDeTpVt/8yoKum9jZTwEkNhhbf16RWJqudyIT893RsmFDIUUpmrJzNp vqKpPZID9f/W2QnHczCY92B/FfCnc8DVp+mWyKY5E2ShTbhWrPykB0KnTLNC6ih0+NwH lMITBCl3TBjY2OK4vCLEjhMjCSZFGBnCAtuqGbceNWjh1GFfVscHixvqQcqs5hxOEE7w nR01Ri/ALX69ibaxuepx5U2vxgKc0o4WgCuDYDRqCFcv+8sAPiwl1SXocMpkIx4cW5R2 NG4UrGOQTCJ6dwHOMuZXtkJh3+YrIBeaMH2g7pXFXEWkckKCEDFUgv7k/GqgO1EalzU/ zY1g== 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=x/q7gnyXum+7O4/P7GZUzL8SXcs+xQpWxBWi3pJCZxM=; b=UMHOxn8FsM1pHKI+4AcUM4ghI40aFp/cSfLP8ebydvog8hrJIlo/sZM5SJua7o8GUT n+nEsVK+AmtrM8EA94x0isW4lBN1tNzCrLreeZV76m9oJgbX7VBrZYMvgTZci4oqCurK CGzHj0LJWXtbjUJBs3ugyVGDR9pEk/yX/EDxy6E3sXCR+ijf5pfA3Lp2wAruHpB2HLkg OnMYLFQrezoas822JQ+ir9C29h4tgDkREJ2Z9MWT2eo0XZ2DjNpYFKBR8pR6RhTzZCR4 GIouJ7hYAOUaU7Rf72xzAdUNU8tJ6X8TQd/+TkpIRufBrwZDjEb1bUSxvQ7B0uVOqsBV Rx1w== X-Gm-Message-State: ALoCoQlAHU3xezSyC8mJcS2mdk/1LsAQ8MFodtDg1ve/30qHbYrXaHm/sGkOmlYELFUFSVcJGRqHxN9y6w109NY8Iu+Wh0IVv7mZ00cU1nMPDPm+FoG/1WXTldp5Ih2gDz0Kf4qa7BEHnqTeRKJyr4HuEqY6OHDFR+4LUuzmkxid8UYqwh3DRxfEgSa0i2ve+1sLcPR/qkle MIME-Version: 1.0 X-Received: by 10.58.143.17 with SMTP id sa17mr3401659veb.14.1383759151887; Wed, 06 Nov 2013 09:32:31 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 6 Nov 2013 09:32:31 -0800 (PST) In-Reply-To: <527A7720.7050008@bbn.com> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> Date: Wed, 6 Nov 2013 17:32:31 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:32:38 -0000 On 6 November 2013 17:06, Stephen Kent wrote: > Ben, > >> However. there are several real-world downsides. Most glaring: >> >> 1. In quite a lot of cases (experiments suggest around 4%), clients >> cannot fetch DNSSEC records (nor TLSA records). >> >> 2. DNSSEC has its equivalent of CAs: registries and registrars. Their >> track records on misissuance are not better than CAs. > > I don't argue with your first point, but I expect this problem to diminish > over time So do I. > The second statement, though, is not a reasonable comparison. registrars > operate > with the equivalent of name constraints, from a cert issuance perspective, > which > makes it much better that the WebPKI TA model. Even if the TAs in that model > were > to issue certs including a name constraints extension, the effect would > not be as good as what we have in the DNSSEC/DANE environment. I accept that _registries_ are name constrained. Registrars less so. Not sure I get why this is better than name constrained certificate chains, tho? From joe@oregon.uoregon.edu Wed Nov 6 09:34:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9E21E815C for ; Wed, 6 Nov 2013 09:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeyUz-qeQ4CD for ; Wed, 6 Nov 2013 09:34:18 -0800 (PST) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id 57CE121E8157 for ; Wed, 6 Nov 2013 09:34:18 -0800 (PST) Date: Wed, 6 Nov 2013 09:31:23 -0800 (PST) Message-Id: <13110609312321_A84B@oregon.uoregon.edu> From: "Joe St Sauver" To: hhalpin@w3.org X-VMS-To: SMTP%"hhalpin@w3.org" X-VMS-Cc: SMTP%"perpass@ietf.org" Cc: perpass@ietf.org Subject: Re: [perpass] Great Critique of Lavabit - Client-encryption in the Web? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:34:30 -0000 Harry commented: #In particular, Moxie notes that encrypted email is impossible to do due #to lack of a usable non-Web mail client (I used to use Mutt, then moved #to Thunderbird+Enigmail, but with every passing day Thunderbird gets #worse and worse - perhaps due to Mozilla abandoning it.) since "Despite #what anyone tells you, end to end encrypted email is not possible in a #webmail world." What about https://www.penango.com/ (free browser add-on for Gmail for use with Firefox and IE)? Regards, Joe From nweaver@icsi.berkeley.edu Wed Nov 6 09:35:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BCD21E8157 for ; Wed, 6 Nov 2013 09:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzge-2E9nTs7 for ; Wed, 6 Nov 2013 09:35:41 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08A21E814D for ; Wed, 6 Nov 2013 09:35:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0DBC12C4041; Wed, 6 Nov 2013 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tfrtA1FwHwjQ; Wed, 6 Nov 2013 09:35:34 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3E3BE2C403F; Wed, 6 Nov 2013 09:35:34 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B796FFFC-C40D-4D43-8FD2-EB325FFD94FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Wed, 6 Nov 2013 09:35:33 -0800 Message-Id: <6F7A6327-0259-40F9-B51C-46FB99A9BF59@icsi.berkeley.edu> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> To: Ben Laurie X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver , Stephen Kent Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:35:45 -0000 --Apple-Mail=_B796FFFC-C40D-4D43-8FD2-EB325FFD94FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 6, 2013, at 9:32 AM, Ben Laurie wrote: >> The second statement, though, is not a reasonable comparison. = registrars >> operate >> with the equivalent of name constraints, from a cert issuance = perspective, >> which >> makes it much better that the WebPKI TA model. Even if the TAs in = that model >> were >> to issue certs including a name constraints extension, the effect = would >> not be as good as what we have in the DNSSEC/DANE environment. >=20 > I accept that _registries_ are name constrained. Registrars less so. >=20 > Not sure I get why this is better than name constrained certificate = chains, tho? You are assuming that the protocol is a "single name -> data" If you use DNSSEC in the context of "{multiple names} -> same data", you = can now require that the attacker either attack multiple chains or that = the multiple chains collude. Thus, eg, you only need to assume that BOTH mydomain.com and mydomain.ru = are not compromised by the same attacker. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_B796FFFC-C40D-4D43-8FD2-EB325FFD94FE 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 iQIcBAEBCgAGBQJSen3lAAoJEG2B1w+SDi/u+moP/RR/dRiLK7+I54PnChfVTo1Y LEwvdpqxVk/CtmDjx1uQrj3WbGQFBPDEr3AVToi6H4+K5kU0fYjHWebVp7eQ/Im8 7EFbL4KUVTXR8AhmRRW5j6kEnKE75gfEIY0nLr9eugogKGI6DmxFzx/GTE4GH5QM 48yarVgIjtooP0ehgBJc2ftUcCztdiGzaEsB0KGdcYbJvDvZx8Je8seeGlOQpJQa 9Gq473/zpHrna1L8jBCOJpAvOcR7FzV2zRoG2oe6/ryY4r4n07Q42KjntQcO/dnn XAUL+7EfXPBoOLhWk+gXdRNvJc1L/XqKPF7QQPObkdwMUKlJVot1cbJX4DXNx9uo +xrIlEdznZW1mheRwiAU0Hi9FkCiOVzklYMd5/YKpUMCvrnFLyivG+1Th0QTpNof UMsqbXXEpZEPsa+zHmvkBBl0eq6tHhK372Nu2G7rw3eNll5c/ZM8BgA7r4F6caDf uDqRFUtgYRpJq6Ebyf9GZdW36+NtE948jgSQkdM3uz6DNGyimg79ojKVSuJ6G+TV ieOXB3ALnU6roQws8DurSisui0ctLB4qic1q1YG71fgQ+pMId3EP3eptBYUzd8RZ dzyUI4jRKiB7LAjUQj2bPEHW7rC6qeym2cpxxXaBM+7zQ8/L+4yP+TDo5dvkQzFx 4mLKZbV55wGfGZycWU1j =TEpY -----END PGP SIGNATURE----- --Apple-Mail=_B796FFFC-C40D-4D43-8FD2-EB325FFD94FE-- From benl@google.com Wed Nov 6 09:54:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1F21E8123 for ; Wed, 6 Nov 2013 09:54:18 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtzOZbZvOdFi for ; Wed, 6 Nov 2013 09:54:18 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C321E808D for ; Wed, 6 Nov 2013 09:54:17 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p6so3710362vbe.32 for ; Wed, 06 Nov 2013 09:54:17 -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=5yPyyWxR1g6HRfh+uoYXaliiD3tMmOMtfjSixO6luC4=; b=nD2yK9uE9A/QqofwEEfrv07Y6qhHlTtSaEnYc48Q+q1vJgwvt3xwfdmURhVWkDXb5d JoymJs+yu7PSKqhRW9SziCfAdLwxBGeyOBvEgk2oTRLO6F8i0zafNWp/QgEZ3mATzUtZ vm1rfFRMuuN5JzCRSGAgWqcsd5Egp63C5ZHNz99hVnAlrZEWxeMRkGhmi3e/1Zam8laj hMCJHJgf1EtaRVBLnwUJvDkLKeKXmbfLVxvVUQdnypL5J4uQR/Rpe000VS845BTf9+2S GFRSGUAbQzdvmAFykwPwkP3riScwcu0rL5GzpZE7+zgcL6hfuvxbRpa4IJd5PV01g5Bs 3CZQ== 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=5yPyyWxR1g6HRfh+uoYXaliiD3tMmOMtfjSixO6luC4=; b=PFe9IfFYBUjsDO6LC5kLViPywgWF83+NNWdI8US4Ozo6jp+EFV9rREeq4OGc2bdnrZ QOV10EWYC2/rmS4lWZrg/YUbRZp10tZTdZ4n3ZfUMWqBYmlAeEnbiJb9KAWHeIRVonra JYQ+eikG9iplHGlHJaSXtjQ0xUaxE7OCaO5k24V7gshktA5ZL/RPma+kNN/4OrnDUzZX /nAYiEzHOBXIZ485Hjaj1MvjAGnwJB7tZ6MiijhmR9Xt+GlUmTw04ZhswgQjm+9dUAv1 lP2D8XPF6FnOfersgA9F926XqWtrijDg6IKRzLa5AIJbs5l25zaI3FhyOvun++bZAxG/ 0xHQ== X-Gm-Message-State: ALoCoQltFmZLW6jhvFw1gPh+RBabbTTQnIlQf0CJqNijMzOT7i6Z/TJhB/geXwwetW0vE497ZWxSBjZrEGjimW+mRaD651aJdIK6TXYOGEgECq63wLEdUxAiW2CNARbOPCTpZECU3p8VPyKoMZ2eQm/ssTf47G7uTNy4UXgydpX7OoXG2Bh5FdaJfXKs0d5yIUlsgNE5FH5O MIME-Version: 1.0 X-Received: by 10.220.196.66 with SMTP id ef2mr3469884vcb.7.1383760457120; Wed, 06 Nov 2013 09:54:17 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 6 Nov 2013 09:54:16 -0800 (PST) In-Reply-To: <6F7A6327-0259-40F9-B51C-46FB99A9BF59@icsi.berkeley.edu> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <6F7A6327-0259-40F9-B51C-46FB99A9BF59@icsi.berkeley.edu> Date: Wed, 6 Nov 2013 17:54:16 +0000 Message-ID: From: Ben Laurie To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Stephen Kent Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:54:19 -0000 On 6 November 2013 17:35, Nicholas Weaver wrote: > > On Nov 6, 2013, at 9:32 AM, Ben Laurie wrote: >>> The second statement, though, is not a reasonable comparison. registrars >>> operate >>> with the equivalent of name constraints, from a cert issuance perspective, >>> which >>> makes it much better that the WebPKI TA model. Even if the TAs in that model >>> were >>> to issue certs including a name constraints extension, the effect would >>> not be as good as what we have in the DNSSEC/DANE environment. >> >> I accept that _registries_ are name constrained. Registrars less so. >> >> Not sure I get why this is better than name constrained certificate chains, tho? > > You are assuming that the protocol is a "single name -> data" That is the protocol. > If you use DNSSEC in the context of "{multiple names} -> same data", you can now require that the attacker either attack multiple chains or that the multiple chains collude. > > Thus, eg, you only need to assume that BOTH mydomain.com and mydomain.ru are not compromised by the same attacker. Sure, I agree you can invent new protocols with different security properties. I have several of my own :-) From kent@bbn.com Wed Nov 6 09:57:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8BC11E80D9 for ; Wed, 6 Nov 2013 09:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j96N83Z-yRc for ; Wed, 6 Nov 2013 09:56:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A97521F9A05 for ; Wed, 6 Nov 2013 09:56:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53809 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ve7LK-0006uc-C3; Wed, 06 Nov 2013 12:56:38 -0500 Message-ID: <527A82D5.3030502@bbn.com> Date: Wed, 06 Nov 2013 12:56:37 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ben Laurie , perpass References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:57:02 -0000 On 11/6/13 12:32 PM, Ben Laurie wrote: >> The second statement, though, is not a reasonable comparison. registrars >> operate >> with the equivalent of name constraints, from a cert issuance perspective, >> which >> makes it much better that the WebPKI TA model. Even if the TAs in that model >> were >> to issue certs including a name constraints extension, the effect would >> not be as good as what we have in the DNSSEC/DANE environment. > I accept that _registries_ are name constrained. Registrars less so. yes, I was sloppy in my terminology. > Not sure I get why this is better than name constrained certificate chains, tho? > because the constrained chains begin somewhere below the TA, which leaves EVERY TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of sovereign alignment to a PKI that many folks find attractive. Steve From carl@redhoundsoftware.com Wed Nov 6 10:01:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358D111E80D9 for ; Wed, 6 Nov 2013 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx18aVZzXMiX for ; Wed, 6 Nov 2013 10:01:36 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6521E8171 for ; Wed, 6 Nov 2013 10:01:34 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so18373734iec.34 for ; Wed, 06 Nov 2013 10:01:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=C2UfF7ILl9IupYLRLTiIxqMT3doVH+QyurjbGvRM/iM=; b=J/oIxZosWl0IvrEVMVf6vnhuS+FfuaFEmeJk0rwbABLnICrkPaeNimWyhDRz2jMU9e CdUvu5qqHTDvDpwwmp91TDKyEcMv6ezYy5sDPB7sxLcyD85T6Wx4fxJ9ahsHriqCVHEx h4LMLhN96+3Ifaz3ghA8vIlN/97/5ovO60/vwwgtl/WP+SAtLQJk92w3VgcyH4XR+qcy GxlGx023/LbhW3rNqF82lMahG5rG+0lyPDrAyEKKN8TfTkv1ys4Q0aEm0Ra/VSyrH8lM 8UFHm3psyD1qX2WNYZb9svixTZUzHYPkHaJxVtLnLD5PjQMqiQNP1MDSAGJivs7TsdrD DH8g== X-Gm-Message-State: ALoCoQkAXXspOHqjh5Lhf2aPRkoK9u+pPdinr3fJso5vL4+2YU7zJhTs3ZsDsYh+aMlaMQPviJAB X-Received: by 10.42.84.130 with SMTP id m2mr2857680icl.16.1383760893745; Wed, 06 Nov 2013 10:01:33 -0800 (PST) Received: from [31.133.161.44] (dhcp-a12c.meeting.ietf.org. [31.133.161.44]) by mx.google.com with ESMTPSA id qi3sm362898igc.8.2013.11.06.10.01.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Nov 2013 10:01:32 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 06 Nov 2013 10:01:26 -0800 From: Carl Wallace To: Stephen Kent , Ben Laurie , perpass Message-ID: Thread-Topic: [perpass] Few things the IETF might standardize for secure collaboration In-Reply-To: <527A82D5.3030502@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:01:42 -0000 On 11/6/13 9:56 AM, "Stephen Kent" wrote: > >On 11/6/13 12:32 PM, Ben Laurie wrote: >>> The second statement, though, is not a reasonable comparison. >>>registrars >>> operate >>> with the equivalent of name constraints, from a cert issuance >>>perspective, >>> which >>> makes it much better that the WebPKI TA model. Even if the TAs in that >>>model >>> were >>> to issue certs including a name constraints extension, the effect would >>> not be as good as what we have in the DNSSEC/DANE environment. >> I accept that _registries_ are name constrained. Registrars less so. >yes, I was sloppy in my terminology. >> Not sure I get why this is better than name constrained certificate >>chains, tho? >> >because the constrained chains begin somewhere below the TA, which >leaves EVERY >TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of >sovereign alignment to a PKI that many folks find attractive. TAs can be constrained (at least in theory). The specs are there - just no widely used implementation. There is no good reason to stick with the unconstrained TA model we've been using, though name constraints at internet scale are hard to define. From benl@google.com Wed Nov 6 10:16:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E3311E81FF for ; Wed, 6 Nov 2013 10:16:03 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+FqgwYfMqMt for ; Wed, 6 Nov 2013 10:16:02 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB711E81DC for ; Wed, 6 Nov 2013 10:16:02 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so3861967veb.18 for ; Wed, 06 Nov 2013 10:16:01 -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=ABV8o/RGDDHVlGTsbbEKs2i4PtUG2Yt7n4BdjV5D+Ho=; b=j/2LMIb3oLDIJRercvjEMZmlizB3v7L/RHxff0clZmWQd0g2/rKwEFKyTAvMrJnpz/ A1THz0UNyRSFUZZvKWCEAZ+fz2ARX0SoUjD3jMe95M6/4jBXcIbRv4Ljm3ysu+M+d8XH g1+iUgPDfk5NegpLleV+ooGBjiveqtmZ53WilOtKORH2fZj32WNVD4i2MVwjSxeM+uh5 SDDu6PUGu9qiAyi1l6mIgi1S881kwxLzicwbkPMEKj717Do7d8acpNZowlm5Ds7etiwp +/89E8+skmU1lu0hQBfNsLpXW1rGIpBcXwvhKiZY8Y6p+48xOAj14oiXqEGW0KYLNFnH xbSQ== 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=ABV8o/RGDDHVlGTsbbEKs2i4PtUG2Yt7n4BdjV5D+Ho=; b=IrKy7xleWlyuMzXVEA/zT+mNnV9PczhyT2Iq9LJEpcbVbU0H88vKF5cwm090ZuakeL SbLaxVOzgwiILDlgWeueIsdQmrKvijxHmG59RsjWdQkIlt9PAHxoXF7C6598Mq4kI6qo BVVuCcCIktjmd1DPHwp/yPjogT/VUVMqbW3NavuEb1Txa1Wo+rt8dTWKN5uFjQHrP/Ji vT0IhizVQb1iC+TrMetgRsJusQWBBQqsXZRepECkxkHhu1J37MsuX0KEYVRgv3mRbdp6 XUzuuiG7M1L7BRWhMehfmv7iHE0OxiOIstFnkF4oDhKTtXXHsPlgzkBXTgWXxfgulDoX iVxQ== X-Gm-Message-State: ALoCoQlGRhw1RE1oIGkJuWXj+2/7gq1ww+GJ4pOJKMSoafiI3lxauRTdJxrPX0a1SHxX61PyT9RmHHdFsWV8wz5tsz5CQzHT5FiK/TyJS+5BFmaQ9FBso/2DRkKDocrC3IJPWP/VLlJQKVn+amj0WUrpZIxjcwVlY7sgtVeSeS5ZhSoL0EcOFCP4BieirNN3FuLS9KNuhfEs MIME-Version: 1.0 X-Received: by 10.58.108.196 with SMTP id hm4mr3445596veb.28.1383761761853; Wed, 06 Nov 2013 10:16:01 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 6 Nov 2013 10:16:01 -0800 (PST) In-Reply-To: <527A82D5.3030502@bbn.com> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <527A82D5.3030502@bbn.com> Date: Wed, 6 Nov 2013 18:16:01 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:16:03 -0000 On 6 November 2013 17:56, Stephen Kent wrote: > > On 11/6/13 12:32 PM, Ben Laurie wrote: >>> >>> The second statement, though, is not a reasonable comparison. registrars >>> operate >>> with the equivalent of name constraints, from a cert issuance >>> perspective, >>> which >>> makes it much better that the WebPKI TA model. Even if the TAs in that >>> model >>> were >>> to issue certs including a name constraints extension, the effect would >>> not be as good as what we have in the DNSSEC/DANE environment. >> >> I accept that _registries_ are name constrained. Registrars less so. > > yes, I was sloppy in my terminology. > >> Not sure I get why this is better than name constrained certificate >> chains, tho? >> > because the constrained chains begin somewhere below the TA, which leaves > EVERY > TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of > sovereign alignment to a PKI that many folks find attractive. For exactly the reason many find it unattractive :-) From kent@bbn.com Wed Nov 6 10:32:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167E611E8115 for ; Wed, 6 Nov 2013 10:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOnFs8rOc8mx for ; Wed, 6 Nov 2013 10:32:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBE221F9AE7 for ; Wed, 6 Nov 2013 10:32:47 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53560 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ve7uH-0007Hk-RD; Wed, 06 Nov 2013 13:32:46 -0500 Message-ID: <527A8B4D.1030706@bbn.com> Date: Wed, 06 Nov 2013 13:32:45 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Carl Wallace , perpass References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:32:55 -0000 Carl, >> .. > TAs can be constrained (at least in theory). The specs are there - just > no widely used implementation. There is no good reason to stick with the > unconstrained TA model we've been using, though name constraints at > internet scale are hard to define. Many of the WebPKI TAs are revenue producing entities, and this they have no desire to be constrained in the range of names they can insert into the certs they issue. Of course one can imagine other TA models, which is why DANE is, IMHO, a great alternative. Steve From kent@bbn.com Wed Nov 6 10:37:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6F21E80C1 for ; Wed, 6 Nov 2013 10:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASXFGO0b06NW for ; Wed, 6 Nov 2013 10:37:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C230011E81C7 for ; Wed, 6 Nov 2013 10:37:42 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50932 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ve7z3-000LKR-Qw; Wed, 06 Nov 2013 13:37:41 -0500 Message-ID: <527A8C74.6020100@bbn.com> Date: Wed, 06 Nov 2013 13:37:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ben Laurie References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <527A82D5.3030502@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:37:50 -0000 Ben, >> because the constrained chains begin somewhere below the TA, which leaves >> EVERY >> TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of >> sovereign alignment to a PKI that many folks find attractive. > For exactly the reason many find it unattractive :-) I am not a fan of viewing the Internet as an extra-national entity. Maybe that makes me a heretic WRT Google's idea of cyberspace and reality ;-) . Countries have a right to manage a lot of things within their borders, and managing their DNS name spaces seems quite reasonable. Steve From ggm@algebras.org Wed Nov 6 10:41:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1B411E81DB for ; Wed, 6 Nov 2013 10:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeG07kAnaJFD for ; Wed, 6 Nov 2013 10:41:10 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31511E8219 for ; Wed, 6 Nov 2013 10:41:06 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id hz1so52952pad.30 for ; Wed, 06 Nov 2013 10:41:05 -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=5+e3UpIXoPTdl+SODn8CgEv1LyqKcCUMcvwMx9HXDvY=; b=N1SyONlKTCfZTdALG3t47dyAyvS4SqyWFvYdCBfx5YSqsJSZrA7BcDnQ1cyQJN5EKq IfI65rUi24pZU95qqlhPArftJC24G3n1Wchks58g/q+hS3xEIGG1Fzp4siCbIQ2+XnS/ 3eR4DUIXoWj4DNOWm/7OyQ3MPqfI9jWd32yysKzrjkzXkz/RUHWyYV90/vZvXd/cyL2V pjVj63YYxF6+XCFr4lYuMwOzd7iyDCcPbpQMAjq345tkMB38px/c7JrAW7Dc7haI7MHw 3/GJ8ng4HLn1NJQN9dXHy1gNaClkffHEDoLT1fZGCcAE23ZCcIjlFV7x1DqPurUBmeSg i3LQ== X-Gm-Message-State: ALoCoQkXIDef8L2R6V+1DLx2YueaWkAwLhD53q4MXA69oMywFyamcYzJe6baTVyrpIavMX3PCWSQ MIME-Version: 1.0 X-Received: by 10.66.162.195 with SMTP id yc3mr5430290pab.64.1383763265787; Wed, 06 Nov 2013 10:41:05 -0800 (PST) Received: by 10.70.19.98 with HTTP; Wed, 6 Nov 2013 10:41:05 -0800 (PST) X-Originating-IP: [2001:67c:370:184:88a3:ad75:2b25:d549] In-Reply-To: <527A8C74.6020100@bbn.com> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <527A82D5.3030502@bbn.com> <527A8C74.6020100@bbn.com> Date: Wed, 6 Nov 2013 10:41:05 -0800 Message-ID: From: George Michaelson To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b6dc1a8e931f804ea867d85 Cc: perpass , Ben Laurie Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:41:15 -0000 --047d7b6dc1a8e931f804ea867d85 Content-Type: text/plain; charset=ISO-8859-1 the useful thing about what Steve said, is that its the convergence of desire and reality. Well, 'desire' might be a stretch, but I think he recognizes national laws as a concrete reality we can't pretend doesn't exist. there is a forcing function in reality here, which I find compelling. btw: I actually like ideas I pick up from 'sunlight on certs' anyway, irrespective of DANE or DNSSEC based things. I see no reason not to have more community consciousness of what TA are seen to be good actors and are understood. and more light shining on bad actors. On Wed, Nov 6, 2013 at 10:37 AM, Stephen Kent wrote: > Ben, > > because the constrained chains begin somewhere below the TA, which leaves >>> EVERY >>> TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of >>> sovereign alignment to a PKI that many folks find attractive. >>> >> For exactly the reason many find it unattractive :-) >> > I am not a fan of viewing the Internet as an extra-national entity. > Maybe that makes me a heretic WRT Google's idea of cyberspace and reality > ;-) . > > Countries have a right to manage a lot of things within their borders, > and managing their DNS name spaces seems quite reasonable. > > Steve > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --047d7b6dc1a8e931f804ea867d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
the useful thing about what Steve said, is that its the co= nvergence of desire and reality. Well, 'desire' might be a stretch,= but I think he recognizes national laws as a concrete reality we can't= pretend doesn't exist.

there is a forcing function in reality here, which I find co= mpelling.=A0

btw: I actually like ideas I pick up = from 'sunlight on certs' anyway, irrespective of DANE or DNSSEC bas= ed things. I see no reason not to have more community consciousness of what= TA are seen to be good actors and are understood. and more light shining o= n bad actors.


On Wed,= Nov 6, 2013 at 10:37 AM, Stephen Kent <kent@bbn.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Ben,

because the constrained chains begin somewhere below the TA, which leaves EVERY
TA free to create ANY subordinate CA. =A0Also, ccTLDs represent the sort of=
sovereign alignment to a PKI that many folks find attractive.
For exactly the reason many find it unattractive :-)
I am not a fan of viewing the Internet as an extra-national entity.
Maybe that makes me a heretic WRT Google's idea of cyberspace and reali= ty ;-) .

Countries have a right to manage a lot of things within their borders,
and managing their DNS name spaces seems quite reasonable.

Steve

_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

--047d7b6dc1a8e931f804ea867d85-- From dean.willis@softarmor.com Wed Nov 6 13:15:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506BA21E8185 for ; Wed, 6 Nov 2013 13:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPHVnXNDXdMe for ; Wed, 6 Nov 2013 13:15:08 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD6921E8182 for ; Wed, 6 Nov 2013 13:15:08 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id ia6so53448vcb.21 for ; Wed, 06 Nov 2013 13:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QArTY3tl+OELe60P2VXhCxmz+ieMD0vE6GZdRgbzpLc=; b=S0Asz0v6MCA2+7kxjYzQylsZ9CwWmSg6/ZWzCpcE2tL6qJbAYn7+Fl8t7YdEFnY2CB c6Za5q4N5ckBF/TOllSNkunE2Ws/ve0BVgAjOLy5Wpt8uKMEm6ouzm1nbEJKbdweVd/Z 8UJNnv5um2C9cAzUdAGW4Qj/oyn2C7kNVBQMI= 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=QArTY3tl+OELe60P2VXhCxmz+ieMD0vE6GZdRgbzpLc=; b=HmoN9PFtFolXy3zhULTbdHti1xrsmT21buj2NzkNevZXcBUCacSxz4TExAMZLzGIdX HsOx90AG7Y3COmOkZkO1coc8IfuuI2s9xjMnPYaq3iffHyuW3FqY5XcaS25T/7juYKml fAN5yoJBGov3UeFbHzbH0saOYv5awgN8uLr0e82hUTXpF7GAYdIzKdkPeFkfyHb9xG1i 5cKaHvVmjqwzDM7ek9VnTeQaDgNF5RLKsdBhQts+/DmQWb9j7ZPyY0vAC3xp6rbPls1/ x835RFpTqVKwncU0GVznKtQfq5wVgNNMzSrYlkRiohD5CqzwRrx33MR2dPhGJVAVFgPZ xBxw== X-Gm-Message-State: ALoCoQk0bioA+jEP2KpKDeeV4BVdy8IWSmiUuDvWcMRJUmwD/XY5yWoU4Yho9exxgCFVqnSKKy34 MIME-Version: 1.0 X-Received: by 10.52.113.194 with SMTP id ja2mr155798vdb.61.1383772507902; Wed, 06 Nov 2013 13:15:07 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 6 Nov 2013 13:15:07 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 6 Nov 2013 13:15:07 -0800 (PST) In-Reply-To: <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> Date: Wed, 6 Nov 2013 15:15:07 -0600 Message-ID: From: Dean Willis To: Nicholas Weaver Content-Type: multipart/alternative; boundary=bcaec5485e02c8b8d404ea88a429 Cc: perpass , Phillip Hallam-Baker , Eric Burger Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:15:09 -0000 --bcaec5485e02c8b8d404ea88a429 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Nov 5, 2013 7:17 PM, "Nicholas Weaver" wrote= : > > > On Nov 5, 2013, at 5:12 PM, Dean Willis wrote= : > > > > Wrong. See, the GCHQ has been surveilling US citizens using taps, and the NSA has been surveilling UK citizens using taps. Both are allowed to use covert mechanisms to surveil foreigners. Then they trade data sets with each other. > > > > This is state surveillance, but since it=92s quite reasonably =93illega= l=94, it also requires secrecy. Securing the transit links such that a =93legal order=94 is required would significantly impact the interception. > > Except that its clear that they already HAVE gotten "legal" orders for such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, etc... > There are basically two classes of surveillance that require distinct analysis: 1) Surveillance that requires collaboration by service providers, generally through a "legal" framework of compulsion or a less qualified process of human subversion. Overt, mostly. Typically used within the legal domain of a state actor or enterprise. 2) Surveillance that can occur without the knowledge or support of the provider. Illegal within the US, typically launched from outside the domain of a state actor or enterprise. --bcaec5485e02c8b8d404ea88a429 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Nov 5, 2013 7:17 PM, "Nicholas Weaver" <nweaver@icsi.berkeley.edu> wrote:
>
>
> On Nov 5, 2013, at 5:12 PM, Dean Willis <dean.willis@softarmor.com> wrote:
> >
> > Wrong. See, the GCHQ has been surveilling US citizens using taps,= and the NSA has been surveilling UK citizens using taps. Both are allowed = to use covert mechanisms to surveil foreigners. Then they trade data sets w= ith each other.
> >
> > This is state surveillance, but since it=92s quite reasonably =93= illegal=94, it also requires secrecy. =A0Securing the transit links such th= at a =93legal order=94 is required would significantly impact the intercept= ion.
>
> Except that its clear that they already HAVE gotten "legal" = orders for such surveillance. =A0E.g. AT&T secret room, GCHQ's deal= with Level 3, etc...
>

There are basically two classes of surveillance that require= distinct analysis:

1) Surveillance that requires collaboration by service provi= ders, generally through a "legal" framework of compulsion or a le= ss qualified process of human subversion. Overt, mostly. Typically used wit= hin the legal domain of a state actor or enterprise.

2) Surveillance that can occur without the knowledge or supp= ort of the provider. Illegal within the US, typically launched from outside= the domain of a state actor or enterprise.

--bcaec5485e02c8b8d404ea88a429-- From yaronf.ietf@gmail.com Wed Nov 6 21:45:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359D11E8247 for ; Wed, 6 Nov 2013 21:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiOV0KQGKKDm for ; Wed, 6 Nov 2013 21:45:28 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5AB21F8E8E for ; Wed, 6 Nov 2013 21:45:07 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id d10so31507eaj.40 for ; Wed, 06 Nov 2013 21:44:55 -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=xSdPsm4AhxWRk//MpYwbRqWmrTM7O0yrjYQ8zLthCq8=; b=OUl5F3PgBkrRCLQPSM22XO6k0SOkQnCFH8D+3aspuh0Ub/yqy5aXOMNz6egPArHTdW cjIb8Kpf3x3fibdFXNCoIGo9yqzM6LC2Ie6l97VuswexIEbN06UY7B3oKkN62q1Iz2U/ v7ubUmliarhvy2ymBg1KTtRBjid4mWwE8fufJk8CMF3NBcQexk/qZGC/IOZ9+O0DMyX3 BOPk+LAe3WbrLsjmxFztDmp8rFHAEZwYG9MWJAp4eWvyyzHEqGWRlLGZ01ZGyFHhu1Pb ChPxHxWcwfggb0FJTdm9XI4J75jAFmUx9zXPCnvGFtkkX0D+lkJEWE+jdt+E/PxUhSig S71w== X-Received: by 10.14.104.5 with SMTP id h5mr7357678eeg.58.1383803094954; Wed, 06 Nov 2013 21:44:54 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id d7sm4637210eem.8.2013.11.06.21.44.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 21:44:54 -0800 (PST) Message-ID: <527B28D1.2090909@gmail.com> Date: Thu, 07 Nov 2013 07:44:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Joe St Sauver , hhalpin@w3.org References: <13110609312321_A84B@oregon.uoregon.edu> In-Reply-To: <13110609312321_A84B@oregon.uoregon.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Great Critique of Lavabit - Client-encryption in the Web? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 05:45:33 -0000 Unfortunately they appear to be dead (no support for modern versions of Firefox, no response to emails). You might want to follow Enlocked ( https://www.enlocked.com/): their current product is not end-to-end, but they're making noises of moving to a more secure model. Thanks, Yaron On 2013-11-06 19:31, Joe St Sauver wrote: > Harry commented: > > #In particular, Moxie notes that encrypted email is impossible to do due > #to lack of a usable non-Web mail client (I used to use Mutt, then moved > #to Thunderbird+Enigmail, but with every passing day Thunderbird gets > #worse and worse - perhaps due to Mozilla abandoning it.) since "Despite > #what anyone tells you, end to end encrypted email is not possible in a > #webmail world." > > What about https://www.penango.com/ (free browser add-on for Gmail for > use with Firefox and IE)? > > Regards, > > Joe > From rutkowski.tony@gmail.com Thu Nov 7 04:36:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252811E8138 for ; Thu, 7 Nov 2013 04:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmuQdjzbRzMQ for ; Thu, 7 Nov 2013 04:36:49 -0800 (PST) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 595C921E8088 for ; Thu, 7 Nov 2013 04:36:47 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id w7so345206qeb.39 for ; Thu, 07 Nov 2013 04:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G3Q6DgoKxXvPUn7msV4oKHMi7+732pNSVTWOdOaZR14=; b=Qq0rVfGfRceycYUsmaSjq5Bc9CECbAm25EdA4cj+TGVixdbv/pSBv6GTONQNYEWdTD TnPcESbcPCPlZfkeGWIs8mQ7rhqazGRpgM5oNzrXTmF8UrOEWRf/TBONIMFvEl/gvSz/ Fny6OaT+7F+giIH2VJsFiY9PPgW/pVxbVRP9NUhVhcvg6A/axSdwcj20QnIEAV5ghjUY ySVrkN09lgCW/QWLy/oKT9CP4oNYHLiI0yQIYChQMqrn+ipZmvrOHAKa/6Aro5c/Lkl9 UONHk9fp97yArBKQX2xsBeNSAzliE1JlK0EyhhjBYXGVo7Rk96mpl6eETweCvFKyBqik Q7aw== X-Received: by 10.224.138.4 with SMTP id y4mr13632094qat.65.1383827805792; Thu, 07 Nov 2013 04:36:45 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id a5sm9480604qae.2.2013.11.07.04.36.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 04:36:45 -0800 (PST) Message-ID: <527B895B.9000000@gmail.com> Date: Thu, 07 Nov 2013 07:36:43 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yaron Sheffer , Joe St Sauver , hhalpin@w3.org References: <13110609312321_A84B@oregon.uoregon.edu> <527B28D1.2090909@gmail.com> In-Reply-To: <527B28D1.2090909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Great Critique of Lavabit - Client-encryption in the Web? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 12:36:50 -0000 They are likely paying their legal fees. They were the subject of a grand jury investigation and enforcement action that is now before the U.S. Court of Appeals for the Fourth Circuit. You can follow along at: http://dockets.justia.com/docket/circuit-courts/ca4/13-4625 The identities were just unsealed last week. Their likelihood of prevailing in the 4th Cir. are between slim and none. What they are fighting is a global LEA requirement: > b) remove any service coding or encryption which has been applied to > the content of communication > (i.e. en clair) and the intercept related information at the > instigation of the network operator or service > provider; > NOTE 1: If coding/encryption cannot be removed through means, which > are available in the network or service for > the given communication, the receiving agencies should be provided > with keys etc. to access the > information en clair, cf next clause. > c) provide the LEA with any other decryption keys whose uses include > encryption of the content of > communication, where such keys are available for NWO/SvP/AP; -t On 11/7/2013 12:44 AM, Yaron Sheffer wrote: > Unfortunately they appear to be dead (no support for modern versions > of Firefox, no response to emails). From kaduk@mit.edu Thu Nov 7 06:55:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDB421E8206 for ; Thu, 7 Nov 2013 06:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsvhRaqqKet0 for ; Thu, 7 Nov 2013 06:55:31 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id C429321E81F3 for ; Thu, 7 Nov 2013 06:55:30 -0800 (PST) X-AuditID: 12074424-b7f0b8e000004bf2-60-527ba9e2c274 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 64.57.19442.2E9AB725; Thu, 7 Nov 2013 09:55:30 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id rA7EtT4N030113; Thu, 7 Nov 2013 09:55:29 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7EtRMg006501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Nov 2013 09:55:28 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA7EtREf019768; Thu, 7 Nov 2013 09:55:27 -0500 (EST) Date: Thu, 7 Nov 2013 09:55:27 -0500 (EST) From: Benjamin Kaduk To: perpass In-Reply-To: Message-ID: References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1754843935-1383836127=:4934" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrftoZXWQwdqbXBZXlx9nsrh7qYPF gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4Ous+Y8Fn0Ypp3xexNzC+Euxi5OSQEDCR WNq9kRnCFpO4cG89WxcjF4eQwGwmiZeTf7NAOBsYJW4t7WaCcA4ySfy9vocJpEVIoF7i06yJ YDaLgJbE9I1nwUaxCahIzHyzkQ3EFhGQkzj88ytYnFlAW+J631lWEFtYwFhi9suPYDWcAoES x9f0g9XwCjhIXDxzkRli2T5miZ9Hl7CAJEQFdCRW75/CAlEkKHFy5hMWiKEBEntu72CdwCg4 C0lqFpIUhG0r8X7hLMZZUHfcv9nGtoCRZRWjbEpulW5uYmZOcWqybnFyYl5eapGuuV5uZole akrpJkZQcLO7qOxgbD6kdIhRgINRiYd3Rk1VkBBrYllxZe4hRkkOJiVR3uPLqoOE+JLyUyoz Eosz4otKc1KLDzFKcDArifAeWQiU401JrKxKLcqHSUlzsCiJ897isA8SEkhPLEnNTk0tSC2C ycpwcChJ8NasAGoULEpNT61Iy8wpQUgzcXCCDOcBGj4NpIa3uCAxtzgzHSJ/ilGXo+X7p2+M Qix5+XmpUuIQgwRAijJK8+DmwJLSK0ZxoLeEeeNAqniACQ1u0iugJUxAS0J+VYIsKUlESEk1 MEremcHz74/W3fdHPernGc3jeca/QXtXa423/kLnR393JB7OPLSrNrhSaOr8y9Y/dNxOL1v7 XU5hs09g39ZIX4b1veYPggPfdPloHzX91qz5qURJp6cwYZFN+oujpZO1m1w6BadO/lppWs79 5JjmjgaT1IL3R0LKHsdkhHv8yf3yp7f077tHUkosxRmJhlrMRcWJAKWY30UlAwAA Cc: Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:55:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1754843935-1383836127=:4934 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 6 Nov 2013, Dean Willis wrote: > On Nov 5, 2013 7:17 PM, "Nicholas Weaver" wro= te: >> >> >> On Nov 5, 2013, at 5:12 PM, Dean Willis wrot= e: >>> >>> Wrong. See, the GCHQ has been surveilling US citizens using taps, and > the NSA has been surveilling UK citizens using taps. Both are allowed to > use covert mechanisms to surveil foreigners. Then they trade data sets wi= th > each other. >>> >>> This is state surveillance, but since it=92s quite reasonably =93illega= l=94, > it also requires secrecy. Securing the transit links such that a =93lega= l > order=94 is required would significantly impact the interception. >> >> Except that its clear that they already HAVE gotten "legal" orders for > such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, etc.= =2E. >> > > There are basically two classes of surveillance that require distinct > analysis: > > 1) Surveillance that requires collaboration by service providers, general= ly > through a "legal" framework of compulsion or a less qualified process of > human subversion. Overt, mostly. Typically used within the legal domain o= f > a state actor or enterprise. > > 2) Surveillance that can occur without the knowledge or support of the > provider. Illegal within the US, typically launched from outside the doma= in > of a state actor or enterprise. Phill made the point during his talk at the BoF yesterday, that (roughly=20 speaking), we should consider cases where our actions cause attacks to=20 move from class (2) to class (1) to be victories. This is (to me),=20 broadly speaking, true, in that it gives the collective us more knowledge= =20 about what is going on. However, I fear that the knowledge we gain may be more limited that we=20 would like. In particular, I fear that NSLs or similar things will come=20 with gag orders so strong that the company's counsel will not be able to=20 use knowledge of them to alter company policy, or even that the gag will=20 prevent the engineer being served from contacting the company's counsel.=20 There are probably technical measures which could help a little, such as=20 requiring multiple persons to authenticate certain classes of operations,= =20 though I suspect those are out of scope for IETF protocol work. -Ben Kaduk (I have received between -1000 and 0 NSLs in the past 30 years.) ---559023410-1754843935-1383836127=:4934-- From dean.willis@softarmor.com Thu Nov 7 09:08:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF121E8134 for ; Thu, 7 Nov 2013 09:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtmGpqa2T8Di for ; Thu, 7 Nov 2013 09:08:25 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0351911E825F for ; Thu, 7 Nov 2013 09:07:51 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md4so873508pbc.2 for ; Thu, 07 Nov 2013 09:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ga9VPf5ducLjTFfsbZ+oBSfFPlQ2bX8sXMJHIiMjbRI=; b=EQXn6y1z43KScEy/cATI/KVRlUL8uGXUcNcBB8QNZMkdRzQ85Ige7Sa9ldQlwUTd+3 yWLZcD2ThDV7vOTCwqowzr83ysdL7TqORf4ai+HTMdmBOLr+7mEYcJrm7IPT+1ZKaVeH i2lpFBfuUl7ULK5dnUcKpMwP59FNB9TGrX1oA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Ga9VPf5ducLjTFfsbZ+oBSfFPlQ2bX8sXMJHIiMjbRI=; b=TvdUMG6j2X3CytpglNcnm9KeHF5a6mBP5yGfkSAoIRXPxnK463SmF/d4b4NTeXyMUP XqC2eDAhunLy0jjI435MoHUp3qM6GK+OuB4wXRj81NKFVx11rVtig0rhx2cN6dqpv+wh llR1HAH7OUrKqE0oy9mBDDTyz2YcKGXIxb49+aWELUV+j6YpUSQ5EKnBhfrOV6CFrX6n CEeYzv2YmX+cXEnn+m/SBb6ONjHTy826k6bprO26wPJbfbKzRZ4IICUU2A3IRcj5dOAJ CW4c2say7KS6Z0FJyx84b5t3BzqJODqmcD2IdY91iJcl6g5JycfTfe9QXVuTmFCnhED6 H4sw== X-Gm-Message-State: ALoCoQkv0GtFncGw+nVp1Q2utJ7lRIpxYrs6uW0W0wvc9YwSG7FjPI+veL8PWUvk/FkWdm9FLVq+ X-Received: by 10.67.21.130 with SMTP id hk2mr10932288pad.76.1383844065266; Thu, 07 Nov 2013 09:07:45 -0800 (PST) Received: from [10.143.89.29] (S0106001b2fe1bb13.vc.shawcable.net. [174.6.170.174]) by mx.google.com with ESMTPSA id pl1sm6284725pbb.20.2013.11.07.09.07.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:07:44 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dean Willis In-Reply-To: Date: Thu, 7 Nov 2013 11:07:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1816) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:08:28 -0000 On Nov 7, 2013, at 8:55 AM, Benjamin Kaduk wrote: >=20 > However, I fear that the knowledge we gain may be more limited that we = would like. In particular, I fear that NSLs or similar things will come = with gag orders so strong that the company's counsel will not be able to = use knowledge of them to alter company policy, or even that the gag will = prevent the engineer being served from contacting the company's counsel. = There are probably technical measures which could help a little, such as = requiring multiple persons to authenticate certain classes of = operations, though I suspect those are out of scope for IETF protocol = work. I don=92t disagree. That=92s why we need best practices for: 1) end to end application-level (TLS, DTLS, etc.) 2) IP node to IP node (IP peer level; application level like HTTPS, = IPSEC transport, or opportunistic tcpcrypt and/or BTN)=20 3) IP domain to IP domain (VPN; IPSEC tunnel) 4) MPLS-to-MPLS (and similar sub-IP overlays)=20 5) physical link (fiber drivers, WPA, etc.) encryptions and authentications all at the same time. Layers in a tasty = birthday cake. If you=92ve been subject to US junk food adverts, think = of it like Lay=92s potato chips. You can=92t eat just one. Another = motto: No eggshells. They=92re going to hit the weak spot. We want the weak spot to require a = whole stack of subpoenas and a whole lot of informed consent. Compliance = with the law is required; our goal is to make sure the law is also = complied with by the the attackers. And we don=92t think that GCHQ is going to be able to get a subpoena = directly in the US, or vice versa, so the game of using foreign agents = to spy on domestic assets (and trade data with each other) will get = mostly shut down. Sure, "they" might pass a law that says end-user encryption is illegal. = We want them to have to pass that law, and have the public discourse = needed to pass such a law in a democracy. Of course, rogue states are = going to do whatever they=92re going to do, but we can certainly reduce = how much of it they do to other states. This is not a =93resistance=94 thing; it=92s a "civil-defense" thing. If = one state=92s or one enterprise=92s infosec is appallingly weak, other = actors are going to take advantage of that weakness. If one nation=92s = or enterprise=92s IT products have weak infosec as a matter of policy, = that nation or enterprise is going to be very disadvantaged in external = sales of those products. Our task is to set the bar sufficiently high = without breaking the bank in the process. We must also remember that = said bar is going to keep moving at the pace of Moore=92s law. Adequate = security in 1990 is not adequate security in 2013, and so on. =97 Dean= From martin@millnert.se Thu Nov 7 11:08:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FBE11E8118 for ; Thu, 7 Nov 2013 11:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at2NP834lkG6 for ; Thu, 7 Nov 2013 11:07:54 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id 2956711E81B3 for ; Thu, 7 Nov 2013 11:07:54 -0800 (PST) Received: from [10.7.59.130] (c-5eeaaa9b-74736162.cust.telenor.se [94.234.170.155]) by mail.millnert.se (Postfix) with ESMTPSA id 5AEBEA8; Thu, 7 Nov 2013 20:10:07 +0100 (CET) References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <935A3030-403D-42DF-862D-6BD74B4B33EA@millnert.se> X-Mailer: iPad Mail (10B329) From: Martin Millnert Date: Thu, 7 Nov 2013 20:07:50 +0100 To: Dean Willis Cc: perpass , Phillip Hallam-Baker , Benjamin Kaduk Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:08:00 -0000 On 7 nov 2013, at 18:07, Dean Willis wrote: >=20 > On Nov 7, 2013, at 8:55 AM, Benjamin Kaduk wrote: >>=20 >> However, I fear that the knowledge we gain may be more limited that we wo= uld like. In particular, I fear that NSLs or similar things will come with g= ag orders so strong that the company's counsel will not be able to use knowl= edge of them to alter company policy, or even that the gag will prevent the e= ngineer being served from contacting the company's counsel. There are probab= ly technical measures which could help a little, such as requiring multiple p= ersons to authenticate certain classes of operations, though I suspect those= are out of scope for IETF protocol work. >=20 >=20 > I don=E2=80=99t disagree. That=E2=80=99s why we need best practices for: >=20 > 1) end to end application-level (TLS, DTLS, etc.) > 2) IP node to IP node (IP peer level; application level like HTTPS, IPSEC t= ransport, or opportunistic tcpcrypt and/or BTN)=20 > 3) IP domain to IP domain (VPN; IPSEC tunnel) > 4) MPLS-to-MPLS (and similar sub-IP overlays)=20 > 5) physical link (fiber drivers, WPA, etc.) >=20 > encryptions and authentications all at the same time. Layers in a tasty bi= rthday cake. If you=E2=80=99ve been subject to US junk food adverts, think o= f it like Lay=E2=80=99s potato chips. You can=E2=80=99t eat just one. Anothe= r motto: No eggshells. >=20 > They=E2=80=99re going to hit the weak spot. We want the weak spot to requi= re a whole stack of subpoenas and a whole lot of informed consent. Complianc= e with the law is required; our goal is to make sure the law is also complie= d with by the the attackers. >=20 > And we don=E2=80=99t think that GCHQ is going to be able to get a subpoena= directly in the US, or vice versa, so the game of using foreign agents to s= py on domestic assets (and trade data with each other) will get mostly shut d= own. >=20 > Sure, "they" might pass a law that says end-user encryption is illegal. We= want them to have to pass that law, and have the public discourse needed to= pass such a law in a democracy. Of course, rogue states are going to do wha= tever they=E2=80=99re going to do, but we can certainly reduce how much of i= t they do to other states. >=20 > This is not a =E2=80=9Cresistance=E2=80=9D thing; it=E2=80=99s a "civil-de= fense" thing. If one state=E2=80=99s or one enterprise=E2=80=99s infosec is a= ppallingly weak, other actors are going to take advantage of that weakness. I= f one nation=E2=80=99s or enterprise=E2=80=99s IT products have weak infosec= as a matter of policy, that nation or enterprise is going to be very disadv= antaged in external sales of those products. Our task is to set the bar suff= iciently high without breaking the bank in the process. We must also remembe= r that said bar is going to keep moving at the pace of Moore=E2=80=99s law. A= dequate security in 1990 is not adequate security in 2013, and so on. +1 /M= From hallam@gmail.com Thu Nov 7 13:16:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3FB21E8188 for ; Thu, 7 Nov 2013 13:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkOhzxNCf0CW for ; Thu, 7 Nov 2013 13:15:59 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 15DB021E818B for ; Thu, 7 Nov 2013 13:15:54 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id u14so906504lbd.36 for ; Thu, 07 Nov 2013 13:15:54 -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=ySYw/f5e1bpLl0cGd35IHE32ceJLfgv7e3FWyl3FvGw=; b=R2pN3ue5ll7jQZfZ2ox496740+f85E5gKCMQxqLa3myPY41z1SR0G98FWYqqiqpiCO XsicVyKes9LItD6EOPg1uA4GrRUm6MXBKVp/SBSs3uh5zZB/58EcggT30SAMlXXzKBR/ d714eSa3pe36uzTddTxPBWIg8KF+XhdOfT8PEchtkSX95H+NFs6q6JFxRezhe5z7TB7P RimdtEDL8wJX1pdVHCyO9ZqlIn5fpT6o8T/9grFPWZ4z3gFPicG+nVawIlf/kYfXjDkc dcwuggeiKXOmgCyP0rbiSzivOKpbju6ryLcdoYVmrhrtfl3t4nRCTfUME8m5pKRfzQpD D1yA== MIME-Version: 1.0 X-Received: by 10.112.234.168 with SMTP id uf8mr7727745lbc.35.1383858953868; Thu, 07 Nov 2013 13:15:53 -0800 (PST) Received: by 10.112.46.98 with HTTP; Thu, 7 Nov 2013 13:15:53 -0800 (PST) In-Reply-To: References: <7F15A999-E66C-48C3-946C-1C17B6956913@standardstrack.com> <93674456-01B7-48D2-942D-25C94DA1CB6F@icsi.berkeley.edu> Date: Thu, 7 Nov 2013 13:15:53 -0800 Message-ID: From: Phillip Hallam-Baker To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c3d9b45d5e1604ea9cc5c0 Cc: perpass Subject: Re: [perpass] Encrypt all lit fiber 24x365 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:16:01 -0000 --001a11c3d9b45d5e1604ea9cc5c0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think it very unlikely that the NSA would think that they can use information gained through a court order for 'swapsies' with other intel agencies as they have been found to have done giving raw intercepts to Israel. Getting a court order to get intercept keys for a machine in a foreign jurisdiction is much harder than in-jurisdiction. The objective here is to prevent traffic analysis. Difficult to to that if you only have the keys for the routers in your own jurisdiction. On Thu, Nov 7, 2013 at 6:55 AM, Benjamin Kaduk wrote: > On Wed, 6 Nov 2013, Dean Willis wrote: > > On Nov 5, 2013 7:17 PM, "Nicholas Weaver" >> wrote: >> >>> >>> >>> On Nov 5, 2013, at 5:12 PM, Dean Willis >>> wrote: >>> >>>> >>>> Wrong. See, the GCHQ has been surveilling US citizens using taps, and >>>> >>> the NSA has been surveilling UK citizens using taps. Both are allowed t= o >> use covert mechanisms to surveil foreigners. Then they trade data sets >> with >> each other. >> >>> >>>> This is state surveillance, but since it=92s quite reasonably =93illeg= al=94, >>>> >>> it also requires secrecy. Securing the transit links such that a =93le= gal >> order=94 is required would significantly impact the interception. >> >>> >>> Except that its clear that they already HAVE gotten "legal" orders for >>> >> such surveillance. E.g. AT&T secret room, GCHQ's deal with Level 3, >> etc... >> >>> >>> >> There are basically two classes of surveillance that require distinct >> analysis: >> >> 1) Surveillance that requires collaboration by service providers, >> generally >> through a "legal" framework of compulsion or a less qualified process of >> human subversion. Overt, mostly. Typically used within the legal domain = of >> a state actor or enterprise. >> >> 2) Surveillance that can occur without the knowledge or support of the >> provider. Illegal within the US, typically launched from outside the >> domain >> of a state actor or enterprise. >> > > Phill made the point during his talk at the BoF yesterday, that (roughly > speaking), we should consider cases where our actions cause attacks to mo= ve > from class (2) to class (1) to be victories. This is (to me), broadly > speaking, true, in that it gives the collective us more knowledge about > what is going on. > > However, I fear that the knowledge we gain may be more limited that we > would like. In particular, I fear that NSLs or similar things will come > with gag orders so strong that the company's counsel will not be able to > use knowledge of them to alter company policy, or even that the gag will > prevent the engineer being served from contacting the company's counsel. > There are probably technical measures which could help a little, such as > requiring multiple persons to authenticate certain classes of operations, > though I suspect those are out of scope for IETF protocol work. > > -Ben Kaduk > > (I have received between -1000 and 0 NSLs in the past 30 years.) --=20 Website: http://hallambaker.com/ --001a11c3d9b45d5e1604ea9cc5c0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think it very unlikely that the NSA would think that the= y can use information gained through a court order for 'swapsies' w= ith other intel agencies as they have been found to have done giving raw in= tercepts to Israel.

Getting a court order to get intercept keys for a machine in= a foreign jurisdiction is much harder than in-jurisdiction.=A0
<= br>
The objective here is to prevent traffic analysis. Difficult = to to that if you only have the keys for the routers in your own jurisdicti= on.


On Thu,= Nov 7, 2013 at 6:55 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Wed, 6 Nov 2013, Dean Willis wro= te:

On Nov 5, 2013 7:17 PM, "Nicholas Weaver" <nweaver@icsi.berkeley.edu&g= t; wrote:


On Nov 5, 2013, at 5:12 PM, Dean Willis <dean.willis@softarmor.com> wrote:

Wrong. See, the GCHQ has been surveilling US citizens using taps, and
the NSA has been surveilling UK citizens using taps. Both are allowed to use covert mechanisms to surveil foreigners. Then they trade data sets with=
each other.

This is state surveillance, but since it=92s quite reasonably =93illegal=94= ,
it also requires secrecy. =A0Securing the transit links such that a =93lega= l
order=94 is required would significantly impact the interception.

Except that its clear that they already HAVE gotten "legal" order= s for
such surveillance. =A0E.g. AT&T secret room, GCHQ's deal with Level= 3, etc...


There are basically two classes of surveillance that require distinct
analysis:

1) Surveillance that requires collaboration by service providers, generally=
through a "legal" framework of compulsion or a less qualified pro= cess of
human subversion. Overt, mostly. Typically used within the legal domain of<= br> a state actor or enterprise.

2) Surveillance that can occur without the knowledge or support of the
provider. Illegal within the US, typically launched from outside the domain=
of a state actor or enterprise.

Phill made the point during his talk at the BoF yesterday, that (roughly sp= eaking), we should consider cases where our actions cause attacks to move f= rom class (2) to class (1) to be victories. =A0This is (to me), broadly spe= aking, true, in that it gives the collective us more knowledge about what i= s going on.

However, I fear that the knowledge we gain may be more limited that we woul= d like. =A0In particular, I fear that NSLs or similar things will come with= gag orders so strong that the company's counsel will not be able to us= e knowledge of them to alter company policy, or even that the gag will prev= ent the engineer being served from contacting the company's counsel. Th= ere are probably technical measures which could help a little, such as requ= iring multiple persons to authenticate certain classes of operations, thoug= h I suspect those are out of scope for IETF protocol work.

-Ben Kaduk

(I have received between -1000 and 0 NSLs in the past 30 years.)



--
Website: http://hallambaker.com/
--001a11c3d9b45d5e1604ea9cc5c0-- From elopez@fortinet.com Thu Nov 7 16:45:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8511E80E2 for ; Thu, 7 Nov 2013 16:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C7Z+HqC-jiS for ; Thu, 7 Nov 2013 16:45:26 -0800 (PST) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.88]) by ietfa.amsl.com (Postfix) with ESMTP id 260E621E8181 for ; Thu, 7 Nov 2013 16:45:20 -0800 (PST) From: Edward Lopez To: "acooper@cdt.org" , "stephen.farrell@cs.tcd.ie" , "turners@ieca.com" Thread-Topic: Discussion of draft-cooper-ietf-privacy-requirements-01.txt Thread-Index: AQHO3BvC/QkMs1P3eUitfGBCsGA/qQ== Date: Fri, 8 Nov 2013 00:45:03 +0000 Message-ID: <8F57AE77-0436-47BC-BB71-E667EBEF26E2@fortinet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.165.82] Content-Type: multipart/alternative; boundary="_000_8F57AE77043647BCBB71E667EBEF26E2fortinetcom_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.213 Cc: "perpass@ietf.org" Subject: [perpass] Discussion of draft-cooper-ietf-privacy-requirements-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:45:45 -0000 --_000_8F57AE77043647BCBB71E667EBEF26E2fortinetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First off, thank you for your efforts on this draft! I have a concerns in that the sum of what is presented in the recommendat= ions document basically says that all emerging IETF protocols must requir= ed consideration for opportunistic encryption, and that unless this oppor= tunistic encryption is anonymous in nature, the protocol cannot fallback = to a non-encrypted state. I see no discussion on encryption costs, particularly relative to perform= ance. In an analogy, any valid assessment of a cryptographic algorithm i= ncludes an analysis of cost relative to the number of cycles needed for i= ts performance. If emerging protocols must include crypto functions, a s= tatement of the cost of the crypto function, at a minimum relative to the= non-crypto functions and who bears these costs. I am concerned that the= exception statement regarding the elimination or severe-diminishment of = utility is insufficient to prevent the emergence of bloated protocols wit= h little practical value. I feel that we are suggesting a band-aid approach to applying opportunist= ic encryption to protocol design. It basically says, build a protocol, a= dd encryption where you can. It does not say that the protection of priv= acy data from passive surveillance is an inherent design goal for the pro= tocol. I feel it is important that we see this was a philosophical chang= e, and not an onerous, and therefore marginalized, task. Is a NULL crypto algorithm acceptable, relative to the goals of this BCP?= Can implementers get away with performing NULL opportunistic encryption= of a protocol that provides it, as opposed to not performing encryption = (yes, there is a difference)? Thank you for your consideration, and I look forward to all queries and r= eplies Cheers! Ed Lopez *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_8F57AE77043647BCBB71E667EBEF26E2fortinetcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
First off, thank you for your efforts on this draft!

I have a concerns in that the sum of what is presented in the recomm= endations document basically says that all emerging IETF protocols must r= equired consideration for opportunistic encryption, and that unless this = opportunistic encryption is anonymous in nature, the protocol cannot fallback to a non-encrypted state.

I see no discussion on encryption costs, particularly relative to pe= rformance.  In an analogy, any valid assessment of a cryptographic a= lgorithm includes an analysis of cost relative to the number of cycles ne= eded for its performance.  If emerging protocols must include crypto functions, a statement of the cost of the crypto fun= ction, at a minimum relative to the non-crypto functions and who bears th= ese costs.  I am concerned that the exception statement regarding th= e elimination or severe-diminishment of utility is insufficient to prevent the emergence of bloated protocols with littl= e practical value.

I feel that we are suggesting a band-aid approach to applying opport= unistic encryption to protocol design.  It basically says, build a p= rotocol, add encryption where you can.  It does not say that the pro= tection of privacy data from passive surveillance is an inherent design goal for the protocol.  I feel it is importan= t that we see this was a philosophical change, and not an onerous, and th= erefore marginalized, task.

Is a NULL crypto algorithm acceptable, relative to the goals of this= BCP?  Can implementers get away with performing NULL opportunistic = encryption of a protocol that provides it, as opposed to not performing e= ncryption (yes, there is a difference)?

Thank you for your consideration, and I look forward to all queries = and replies

Cheers!
Ed Lopez


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_8F57AE77043647BCBB71E667EBEF26E2fortinetcom_-- From bortzmeyer@nic.fr Mon Nov 11 04:13:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0221E80D2 for ; Mon, 11 Nov 2013 04:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2h0rlflDg3W for ; Mon, 11 Nov 2013 04:13:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1719D21E80A6 for ; Mon, 11 Nov 2013 04:13:08 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 055563B6F5; Mon, 11 Nov 2013 12:13:06 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id D61AE190BEB; Mon, 11 Nov 2013 13:10:27 +0100 (CET) Date: Mon, 11 Nov 2013 13:10:27 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20131111121027.GA31723@sources.org> References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> <5242D8AA.4040108@cs.tcd.ie> <20130925124059.GA8996@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130925124059.GA8996@nic.fr> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.2 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass , Andy Wilson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:13:14 -0000 On Wed, Sep 25, 2013 at 02:40:59PM +0200, Stephane Bortzmeyer wrote a message of 13 lines which said: > May be starting with the more modest but certainly useful "DNS > privacy considerations" Internet-Draft? Such a document, just > documenting the problem, would be a good idea, IMHO. Done. http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy From stephen.farrell@cs.tcd.ie Mon Nov 11 09:56:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A76911E81C4 for ; Mon, 11 Nov 2013 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7yilSnc2p3P for ; Mon, 11 Nov 2013 09:56:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 64FC711E81CA for ; Mon, 11 Nov 2013 09:56:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1E1EBE6E for ; Mon, 11 Nov 2013 17:56: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 pFwLyoFMamUj for ; Mon, 11 Nov 2013 17:56: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 5F72ABE68 for ; Mon, 11 Nov 2013 17:56:00 +0000 (GMT) Message-ID: <52811A32.3010706@cs.tcd.ie> Date: Mon, 11 Nov 2013 17:56:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:56:09 -0000 Hiya, I think we got a great outcome last week, at the tech plenary and all the other sessions where we discussed pervasive monitoring. Thanks to everyone who sent mail, presented or spoke at a mic for all your constructive contributions. Sean and I chatted at the end of the week and figured it'd be useful to refine the description of this list to reflect that progress. Hopefully that'll help us keep the list more focused between now and London. Since this is not intended to be a working group, this isn't a charter, but is a bit similar, so we'd like to run it by the list in case any discussion is needed. We'd like to get that out of the way in the next few days and then move on to discussion of how to go forward with the bits and pieces of work that were identified at the meeting and earlier on the list. (I need to go back over the meeting notes and listen back to the audio which I'll do in the next few days but let's get any discussion of this out of the way first.) Our current revised list description based on all that happened in Vancouver is as follows: " The perpass list is for IETF discussion of pervasive monitoring. IETF specifications need to be designed to protect against pervasive monitoring where possible. This list is intended for technical discussions attempting to meet that goal. Discussion is limited to specific technical proposals for improvements in IETF protocols and to IETF process changes aiming to increase the liklihood that implementation and deployment of IETF protocols results in better mitigation for pervasive monitoring. Those with proposals are encouraged to embody them in detailed internet-draft specifications, rather than relying solely email messages. The typical modus-operandi of the perpass list should be to identify a credible piece of work, with identified volunteer effort, and then to find a home for that work within the IETF. Once such a home is identified work should move to whatever other lists are relevant. Note that the perpass list is a non-working group list, that is, there is no intent to form an IETF working group on this topic. " Comments welcome, and we'll get back about the plan for specific work items in a few days. Thanks, Stephen & Sean. From leifj@mnt.se Mon Nov 11 09:59:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0B11E81ED for ; Mon, 11 Nov 2013 09:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsQJrLpniqMq for ; Mon, 11 Nov 2013 09:59:08 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 84EEA11E8217 for ; Mon, 11 Nov 2013 09:59:07 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so5508138pdj.33 for ; Mon, 11 Nov 2013 09:59:07 -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=bkQVTMSzn6VwCK35Ff7JRXuDiSP2YhNiIoLgHk2gX8I=; b=HQE+vh4snS7Zw+MXM2SSj/t5dinlnRaphJtB4jObyeNI+axulcUVvu9ayS48yPX7sH b3aTmmPZgRx8is/JEsMeWClx3+pP6DpQ+O+NrZAk1N//Ib97jGEB0NaSckEmNNgUqPY0 ftTz5ywNJ6BZ8lq8J9E9IOP3J/wDI8yiYadLPIGT3zttErfvgLF0VC+jkVw9iKmYXIJf kpK71THYfKmZX+0V+6K1rAEa3CN/QgE+sSP2MSncsoKV1oEwvCHhSFOT/vBQ2FIC96Ck ZQer7qozKfGn1chZUNIS+oLtOUZkWlOLyeniyR2pIin6I02sLUf2ykMHy7ML3T045cn7 rBvQ== X-Gm-Message-State: ALoCoQmkppBDFUFukw4abWPEUkIzXHZcIfDlZw0MGnbCIKtzlYEA9XWElhqmauv/YhpwncqvWCPC X-Received: by 10.66.249.134 with SMTP id yu6mr32333716pac.37.1384192747357; Mon, 11 Nov 2013 09:59:07 -0800 (PST) Received: from [172.20.9.190] ([12.177.140.253]) by mx.google.com with ESMTPSA id nj9sm32196988pbc.13.2013.11.11.09.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 09:59:06 -0800 (PST) Message-ID: <52811AE9.4090106@mnt.se> Date: Mon, 11 Nov 2013 18:59:05 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> In-Reply-To: <52811A32.3010706@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:59:13 -0000 On 11/11/2013 06:56 PM, Stephen Farrell wrote: > Hiya, > > I think we got a great outcome last week, at the tech > plenary and all the other sessions where we discussed > pervasive monitoring. Thanks to everyone who sent mail, > presented or spoke at a mic for all your constructive > contributions. > > Sean and I chatted at the end of the week and figured > it'd be useful to refine the description of this list > to reflect that progress. Hopefully that'll help us > keep the list more focused between now and London. > Since this is not intended to be a working group, this > isn't a charter, but is a bit similar, so we'd like > to run it by the list in case any discussion is needed. > > We'd like to get that out of the way in the next few > days and then move on to discussion of how to go forward > with the bits and pieces of work that were identified > at the meeting and earlier on the list. (I need to go > back over the meeting notes and listen back to the audio > which I'll do in the next few days but let's get any > discussion of this out of the way first.) > > Our current revised list description based on all that > happened in Vancouver is as follows: > > " > The perpass list is for IETF discussion of pervasive > monitoring. > > IETF specifications need to be designed to protect against > pervasive monitoring where possible. This list is intended > for technical discussions attempting to meet that goal. > > Discussion is limited to specific technical proposals for > improvements in IETF protocols and to IETF process changes > aiming to increase the liklihood that implementation and > deployment of IETF protocols results in better mitigation > for pervasive monitoring. > > Those with proposals are encouraged to embody them in > detailed internet-draft specifications, rather than > relying solely email messages. > > The typical modus-operandi of the perpass list should be > to identify a credible piece of work, with identified > volunteer effort, and then to find a home for that work > within the IETF. Once such a home is identified work > should move to whatever other lists are relevant. > > Note that the perpass list is a non-working group list, > that is, there is no intent to form an IETF working > group on this topic. > " we could argue about words but I suggest not doing that giving this my "+1" > Comments welcome, and we'll get back about the plan for > specific work items in a few days. > > Thanks, > Stephen & Sean. > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hannes.tschofenig@gmx.net Mon Nov 11 10:06:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A4F11E81B2 for ; Mon, 11 Nov 2013 10:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78ecoFjnypA for ; Mon, 11 Nov 2013 10:06:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3277611E821A for ; Mon, 11 Nov 2013 10:05:59 -0800 (PST) Received: from Masham-MAC.local ([91.179.213.128]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MLR30-1VgU683hYo-000YNF for ; Mon, 11 Nov 2013 19:05:43 +0100 Message-ID: <52811C74.9030009@gmx.net> Date: Mon, 11 Nov 2013 19:05:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stephen Farrell References: <52811A32.3010706@cs.tcd.ie> In-Reply-To: <52811A32.3010706@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/xOTcQV5aWiCAYejJoRcmXwhpCPMEKVCBWYwrlecMu0eKsnA2os cAFEqiXYBXcj8HtKRkkwTb6fRPS0AeDBW0sNq/ngd43sD6wukGgNDxZHielLc5+niGjJfPf ANHiET8rvYxQQbY3emxTDXyPJYAJf+1XqMb6Zxm02zmbF+a3AaPy0VODEh4st6bNUYonRRD 6t+zgFtfSr5duM6Nv9Agw== Cc: perpass@ietf.org, hannes.tschofenig@gmx.net Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 18:06:12 -0000 Am 11.11.13 18:56, schrieb Stephen Farrell: > Discussion is limited to specific technical proposals for > improvements in IETF protocols So, the list would not be used for discussing the implementation or the deployment of IETF security protocols? As an example, the XMPP manifesto Peter distributed, see https://github.com/stpeter/manifesto, would not be in scope of the discussions. Ciao Hannes From wilton@isoc.org Mon Nov 11 10:18:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9821E821A for ; Mon, 11 Nov 2013 10:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czzjrNcQn6BR for ; Mon, 11 Nov 2013 10:18:34 -0800 (PST) Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 12FAA21E820A for ; Mon, 11 Nov 2013 10:18:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 241A0E8076; Mon, 11 Nov 2013 13:18:32 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 9E348E807D; Mon, 11 Nov 2013 13:18:31 -0500 (EST) References: <52811A32.3010706@cs.tcd.ie> In-Reply-To: <52811A32.3010706@cs.tcd.ie> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 11 Nov 2013 18:22:14 +0000 To: Stephen Farrell Cc: perpass Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 18:18:38 -0000 Thanks Stephen, I found the perpass session very constructive and useful, and I hope the sam= e spirit will drive e activities of the list/virtual group. I'd also just like to express my thanks for what I thought was an excellent c= ontribution to the Technical Plenary on your part. Bruce Schneier can't be a= n easy act to follow, and you did a great job. All the best, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 11 Nov 2013, at 17:56, Stephen Farrell wrote:= >=20 > Hiya, >=20 > I think we got a great outcome last week, at the tech > plenary and all the other sessions where we discussed > pervasive monitoring. Thanks to everyone who sent mail, > presented or spoke at a mic for all your constructive > contributions. >=20 > Sean and I chatted at the end of the week and figured > it'd be useful to refine the description of this list > to reflect that progress. Hopefully that'll help us > keep the list more focused between now and London. > Since this is not intended to be a working group, this > isn't a charter, but is a bit similar, so we'd like > to run it by the list in case any discussion is needed. >=20 > We'd like to get that out of the way in the next few > days and then move on to discussion of how to go forward > with the bits and pieces of work that were identified > at the meeting and earlier on the list. (I need to go > back over the meeting notes and listen back to the audio > which I'll do in the next few days but let's get any > discussion of this out of the way first.) >=20 > Our current revised list description based on all that > happened in Vancouver is as follows: >=20 > " > The perpass list is for IETF discussion of pervasive > monitoring. >=20 > IETF specifications need to be designed to protect against > pervasive monitoring where possible. This list is intended > for technical discussions attempting to meet that goal. >=20 > Discussion is limited to specific technical proposals for > improvements in IETF protocols and to IETF process changes > aiming to increase the liklihood that implementation and > deployment of IETF protocols results in better mitigation > for pervasive monitoring. >=20 > Those with proposals are encouraged to embody them in > detailed internet-draft specifications, rather than > relying solely email messages. >=20 > The typical modus-operandi of the perpass list should be > to identify a credible piece of work, with identified > volunteer effort, and then to find a home for that work > within the IETF. Once such a home is identified work > should move to whatever other lists are relevant. >=20 > Note that the perpass list is a non-working group list, > that is, there is no intent to form an IETF working > group on this topic. > " >=20 > Comments welcome, and we'll get back about the plan for > specific work items in a few days. >=20 > Thanks, > Stephen & Sean. >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From rutkowski.tony@gmail.com Mon Nov 11 11:10:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6217011E81CB for ; Mon, 11 Nov 2013 11:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9CyUk4S8yVh for ; Mon, 11 Nov 2013 11:10:56 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38A11E8186 for ; Mon, 11 Nov 2013 11:10:55 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id hu16so2210094qab.17 for ; Mon, 11 Nov 2013 11:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KTTn1dJbTPxJfpuZnGMy2YsOxaXgD7MIOYLMycr2Hgg=; b=kweKSX1mqQLfeQXP1ig1oQ3nY9XDL8+swJ5BdnziR79OnnHmtM6pxcSpGVJ5uBaQTB RrTuPYCGUfeDwzmrKpBnUKh0+0sYna/9isEf27yZgyH+qo7oaYgNTTERMI4EAVYMTqCC qSLtHxpYI05I1uJUJ3GIPWh1nxjH7liaFfrLjpefSgFCGt9YsppqG5imLwzUo1RTazPQ n1z/D3yeAPz/SoggPvGyOHnEy2lnhDARhWir0DeD0FO++NT819SNZvlbiOOG8XePnWCf YxcwoNortxQZy9tB9gzVq5Y2S4P+ZGgt16TnHnxUlZvlg4s4jJicF+i2DIi2p2PnwvXv if4Q== X-Received: by 10.224.24.201 with SMTP id w9mr21231536qab.103.1384197053938; Mon, 11 Nov 2013 11:10:53 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id h2sm61453726qaf.10.2013.11.11.11.10.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 11:10:53 -0800 (PST) Message-ID: <52812BBC.1050508@gmail.com> Date: Mon, 11 Nov 2013 14:10:52 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <52811A32.3010706@cs.tcd.ie> In-Reply-To: <52811A32.3010706@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:10:56 -0000 On 11/11/2013 12:56 PM, Stephen Farrell wrote: > IETF specifications need to be designed to protect against > pervasive monitoring where possible. This list is intended > for technical discussions attempting to meet that goal. Where "possible," or where "appropriate." Surely you are not inferring that every "specification" needs to be so designed? It seems context dependent. > Discussion is limited to specific technical proposals for > improvements in IETF protocols and to IETF process changes > aiming to increase the liklihood that implementation and > deployment of IETF protocols results in better mitigation > for pervasive monitoring. What if one believes that mitigation is not appropriate, or that it pervasive monitoring should be enhanced? Those apostates should go somewhere else? Guess you don't want discuss improving the protocols to enhance DPI or data retention. :-) cheers, tony From wilton@isoc.org Mon Nov 11 11:23:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6787B21E80EA for ; Mon, 11 Nov 2013 11:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.802 X-Spam-Level: X-Spam-Status: No, score=-101.802 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDnaNKalqWvI for ; Mon, 11 Nov 2013 11:23:15 -0800 (PST) Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEEF21E80E1 for ; Mon, 11 Nov 2013 11:23:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DA3441500AD; Mon, 11 Nov 2013 14:23:14 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 9C4D2150083; Mon, 11 Nov 2013 14:23:14 -0500 (EST) References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> In-Reply-To: <52812BBC.1050508@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6053B867-28BC-4642-BB82-606C6A8EB1AF@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 11 Nov 2013 19:26:58 +0000 To: "rutkowski.tony@gmail.com" Cc: perpass , Stephen Farrell Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:23:19 -0000 Tony, Since it's not plausible to assume you aren't aware of RFC 2804, I have to w= onder whether some of your comments below aren't just meant to be deliberate= ly provocative. Best wishes, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 11 Nov 2013, at 19:10, Tony Rutkowski wrote: > On 11/11/2013 12:56 PM, Stephen Farrell wrote: >> IETF specifications need to be designed to protect against >> pervasive monitoring where possible. This list is intended >> for technical discussions attempting to meet that goal. > Where "possible," or where "appropriate." >=20 > Surely you are not inferring that every "specification" > needs to be so designed? It seems context dependent. >> Discussion is limited to specific technical proposals for >> improvements in IETF protocols and to IETF process changes >> aiming to increase the liklihood that implementation and >> deployment of IETF protocols results in better mitigation >> for pervasive monitoring. > What if one believes that mitigation is not > appropriate, or that it pervasive monitoring > should be enhanced? Those apostates should > go somewhere else? >=20 > Guess you don't want discuss improving the > protocols to enhance DPI or data retention. :-) >=20 > cheers, > tony > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From gwiley@verisign.com Mon Nov 11 11:27:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A042D21E80E1 for ; Mon, 11 Nov 2013 11:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffV9sKi2t-0e for ; Mon, 11 Nov 2013 11:27:35 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00A11E8231 for ; Mon, 11 Nov 2013 11:27:29 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUoEvoJZq+jaXpElMjaEhlJ/KJG7aMwyJ@postini.com; Mon, 11 Nov 2013 11:27:35 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rABJRPTx027732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 14:27:25 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 11 Nov 2013 14:27:25 -0500 From: "Wiley, Glen" To: Stephane Bortzmeyer , Stephen Farrell Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiA Date: Mon, 11 Nov 2013 19:27:25 +0000 Message-ID: In-Reply-To: <20131111121027.GA31723@sources.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , Andy Wilson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:27:42 -0000 Stephane, Thanks for taking the time to capture this issue in a draft. I am very supporting of providing a means to make DNS confidential. A few comments from a reviewers perspective: Section 3.2: I realize that this is obvious, but it might be worth noting that there is often (typically) a network connection made to the subject of a DNS query sent from a stub resolver. For example after sending a query for www.example.com I am likely to make a connection via TCP to the address returned. This fact reduces the value of obscuring DNS queries at the last mile unless the most aggressive measures are taken (a VPN or tunnel). If an eavesdropper can dump traffic on the wire then they will see outbound connections to www.example.com and so it doesn't really matter whether they were able to see the DNS query. Section 3.3.3: While I agree with the sentiments in this section, is this in scope for this draft? This feels a little more like a reprise of arguments in favor of DNSSEC which does not address privacy at all. Section 4: There is enough overlap between sections 4 and 3.3 that I would combine section 4 and section 3.3 to address the problem of properly handling packet traces and captured DNS traffic in a way that protects end user privacy. Section 6.1 It feels as though this section dives into the solution rather than the problem=A9.something that needs to be done, but it feels out of scope for this draft. This could be addressed by changing the abstract of the draft or by reducing the content in this section. --=20 Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 11/11/13 7:10 AM, "Stephane Bortzmeyer" wrote: >On Wed, Sep 25, 2013 at 02:40:59PM +0200, > Stephane Bortzmeyer wrote > a message of 13 lines which said: > >> May be starting with the more modest but certainly useful "DNS >> privacy considerations" Internet-Draft? Such a document, just >> documenting the problem, would be a good idea, IMHO. > >Done.=20 >http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy >_______________________________________________ >perpass mailing list >perpass@ietf.org >https://www.ietf.org/mailman/listinfo/perpass From brian.e.carpenter@gmail.com Mon Nov 11 11:37:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794E21E80A5 for ; Mon, 11 Nov 2013 11:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPPV0-7aWvdM for ; Mon, 11 Nov 2013 11:37:46 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E145A21F8415 for ; Mon, 11 Nov 2013 11:37:45 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md4so5612482pbc.30 for ; Mon, 11 Nov 2013 11:37:36 -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=XK8Z/aOGHidL5ziRoCK00Wpxpr4uBxbVTl2qIUC9Yyg=; b=RVUwii2wSm729C6Xg1/vf7cQfkjrOJPiF0DGgGjTqMaZ4o56GF5ZgV6uKJTAzHbmm1 c0fYOAbnWVa43q4fHsobVMblEPRDAwwtQuniyjMYHGkmxkV2fy5hU/8sf1eacyrDAXAH mW0S1cyhvkGhjQHi40+a3zLSwDomdD0Bd+gkAOhOE+h4RHFMnayTWHV6kRg/kAklfj8Y nq+3P4cZjB1Yl64G+SbKSOrBxPckf8tBmoEyNuxOVyNkDtuxdOOpTNYZ9qavUcd7/JH7 ucPqwiozhCK9yS/qgXx41eSLfHEWrvPASzEOYdW6+BhZPOD6Bdd1Aeb6tKN+Z4oXEKbg lVyA== X-Received: by 10.68.190.229 with SMTP id gt5mr3444453pbc.177.1384198656351; Mon, 11 Nov 2013 11:37:36 -0800 (PST) Received: from [192.168.178.20] (34.198.69.111.dynamic.snap.net.nz. [111.69.198.34]) by mx.google.com with ESMTPSA id lm2sm38054982pab.2.2013.11.11.11.37.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 11:37:35 -0800 (PST) Message-ID: <528131FA.20301@gmail.com> Date: Tue, 12 Nov 2013 08:37:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rutkowski.tony@gmail.com References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> In-Reply-To: <52812BBC.1050508@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass , Stephen Farrell Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:37:47 -0000 On 12/11/2013 08:10, Tony Rutkowski wrote: ... > What if one believes that mitigation is not > appropriate, or that it pervasive monitoring > should be enhanced? Hi Tony, In the IETF we try to focus our lists on precise objectives. I didn't see you in Vancouver but I assume you watched the plenary (if not, it's available at www.ietf.org/live). Despite a few complaints about details of the way the hums at the end were phrased, the sense of the room was pretty clear: the plenary felt that pervasive surveillance is a technical attack and our technical specifications should defend against it. I take the proposed revised charter for this list as embodying that sense and describing a triage process for concrete technical proposals to achieve it. That seems appropriate to me. Brian From scott.brim@gmail.com Mon Nov 11 12:16:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7021E80E1 for ; Mon, 11 Nov 2013 12:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBPwyncB4mph for ; Mon, 11 Nov 2013 12:16:34 -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 638B611E8102 for ; Mon, 11 Nov 2013 12:16:34 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id wm4so4869702obc.18 for ; Mon, 11 Nov 2013 12:16:34 -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=ym32CM/fj2kz3Wd47V6t/Ka+XMXXQuywj8w/Mrtb1Sk=; b=nLcvN3OciGFIm80Zb+GaUEO7iqlvm8IoOWK+m+MHDP1p7dU6Dqcgo5BzHrGJGklHOK wJv6pX5JddVGERmz0R+HbOchBuRK5Wq5L5mYbmissLfICqGWZEvWXDmi9UyS8w8EXJMn ytsVxc2EMl8YF7rDKeVQTjKEMnSq2SyjUUxGtf1eJpzIF9JC7F2Y+qTGCXs8biql3dba SJ6U9iYh2afiyU5JapiBFC2oEJQq/6fTKLu5jxOQ7FfRUW4XEDLGIKJdAd41MwdfWcKw /Jyh/tyPb7Qi8/iYrob5e2kdDSUQ5a/kLFNxF+lXKPWfCUHxEtiG47pGclzfF/FSLU4B BKdw== MIME-Version: 1.0 X-Received: by 10.60.138.136 with SMTP id qq8mr3030965oeb.59.1384200993943; Mon, 11 Nov 2013 12:16:33 -0800 (PST) Received: by 10.182.2.134 with HTTP; Mon, 11 Nov 2013 12:16:33 -0800 (PST) In-Reply-To: <52811A32.3010706@cs.tcd.ie> References: <52811A32.3010706@cs.tcd.ie> Date: Mon, 11 Nov 2013 15:16:33 -0500 Message-ID: From: Scott Brim To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b41ccf88ab82c04eaec68fc Cc: perpass Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:16:35 -0000 --047d7b41ccf88ab82c04eaec68fc Content-Type: text/plain; charset=ISO-8859-1 > Discussion is limited to specific technical proposals for > improvements in IETF protocols and to IETF process changes > aiming to increase the liklihood that implementation and > deployment of IETF protocols results in better mitigation > for pervasive monitoring. Wording issue: "mitigation" is "the action of reducing the severity, seriousness, or painfulness". It would be best to (optionally) make it possible to block pervasive monitoring completely. Perhaps change "mitigation for" to something like "potential resistance to"? --047d7b41ccf88ab82c04eaec68fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Discussion is limited to specific technical proposals for
> impr= ovements in IETF protocols and to IETF process changes
> aiming to in= crease the liklihood that implementation and
> deployment of IETF pro= tocols results in better mitigation
> for pervasive monitoring.

Wording issue: "mitigation"= is "the action of reducing the severity, seriousness, or painfulness&= quot;. It would be best to (optionally) make it possible to block pervasive= monitoring completely.

Perhaps change "mitigation for" to something = like "potential resistance to"?

--047d7b41ccf88ab82c04eaec68fc-- From rutkowski.tony@gmail.com Mon Nov 11 12:26:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C759211E811D for ; Mon, 11 Nov 2013 12:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC8QILOuEA+q for ; Mon, 11 Nov 2013 12:26:48 -0800 (PST) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF211E8102 for ; Mon, 11 Nov 2013 12:26:48 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so4969504qej.7 for ; Mon, 11 Nov 2013 12:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mP/M6TsO1JXoh9xtExHXsRu1KjtAHaB1i5lHbrP8kYg=; b=YqNt/KgkD+itTuAqlBDvW5oLOEhZa+RAr0bggTUe4h/1i6E1cdmxTqndfA0B16wiyF QMc0/O4u3lMPWlAMj/BE8zdLg0A/wQK93bD/QkD15Z9892FKr0jv4x17OKkWVczrjisR 8T813FsGf5ZtD2LZSo33e9KcTiIG+9b0frxBTvUwQjujgdXrRvwqt8do6qOKwIilTGSS g3+sr8MUHSo5CxGGHyXHjU/SPp82BOp3fL3xusarPglMTBLz2Ia8sAGJAVSlzJWJ0QUp +fF0oSkH+6Nk92F+tZZi8+lX3ElnhuQ4dgvE8IoACR9fvyfZ++N/GCAgDrEhwULghSKo EJXA== X-Received: by 10.224.79.134 with SMTP id p6mr51945296qak.22.1384201607575; Mon, 11 Nov 2013 12:26:47 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id p17sm55558330qak.4.2013.11.11.12.26.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 12:26:46 -0800 (PST) Message-ID: <52813D85.405@gmail.com> Date: Mon, 11 Nov 2013 15:26:45 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Robin Wilton References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> <6053B867-28BC-4642-BB82-606C6A8EB1AF@isoc.org> In-Reply-To: <6053B867-28BC-4642-BB82-606C6A8EB1AF@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass , Stephen Farrell Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:26:48 -0000 Hi Robin, Brian, It's not clear why asking whether "IETF specifications need to be designed to protect against pervasive monitoring" without exceptions is "deliberatively provocative." And Brian, I don't care who met and what anyone through they hummed. It just seems to me that the assertion is extreme. RFC 2804 is at least neutral. It doesn't require swearing allegiance to a particular view or doing anything affirmative for ever activity of the organization. Furthermore, no one has yet defined what is even meant by "pervasive monitoring." That seems rather different from what RFC 2804 is attempting to cover. There might be all kinds of different forms and contexts of platforms that nominally fall under the aegis of pervasive monitoring that are perfectly appropriate if not needed. For example, the use of SMTP on my own network is arguably pervasive monitoring. Watching for malware at gateways is pervasive monitoring. I participate in a great many standards bodies, and have no particular allegiance or reverence for any them, including the IETF. You might consider that the IETF may have just gone off into religious territory of unquestionable belief that does not serve the IETF well. --tony On 11/11/2013 2:26 PM, Robin Wilton wrote: > Since it's not plausible to assume you aren't aware of RFC 2804, I have to wonder whether some of your comments below aren't just meant to be deliberately provocative. From wilton@isoc.org Mon Nov 11 13:41:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2554B11E8103 for ; Mon, 11 Nov 2013 13:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58E55hIkwLyK for ; Mon, 11 Nov 2013 13:40:56 -0800 (PST) Received: from smtp94.iad3a.emailsrvr.com (smtp94.iad3a.emailsrvr.com [173.203.187.94]) by ietfa.amsl.com (Postfix) with ESMTP id 041AA11E80F9 for ; Mon, 11 Nov 2013 13:40:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 897982600D1; Mon, 11 Nov 2013 16:40:55 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 56E552600AA; Mon, 11 Nov 2013 16:40:55 -0500 (EST) References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> In-Reply-To: <52812BBC.1050508@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5BF695F3-D8C2-4BDF-AB2D-40A2F8406C35@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 11 Nov 2013 21:44:39 +0000 To: "rutkowski.tony@gmail.com" Cc: perpass , Stephen Farrell Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:41:00 -0000 Tony, specifically, you mused on whether the IETF should work on specificati= ons that enhance pervasive monitoring, DPI and data retention.=20 I think RFC 2804 set out a very clear, principled IETF position on intercept= ion of communications. I think it would be strange if, at the first IETF s= ince the Snowden revelations, the consensus was to do more to enhance the te= chnology of wiretapping, rather than to reaffirm the principles on which 280= 4 was based. I hope this makes it clearer why there were parts of your email that I found= hard to accept at face value. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 11 Nov 2013, at 19:10, Tony Rutkowski wrote: > On 11/11/2013 12:56 PM, Stephen Farrell wrote: >> IETF specifications need to be designed to protect against >> pervasive monitoring where possible. This list is intended >> for technical discussions attempting to meet that goal. > Where "possible," or where "appropriate." >=20 > Surely you are not inferring that every "specification" > needs to be so designed? It seems context dependent. >> Discussion is limited to specific technical proposals for >> improvements in IETF protocols and to IETF process changes >> aiming to increase the liklihood that implementation and >> deployment of IETF protocols results in better mitigation >> for pervasive monitoring. > What if one believes that mitigation is not > appropriate, or that it pervasive monitoring > should be enhanced? Those apostates should > go somewhere else? >=20 > Guess you don't want discuss improving the > protocols to enhance DPI or data retention. :-) >=20 > cheers, > tony > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Mon Nov 11 14:03:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4F121E8138 for ; Mon, 11 Nov 2013 14:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H+ZSmRlD6mV for ; Mon, 11 Nov 2013 14:03: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 7975721E8092 for ; Mon, 11 Nov 2013 14:03:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CDE7BE59; Mon, 11 Nov 2013 22:03:29 +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 7njDXvDlACha; Mon, 11 Nov 2013 22:03:27 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.52.131]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 487C8BE56; Mon, 11 Nov 2013 22:03:27 +0000 (GMT) Message-ID: <5281542F.1080802@cs.tcd.ie> Date: Mon, 11 Nov 2013 22:03:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Scott Brim References: <52811A32.3010706@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:03:36 -0000 Hi Scott, On 11/11/2013 08:16 PM, Scott Brim wrote: >> Discussion is limited to specific technical proposals for >> improvements in IETF protocols and to IETF process changes >> aiming to increase the liklihood that implementation and >> deployment of IETF protocols results in better mitigation >> for pervasive monitoring. > > Wording issue: "mitigation" is "the action of reducing the severity, > seriousness, or painfulness". It would be best to (optionally) make it > possible to block pervasive monitoring completely. > > Perhaps change "mitigation for" to something like "potential resistance to"? To be honest, I think mitigation is really more accurate and will be more widely understood. The term is common when considering threats/attacks, whereas "resistance" could require explaining. S. > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Mon Nov 11 14:06:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937EE11E80F9 for ; Mon, 11 Nov 2013 14:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouj7eOQx7lZ1 for ; Mon, 11 Nov 2013 14:06:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B538911E8114 for ; Mon, 11 Nov 2013 14:06:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0A84BE59; Mon, 11 Nov 2013 22:05:59 +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 uJatJQeFFkkg; Mon, 11 Nov 2013 22:05:58 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.52.131]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88545BE56; Mon, 11 Nov 2013 22:05:58 +0000 (GMT) Message-ID: <528154C6.2090909@cs.tcd.ie> Date: Mon, 11 Nov 2013 22:05:58 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Hannes Tschofenig References: <52811A32.3010706@cs.tcd.ie> <52811C74.9030009@gmx.net> In-Reply-To: <52811C74.9030009@gmx.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:06:06 -0000 Hi Hannes, On 11/11/2013 06:05 PM, Hannes Tschofenig wrote: > Am 11.11.13 18:56, schrieb Stephen Farrell: >> Discussion is limited to specific technical proposals for >> improvements in IETF protocols > > > So, the list would not be used for discussing the implementation or the > deployment of IETF security protocols? > > As an example, the XMPP manifesto Peter distributed, see > https://github.com/stpeter/manifesto, would not be in scope of the > discussions. Good catch! That, and the like, should clearly be in scope. I'd count it as an improvement, though since its not a change that's probably not clear enough in the above. I've tidied up that paragraph to say: " Discussion is limited to specific technical proposals for improvements in IETF protocols, their implementation or deployment and to IETF process changes aiming to increase the liklihood that development, implementation and deployment of IETF protocols results in better mitigation for pervasive monitoring. " Cheers, S. > > Ciao > Hannes > > > > > From dhc@dcrocker.net Mon Nov 11 14:07:17 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7702F21E80F8 for ; Mon, 11 Nov 2013 14:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW7X3ZQ1dwv7 for ; Mon, 11 Nov 2013 14:07:09 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9CE921E811E for ; Mon, 11 Nov 2013 14:06:29 -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 rABM6FvE031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 14:06:18 -0800 Message-ID: <528154BC.6010900@dcrocker.net> Date: Mon, 11 Nov 2013 14:05:48 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Farrell , Scott Brim References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> In-Reply-To: <5281542F.1080802@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]); Mon, 11 Nov 2013 14:06:19 -0800 (PST) Cc: perpass Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:07:18 -0000 On 11/11/2013 2:03 PM, Stephen Farrell wrote: >> Perhaps change "mitigation for" to something like "potential resistance to"? > To be honest, I think mitigation is really more accurate Mitigation has a nicely clinical ring to it. I'm more worried about whether the 'for' should be an 'of'. Does this depend upon the English dialect at play? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Mon Nov 11 14:47:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDAD21E80DB for ; Mon, 11 Nov 2013 14:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkjre9soExSw for ; Mon, 11 Nov 2013 14:46:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA921E80BF for ; Mon, 11 Nov 2013 14:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32EDEBE62; Mon, 11 Nov 2013 22:46:51 +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 Ni4SPRS8ZAaN; Mon, 11 Nov 2013 22:46:49 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.52.131]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8226EBE5F; Mon, 11 Nov 2013 22:46:49 +0000 (GMT) Message-ID: <52815E59.8010606@cs.tcd.ie> Date: Mon, 11 Nov 2013 22:46:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rutkowski.tony@gmail.com, perpass References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> In-Reply-To: <52812BBC.1050508@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:47:02 -0000 Tony, On 11/11/2013 07:10 PM, Tony Rutkowski wrote: > On 11/11/2013 12:56 PM, Stephen Farrell wrote: >> IETF specifications need to be designed to protect against >> pervasive monitoring where possible. This list is intended >> for technical discussions attempting to meet that goal. > Where "possible," or where "appropriate." I think either is good enough. > Surely you are not inferring that every "specification" > needs to be so designed? It seems context dependent. >> Discussion is limited to specific technical proposals for >> improvements in IETF protocols and to IETF process changes >> aiming to increase the liklihood that implementation and >> deployment of IETF protocols results in better mitigation >> for pervasive monitoring. > What if one believes that mitigation is not > appropriate, or that it pervasive monitoring > should be enhanced? Those apostates should > go somewhere else? If someone believed that, then they would be unlikely to be a happy and constructive contributor on this list;-) As Brian points out, refining the list to this scope is entirely consistent with the Vancouver tech plenary outcome. If you want to disagree with the outcome of the Vancouver tech-plenary, then the list for that discussion would be ietf@ietf.org and not this one. And to be clear, yes, there is the implication that continued off-topic posting here (especially with occasional inflammatory content as has happened) could lead to an RFC 3683 PR-action, as I've previously explained to you in off list mail. I really hope you don't take us down that road, but I want to be clear that this refinement of the list description does mean that your continual statements that this work is some kind of religious quest are now quite clearly off-topic for this list. In contrast, calling out any actual flaws in proposals that are made is entirely within scope and is welcome. S. > Guess you don't want discuss improving the > protocols to enhance DPI or data retention. :-) > > cheers, > tony > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From rutkowski.tony@gmail.com Mon Nov 11 15:49:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367F421E80F4 for ; Mon, 11 Nov 2013 15:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbZLbfaOVLrR for ; Mon, 11 Nov 2013 15:49:07 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6C421E811E for ; Mon, 11 Nov 2013 15:49:06 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id k18so4819496qcv.10 for ; Mon, 11 Nov 2013 15:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SUYaMLGjOUTfaGGQcnpureNc7+l3XMiJI3qetWAzamM=; b=hGxLRNLq5Ivl7EQTNaK8fNOUlmRDgEXAmpTkbuO1WvKtxk7ZvRp0D1bg0WHjRvR/We 78OLtbcstDnG2e1EhPNtcGMHQIL2nt6OgRIN8lKEkoBF+MQHKw9CwIoyJI6wxsL21UKA RND7F/xYS5sdR5V9mGWHpechzA6ZBz98Ied/byLo6DwiiSDmraBZspmKB65/IUn7rsD0 8h+prPDu2a26wCLcky12MUXslmQlalB/VCURzQ0NVelzYoLUJRZkFWvMus+N2VM3UWsr Yj4zFLwFUbSxuaBY2C5PwstQyODzZJEwOyaMs6qJDWmcwtYL2qDubPUfppMkfe2+gebm HYAQ== X-Received: by 10.224.64.73 with SMTP id d9mr53780888qai.83.1384213746371; Mon, 11 Nov 2013 15:49:06 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-191-218.clppva.fios.verizon.net. [173.72.191.218]) by mx.google.com with ESMTPSA id b10sm56325427qeg.7.2013.11.11.15.49.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 15:49:05 -0800 (PST) Message-ID: <52816CF0.4070803@gmail.com> Date: Mon, 11 Nov 2013 18:49:04 -0500 From: Tony Rutkowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> <52815E59.8010606@cs.tcd.ie> In-Reply-To: <52815E59.8010606@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rutkowski.tony@gmail.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 23:49:08 -0000 Stephen, I think the dialogue here provides an ample indication of how extreme the behavior has become in the IETF. It is also interesting to contrast that behavior with the many other bodies industry bodies in this sector. I guess the IETF really provides a home for everyone. :-) --tony On 11/11/2013 5:46 PM, Stephen Farrell wrote: > If someone believed that, then they would be unlikely > to be a happy and constructive contributor on this list;-) > From hallam@gmail.com Mon Nov 11 21:33:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E031A11E819A for ; Mon, 11 Nov 2013 21:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+8yA7bHU4Uq for ; Mon, 11 Nov 2013 21:33:49 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D41611E810E for ; Mon, 11 Nov 2013 21:33:48 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so1473095lbv.6 for ; Mon, 11 Nov 2013 21:33:47 -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=c1rF9m+EcWeoHjMEBo0E1SmxYcix/gwaHshoR8lQiis=; b=LEG3tCbm+Nv1kzmYsPFox3HSNSzEvm/Q3k2xDh5tcVIp+iawQtAQyzuOSm1HLTRrs3 RKd/JRkJWUztzDFgzVTbIs2qB7dC11atNRVmYd1n0nZPwHJwTAk9mhzqogtDirjL79LX Inc9qr/v8It07R3Sk10Fy7iKOg5l/t3IyDP+g23ZLqW71F+6utGH7mPQjstqKBXGp/+c 8QNpP0Bx7kL1Pm1duM5Xm0zKce8xxklx4PB3JjFEkaduXyDoviFB7+2gcsvOjMAAWEqA X6XywAkg4Yvpi3pPWVd8QGf59xvoOhuLM9KnAWAcb0FBuY314stqcpwogZsnqxhayoaE z4kw== MIME-Version: 1.0 X-Received: by 10.152.10.99 with SMTP id h3mr26137423lab.13.1384234427281; Mon, 11 Nov 2013 21:33:47 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 11 Nov 2013 21:33:47 -0800 (PST) In-Reply-To: <5281542F.1080802@cs.tcd.ie> References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> Date: Tue, 12 Nov 2013 00:33:47 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1132f26a52f75604eaf431e3 Cc: perpass , Scott Brim Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:33:50 -0000 --001a1132f26a52f75604eaf431e3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 11, 2013 at 5:03 PM, Stephen Farrell wrote: > > Hi Scott, > > On 11/11/2013 08:16 PM, Scott Brim wrote: > >> Discussion is limited to specific technical proposals for > >> improvements in IETF protocols and to IETF process changes > >> aiming to increase the liklihood that implementation and > >> deployment of IETF protocols results in better mitigation > >> for pervasive monitoring. > > > > Wording issue: "mitigation" is "the action of reducing the severity, > > seriousness, or painfulness". It would be best to (optionally) make it > > possible to block pervasive monitoring completely. > > > > Perhaps change "mitigation for" to something like "potential resistance > to"? > > To be honest, I think mitigation is really more accurate > and will be more widely understood. The term is common when > considering threats/attacks, whereas "resistance" could > require explaining. In the Perpass session I pointed out that the problem is not limited to covert surveillance like the NSA has been practicing. The problem of overt surveillance is far harder to deal with. The government of North Korea just murdered 80 people for the 'crime' of watching South Korean TV [For comparison the communist system killed between 0.3 and 3.5 million in the 1994-1998 famine and would be killing as many again without foreign food aid].. We are not going to do much more than mitigate in such situations and it is quite likely that no standards based scheme is going to be appropriate because steganography is an essential part of the solution. -- Website: http://hallambaker.com/ --001a1132f26a52f75604eaf431e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 11, 2013 at 5:03 PM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Hi Scott,

On 11/11/2013 08:16 PM, Scott Brim wrote:
>> Discussion is limited to specific technical proposals for
>> improvements in IETF protocols and to IETF process changes
>> aiming to increase the liklihood that implementation and
>> deployment of IETF protocols results in better mitigation
>> for pervasive monitoring.
>
> Wording issue: "mitigation" is "the action of reducing = the severity,
> seriousness, or painfulness". It would be best to (optionally) ma= ke it
> possible to block pervasive monitoring completely.
>
> Perhaps change "mitigation for" to something like "pote= ntial resistance to"?

To be honest, I think mitigation is really more accurate
and will be more widely understood. The term is common when
considering threats/attacks, whereas "resistance" could
require explaining.

In the Perpass session = I pointed out that the problem is not limited to covert surveillance like t= he NSA has been practicing. The problem of overt surveillance is far harder= to deal with.

The government of North Korea just murdered 80 people f= or the 'crime' of watching South Korean TV [For comparison the comm= unist system killed between 0.3 and 3.5 million in the 1994-1998 famine and= would be killing as many again without foreign food aid]..

We are not going to do much more than mitigate in= such situations and it is quite likely that no standards based scheme is g= oing to be appropriate because steganography is an essential part of the so= lution.


--
Website: http://hallambaker.com/
--001a1132f26a52f75604eaf431e3-- From stephen.farrell@cs.tcd.ie Tue Nov 12 04:11:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1821E8105 for ; Tue, 12 Nov 2013 04:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFN0TfcvwPa1 for ; Tue, 12 Nov 2013 04:11:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 931D021E80EE for ; Tue, 12 Nov 2013 04:11:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2F56BE57 for ; Tue, 12 Nov 2013 12:11:16 +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 yTrUyvd0CGfT for ; Tue, 12 Nov 2013 12:11:16 +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 D9134BE56 for ; Tue, 12 Nov 2013 12:11:16 +0000 (GMT) Message-ID: <52821AE5.7020605@cs.tcd.ie> Date: Tue, 12 Nov 2013 12:11:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 12:11:23 -0000 Hiya, Way back in the mists of September there was a thread [1] on this that seemed to have broad agreement that this was a useful and quite doable change to TLS but I don't think we currently have a clear owner to push it along in the TLS WG. If everyone thinks someone else will get around to doing this, it won't happen. Any takers? Thanks, S. [1] https://www.ietf.org/mail-archive/web/perpass/current/msg00168.html From stephen.farrell@cs.tcd.ie Tue Nov 12 04:56:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02F721E810A for ; Tue, 12 Nov 2013 04:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWcWYTNBXwIT for ; Tue, 12 Nov 2013 04:55:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 08DC921E8104 for ; Tue, 12 Nov 2013 04:55:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0368ABE57 for ; Tue, 12 Nov 2013 12:55:53 +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 FNSsMXRNk+sx for ; Tue, 12 Nov 2013 12:55:52 +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 DDA7EBE54 for ; Tue, 12 Nov 2013 12:55:52 +0000 (GMT) Message-ID: <52822559.7030302@cs.tcd.ie> Date: Tue, 12 Nov 2013 12:55:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] orphan thread - on rfc 6302 and/or rfc 6325 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 12:56:02 -0000 Hiya, Another of these. We had a brief thread [1] on rfc 6302, and then Benoit/Brian told me it should really be about rfc 6325, so I'm not clear what's what, and I don't think we have an owner who's said they'd try do something here. I would guess it could be valuable to consider whether the 6325 mechanisms might be the basis on which to obsolete or update 6302 but again, if nobody wants to grab it and do work, nothing will happen. So, any takers for this one? Thanks, S. [1] https://www.ietf.org/mail-archive/web/perpass/current/msg00212.html From a.kuckartz@ping.de Tue Nov 12 06:16:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0605211E815F for ; Tue, 12 Nov 2013 06:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJUTXPhtNPKL for ; Tue, 12 Nov 2013 06:16:02 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id 9FF0511E8169 for ; Tue, 12 Nov 2013 06:16:01 -0800 (PST) Received: (qmail 1735 invoked from network); 12 Nov 2013 14:15:55 -0000 Received: (ofmipd 83.97.42.23); 12 Nov 2013 14:15:32 -0000 Received: from 85-22-129-24.ip.dokom21.de ([85.22.129.24] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1VgEkz-0003BV-QB; Tue, 12 Nov 2013 15:15:54 +0100 Date: 12 Nov 2013 15:15:51 +0100 Message-ID: <52823817.409@ping.de> From: "Andreas Kuckartz" To: "Stephen Farrell" MIME-Version: 1.0 References: <52821AE5.7020605@cs.tcd.ie> In-Reply-To: <52821AE5.7020605@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: [perpass] Issue tracker Re: orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:16:12 -0000 Stephen Farrell: > Way back in the mists of September there was a thread [1] > on this that seemed to have broad agreement that this was > a useful and quite doable change to TLS but I don't think > we currently have a clear owner to push it along in the > TLS WG. If everyone thinks someone else will get around to > doing this, it won't happen. > > Any takers? Does the IETF have an issue tracking system for such issues (besides mailing lists) ? Cheers, Andreas From stephen.farrell@cs.tcd.ie Tue Nov 12 06:21:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7C11E8178 for ; Tue, 12 Nov 2013 06:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myQiUJY4yCMa for ; Tue, 12 Nov 2013 06:21:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 944C211E8152 for ; Tue, 12 Nov 2013 06:21:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE068BE62; Tue, 12 Nov 2013 14:21:16 +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 UYPc8lEM9trn; Tue, 12 Nov 2013 14:21:16 +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 B5460BE5C; Tue, 12 Nov 2013 14:21:16 +0000 (GMT) Message-ID: <5282395D.8030301@cs.tcd.ie> Date: Tue, 12 Nov 2013 14:21:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andreas Kuckartz References: <52821AE5.7020605@cs.tcd.ie> <52823817.409@ping.de> In-Reply-To: <52823817.409@ping.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Issue tracker Re: orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:21:22 -0000 On 11/12/2013 02:15 PM, Andreas Kuckartz wrote: > Stephen Farrell: >> Way back in the mists of September there was a thread [1] >> on this that seemed to have broad agreement that this was >> a useful and quite doable change to TLS but I don't think >> we currently have a clear owner to push it along in the >> TLS WG. If everyone thinks someone else will get around to >> doing this, it won't happen. >> >> Any takers? > > Does the IETF have an issue tracking system for such issues (besides > mailing lists) ? Individual working groups manage that themselves so YMMV. For this activity I've been keeping track via a file:-) That's at [1] but I'm in the process of updating it based on all last week's events so the current version is out of date. I'll have it updated in the next few days with what I think is the current state of play when I'm done going over the meeting notes etc. Meanwhile, feel free to volunteer to take this one on if you're up for pushing the work along in the TLS WG. Cheers. S. [1] http://down.dsg.cs.tcd.ie/misc/perpass.txt > > Cheers, > Andreas > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From nick.a.mathewson@gmail.com Tue Nov 12 06:55:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBB811E8168 for ; Tue, 12 Nov 2013 06:55:11 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAR-7iGzACSK for ; Tue, 12 Nov 2013 06:55:10 -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 86A4011E815C for ; Tue, 12 Nov 2013 06:55:10 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id el20so5199255lab.18 for ; Tue, 12 Nov 2013 06:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zqYCSLlkraIscTHnj5fup8uhlZkVskY2Eqp+Pqf5H48=; b=zXFpZi6Gfx7585omhWD1/OFKY3AZxSOGBqXhBCR/VFIj7GFDiVuVe3q41KyyfQc9Xq Kqp0ev2Wu/e6XkmY9kaHLvPd1i73oqS3tuJfUzWuVdlNGgQCLIVfT35vyI0+88ZxRcG2 bZr3VzKDdl3aDwueWC1LQvz6zwJPwVURuRInPixl07EbJsuU8getq0SzUnoGbfDQNm7s PqFEtdGlUB1E4fJNZF5ogTiJ1aW9IBn2pb9Zyqw27/1lc922UhXDZO1K7V3swKuri3qS HSw0E6oq90AO/aNle8H6srhwBSU76vZcNA84CUKCfB2RNDbBERXWoCcotDZh+oTSQY+f 5CWA== MIME-Version: 1.0 X-Received: by 10.152.3.101 with SMTP id b5mr7566lab.74.1384268109463; Tue, 12 Nov 2013 06:55:09 -0800 (PST) Sender: nick.a.mathewson@gmail.com Received: by 10.112.75.165 with HTTP; Tue, 12 Nov 2013 06:55:09 -0800 (PST) In-Reply-To: <52821AE5.7020605@cs.tcd.ie> References: <52821AE5.7020605@cs.tcd.ie> Date: Tue, 12 Nov 2013 09:55:09 -0500 X-Google-Sender-Auth: MckhieOwRMmrO12r9ZBZeVw4y7A Message-ID: From: Nick Mathewson To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass Subject: Re: [perpass] orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:55:11 -0000 On Tue, Nov 12, 2013 at 7:11 AM, Stephen Farrell wrote: > > Hiya, > > Way back in the mists of September there was a thread [1] > on this that seemed to have broad agreement that this was > a useful and quite doable change to TLS but I don't think > we currently have a clear owner to push it along in the > TLS WG. If everyone thinks someone else will get around to > doing this, it won't happen. > > Any takers? I'd be glad to lend my enthusiasm, time, and modest sticktoitiveness, but I'd need somebody with more experience working in WGs to help me with the process stuff. (An update on the topic: OpenSSL has merged my patches to randomize gmt_unix_time by default. I also wrote a patch to allow tlsdate, the one known user of gmt_unix_time that people mentioned, to support reading the time from HTTPS headers. That patch has also been merged.) yrs, -- Nick Mathewson From benl@google.com Tue Nov 12 07:12:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E211E8168 for ; Tue, 12 Nov 2013 07:12:32 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDJM34jpFBeF for ; Tue, 12 Nov 2013 07:12:31 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8788D21F9F74 for ; Tue, 12 Nov 2013 07:12:31 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id if17so87635vcb.19 for ; Tue, 12 Nov 2013 07:12:31 -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=S1F6DqnOOpCC+XeZVbALFiWTCaHNN6UEFqGrdokiGrw=; b=jfFoOVPjl3Csel8+/LeD5c2Ds6nYut9ep29IrWLAdiXUi1QoJdaOsdMekXVGdSboUO SoESlwt5sl7wnlyzCYr1kM/Xrb6Og61hSFOkSMLekZyqpXME9t/bj3PMEgGzy0cLtHuz EA6d1Oy21YCoKOGgkPMVy6yEzQMa1ixoLcqlRwbtTiYAmU0DUE6JSpvD/tpDB7Xh4ynE kZfeVlNWItqlTDZk1QB/8HOXsQASOhVYHh4Tspse/d1U7fMrVZ+GtEF3EtMHWFhAPLV6 eovrVHtav6SEqCv7V85XB4aAHr49vjNwb5FUaQezXUTy+ftwQmCanF+3fdmK0Fzb7IFy XJaQ== 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=S1F6DqnOOpCC+XeZVbALFiWTCaHNN6UEFqGrdokiGrw=; b=Qvfl4V42KeaxkdJDVYLW8s3AcM6/WyhW8T/hB1J4E84bJOfRjg1cCRJFTsAORG0SBU s1BMBa9/LSC3TpYahkBBKx7jpIkx7OMWjFdeeBaFOVIfUKOvVBVxq5MAImxV/6xVVrjI Vom7JdwKnOQ8VBgNw8afLLZL0v0iJikh5E36sAkwq3XTB0JiZbEKqM6Ze/NeitSG44mk mMjhyjJpbRMy1xe01Nr3JIcDOIPpD/52x9/mutdub6nK356aioqCQ4xLXMCjk+9AXkxA xLgBUBEjW0ZrpBWFquP4TKoofrb1TSEHDdLqZbGK/4rKznDyHL9i0Q1eVKlZ3IC33al0 TT5w== X-Gm-Message-State: ALoCoQmUsm27tAOFJv3QX3W52U+nPdW74j6IJRlvX0cX8TYdAuBoyzRTojqgRz1ZbBZiAsmcr1Fr+mztqXdYqBg59Z1DztEHrJzio8h/WxrKlJUkN4lMVNrnWf13ddQPtDa/5YGHdajASded08dtcLIQIoRMXNamtq8PUAunJPczOXGnxrq9KLV4Eih91CH5CeAD8CoHrVI6 MIME-Version: 1.0 X-Received: by 10.52.52.232 with SMTP id w8mr72585vdo.53.1384269150865; Tue, 12 Nov 2013 07:12:30 -0800 (PST) Received: by 10.52.183.65 with HTTP; Tue, 12 Nov 2013 07:12:30 -0800 (PST) In-Reply-To: References: <52821AE5.7020605@cs.tcd.ie> Date: Tue, 12 Nov 2013 15:12:30 +0000 Message-ID: From: Ben Laurie To: Nick Mathewson Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Stephen Farrell Subject: Re: [perpass] orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:12:32 -0000 On 12 November 2013 14:55, Nick Mathewson wrote: > On Tue, Nov 12, 2013 at 7:11 AM, Stephen Farrell > wrote: >> >> Hiya, >> >> Way back in the mists of September there was a thread [1] >> on this that seemed to have broad agreement that this was >> a useful and quite doable change to TLS but I don't think >> we currently have a clear owner to push it along in the >> TLS WG. If everyone thinks someone else will get around to >> doing this, it won't happen. >> >> Any takers? > > I'd be glad to lend my enthusiasm, time, and modest sticktoitiveness, > but I'd need somebody with more experience working in WGs to help me > with the process stuff. I can help with process stuff. > (An update on the topic: OpenSSL has merged my patches to randomize > gmt_unix_time by default. I also wrote a patch to allow tlsdate, the > one known user of gmt_unix_time that people mentioned, to support > reading the time from HTTPS headers. That patch has also been merged.) > > yrs, > -- > Nick Mathewson > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From benl@google.com Tue Nov 12 07:21:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECD21E8146 for ; Tue, 12 Nov 2013 07:21:26 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-ZKcELMV868 for ; Tue, 12 Nov 2013 07:21:26 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04821E8145 for ; Tue, 12 Nov 2013 07:21:21 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id ij19so1908791vcb.17 for ; Tue, 12 Nov 2013 07:21:21 -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=VkY7VA3RdtTLe0MgfB353eJlKutG+Eb8ShSptBU9HDw=; b=dARlj1Gvd8vMLTsfm1XKH+UEKv2Zt4Iq+AwNkI5chOm3QaIWlczjwbgjc1mtrlg5e8 ZIYM97iXs8x8eqDvkh1XF+EVUiMUvKskfpNR0RLYFiZTPev2Vs85LEJOwpVDJBvj6EOs 7Iez11GpGv3ubpWBUiUx0efgthqrL8eogEH7S5gQ8VolJa21ek1v1JC/C6jsFLqM7Y2k YJST7JNqFw0SiG2I+AUuhO2+GqPIvqH5a2YUQQ7yYNhM7tppWVpUzcsne4jCRaE44t3z 51CZTtYsNX3nFZuYb2LVmW7ZiKykaT+Dteho6esET8GbpG135N5eTrGlg2oq01cu9U15 Du7w== 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=VkY7VA3RdtTLe0MgfB353eJlKutG+Eb8ShSptBU9HDw=; b=nKeUcoNCdc9lOW8jrgdDrVFoM/bhBtD57cqm+D86BxAiCQlylfnueaefJohfaQfeFE mC2fOGuK1yMBh9va6Z3WPKOol5TmAEqx4b9dgpj0Pyb7c3w1U5SQ2VCHzSma/V34beE3 +2YpS6NzFu7O39+7q2yHICAabKDO4j3hFZ1TfPcnX9qI8xsNG3fedWP0H6EssVChgVKx s6FIK3338ly9Eocfw5rcQ1ETzHnQaS/g7dPxQg6aYD9SZdRsIpQlppXJxI26PFKsYoGA 7pYiXPA5Q+WlaIqfZlEsrL7EPvbQGhGTL6U50wTzCOUBoKBVJi1JThml0tzIhiYl5inF P7dw== X-Gm-Message-State: ALoCoQla9ESIF6X0gXmU7DlXZ6e2eZHHhAjJIHfTI8P1ENKl4aCq73WlKZj4AxaTNo//8T66uTV2rP5xJnWEFNvxeCpsYTCTkzAOVzAWcZC3IsaVQpsG3aDmtdujamEiucl2PVoRXqnV1QjOnDv02T0wLN632UPZjX027R/gykIf5yeIDOb8rcFn1ciRFNwSKT3WMIti6O9R MIME-Version: 1.0 X-Received: by 10.221.6.195 with SMTP id ol3mr732478vcb.34.1384269681560; Tue, 12 Nov 2013 07:21:21 -0800 (PST) Received: by 10.52.183.65 with HTTP; Tue, 12 Nov 2013 07:21:21 -0800 (PST) In-Reply-To: <527A8C74.6020100@bbn.com> References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <527A82D5.3030502@bbn.com> <527A8C74.6020100@bbn.com> Date: Tue, 12 Nov 2013 15:21:21 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:21:27 -0000 On 6 November 2013 18:37, Stephen Kent wrote: > Ben, > >>> because the constrained chains begin somewhere below the TA, which leaves >>> EVERY >>> TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of >>> sovereign alignment to a PKI that many folks find attractive. >> >> For exactly the reason many find it unattractive :-) > > I am not a fan of viewing the Internet as an extra-national entity. > Maybe that makes me a heretic WRT Google's idea of cyberspace and reality > ;-) . > > Countries have a right to manage a lot of things within their borders, > and managing their DNS name spaces seems quite reasonable. Sure. But we were talking about key management. From trammell@tik.ee.ethz.ch Tue Nov 12 07:48:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A017D21E8257 for ; Tue, 12 Nov 2013 07:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiKPmC3mKjFV for ; Tue, 12 Nov 2013 07:48:05 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CD00D21E817D for ; Tue, 12 Nov 2013 07:47:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 36E1DD9303; Tue, 12 Nov 2013 16:47:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7srVgjhzSMHw; Tue, 12 Nov 2013 16:47:22 +0100 (MET) Received: from commodity-noc-40.sc13.org (commodity-noc-40.sc13.org [140.221.248.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 96BB4D9302; Tue, 12 Nov 2013 16:47:21 +0100 (MET) Message-ID: <52824D86.5000906@tik.ee.ethz.ch> Date: Tue, 12 Nov 2013 08:47:18 -0700 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Stephen Farrell References: <52822559.7030302@cs.tcd.ie> In-Reply-To: <52822559.7030302@cs.tcd.ie> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAD208A70CD53A865F0FC7168" Cc: perpass Subject: Re: [perpass] orphan thread - on rfc 6302 and/or rfc 6325 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:48:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD208A70CD53A865F0FC7168 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi Stephen, We'll address this problem briefly in the upcoming -ppa draft. 6325 would need a somewhat more detailed treatment on logging of user identifiers to be useful to the problem of reducing the usefulness of such logs for passive surveillance. This is kind of a minefield though, because I can't see a 6325-derived way to obfuscate logs that wouldn't also destroy their utility for debugging. There are also legal requirements in certain jurisdictions for log retention. The problem of distinguishing targeted investigation by a party with authorized access to the retained logs is a Layer 9 probl= em. Cheers, Brian Stephen Farrell wrote: > Hiya, >=20 > Another of these. We had a brief thread [1] on rfc 6302, and > then Benoit/Brian told me it should really be about rfc 6325, > so I'm not clear what's what, and I don't think we have an > owner who's said they'd try do something here. I would guess > it could be valuable to consider whether the 6325 mechanisms > might be the basis on which to obsolete or update 6302 but > again, if nobody wants to grab it and do work, nothing will > happen. >=20 > So, any takers for this one? >=20 > Thanks, > S. >=20 > [1] https://www.ietf.org/mail-archive/web/perpass/current/msg00212.html= > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------enigAD208A70CD53A865F0FC7168 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJSgk2HAAoJENt3nsOmbNJcVIoH+wVZOD+tLHOsW3qzuJgyJg+d rJ/EsZRKoPa3Oo+WCCX6jtfx+FBb6Q9IM8/A39QL0gNCBRi6RxzVecDjo5NuwwGK FtaWpFFTLn5N7XbdZXU6fPIHFnxjORUZMvcJub5VNxWOaRPMvVPKpms7yTS5Hm7U 7SI6OdvYcypOG0c8VLwtlhkTloGXxT3DusaN/3hLR8RRNVH+eEIbaJ31Sv+Tq93h 8piV/Y40HNzHsLJc7wdb2TLqUlig/oxk19NCGKa53PKgJaCTTQiP2ID6/4DlPply ZtSVPsVVT9x8FHPSgYaQALSuYIAEupybCuWvDwXY+LZSBSzmEyeL6SM0UlfMJHg= =Gb4b -----END PGP SIGNATURE----- --------------enigAD208A70CD53A865F0FC7168-- From hallam@gmail.com Tue Nov 12 08:05:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CC121E8255 for ; Tue, 12 Nov 2013 08:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt1iHC5TqtFK for ; Tue, 12 Nov 2013 08:05:11 -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 B32DE21E80A1 for ; Tue, 12 Nov 2013 08:05:10 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so2053527lbv.21 for ; Tue, 12 Nov 2013 08:05:09 -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=MXtUAVknl62Cz1x1NO7bE6FNHT/IomL7UTKqjqtY0OM=; b=nw2fcdqbgRQd5tjDKTaZ+HnoVe6daYkQzglPJLmD2IhvT9XfZFb3n8PPGCa4zOqKGG Xne0e2sYuH8PR5DO92/nqM4n7J5y4qSYVNS5N9kIhbR5r4VyF4oFld/ztPn9YuD+1Y2y olP92MnwETJC11RMWzo/a7IXD7SLGpSMHu8TWn4A4K62Uutp5XvRyCNpDALDSFzZKcnJ 3QpKK2+2SAd3rWhHQh70T57fb5jdXgjE0qHzghQRMlzWVV+fg/SDcgDEyg7hEImnrdw9 Plt4lmt4W9QuiIPoVMR/ev77Yelhb1RZI+CrDnfe/JCkpu+U3Af/h+G0u8/SmehTnaYM VkeA== MIME-Version: 1.0 X-Received: by 10.112.205.34 with SMTP id ld2mr9944614lbc.27.1384272309479; Tue, 12 Nov 2013 08:05:09 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 12 Nov 2013 08:05:09 -0800 (PST) Date: Tue, 12 Nov 2013 11:05:09 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c3d99a47709b04eafd036d Subject: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:05:13 -0000 --001a11c3d99a47709b04eafd036d Content-Type: text/plain; charset=ISO-8859-1 The biggest weakness in Internet protocols is relying on passwords for authentication. What can we do to make the password mechanisms more secure and to wean the Internet off passwords? I don't want to start an NSA rathole here, but I need evidence to support the above assertion and until the GRU or MOSSAD or PLA or whatever have their Snowden event, I am limited to using the NSA. 1) NSA using Password sniffing in Attack: http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html 2) The NSA gets rolled by Snowden using password sharing: http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=932 I don't think this problem is as insoluble as many imagine. What I think has been the show stopper is that strong authentication techniques are an all or nothing proposition that require both the site and the user to adopt before the scheme is useful. This double ended adoption requirement invariably leads to deployment deadlock in my experience. What I suggest as an alternative is the following: 1) The user decides to unilaterally use a password in the cloud scheme that allows them to store their passwords on one machine and access them from any of their browsers. 2) The password in the cloud scheme uses randomly generated passwords that are unique for each site and have 128 bits of randomness (min). 3) The browser implementing the password in the cloud scheme alerts the site being contacted to the fact that it can support a direct user authentication exchange that would make the user experience seamless and support single sign on. Note that this almost describes where we are right now. Pretty much every browser already offers password in the cloud service. They are forced to by market forces. But they don't support an interoperable, standards based password in the cloud service which is the requirement for us to get to step 3. Interoperability is also a requirement to get to step 2. I am not going to lock myself into one browser no matter how much the management of Google or Firefox or Apple or Microsoft want that. It is not going to happen and that is why I can't let the browser generate the password for me. I believe that we can make cloud log in a more secure option than current single factor authentication. Remember that 95% of Internet accounts are not financially sensitive. An authorization in the cloud service is completely acceptable to me as a means of storing my Slashdot username and password. The remaining 5% have important security concerns but the real issue is confirming critical transactions rather than access control to view the site info. A simple cloud log in scheme is more than sufficient for access to view my account details but I want a strong second factor to verify transfers out of my account place stock trades, etc. I plan to return to this after I get email security on a solid track with some code. -- Website: http://hallambaker.com/ --001a11c3d99a47709b04eafd036d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The biggest weakness in Internet protocols is relying on p= asswords for authentication. What can we do to make the password mechanisms= more secure and to wean the Internet off passwords?

I d= on't want to start an NSA rathole here, but I need evidence to support = the above assertion and until the GRU or MOSSAD or PLA or whatever have the= ir Snowden event, I am limited to using the NSA.


2) The NSA gets rolled by Snowden using password sharing:=A0= http://www.reuters.com/article/2013= /11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=3D932


I don't think this problem i= s as insoluble as many imagine. What I think has been the show stopper is t= hat strong authentication techniques are an all or nothing proposition that= require both the site and the user to adopt before the scheme is useful. T= his double ended adoption requirement invariably leads to deployment deadlo= ck in my experience.

What I suggest as an alternative is the following:

1) The user decides to unilaterally use a password in = the cloud scheme that allows them to store their passwords on one machine a= nd access them from any of their browsers.

2) The password in the cloud scheme uses randomly gener= ated passwords that are unique for each site and have 128 bits of randomnes= s (min).

3) The browser implementing the password = in the cloud scheme alerts the site being contacted to the fact that it can= support a direct user authentication exchange that would make the user exp= erience seamless and support single sign on.


Note that this almost describes where we= are right now. Pretty much every browser already offers password in the cl= oud service. They are forced to by market forces. But they don't suppor= t an interoperable, standards based password in the cloud service which is = the requirement for us to get to step 3.

Interoperability is also a requirement to get to step 2= .

I am not going to lock myself into one browser n= o matter how much the management of Google or Firefox or Apple or Microsoft= want that. It is not going to happen and that is why I can't let the b= rowser generate the password for me.


I believe that we can make cloud log in = a more secure option than current single factor authentication. Remember th= at 95% of Internet accounts are not financially sensitive. An authorization= in the cloud service is completely acceptable to me as a means of storing = my Slashdot username and password.

The remaining 5% have important security concerns but t= he real issue is confirming critical transactions rather than access contro= l to view the site info. A simple cloud log in scheme is more than sufficie= nt for access to view my account details but I want a strong second factor = to verify transfers out of my account place stock trades, etc.


I plan to return to this after I get ema= il security on a solid track with some code.

--
Web= site: http://hallambaker.com/
--001a11c3d99a47709b04eafd036d-- From ted.ietf@gmail.com Tue Nov 12 08:12:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB821E829A for ; Tue, 12 Nov 2013 08:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT2IF6S0Kr7E for ; Tue, 12 Nov 2013 08:12:18 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A621E828B for ; Tue, 12 Nov 2013 08:12:17 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id y10so2655398wgg.33 for ; Tue, 12 Nov 2013 08:12: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=WvGZ7LEcDmGgPE7NlLXt51WlS/OUNTWX/kOihGGuCQ8=; b=0jiQuyeuXCv/O/lqNCSQ6Wq+vr9iWOUJI5aqTyOPUoTf61pVzz6dmrWen/K5U9c96f C+qpxbfPeJyjAoBgOsnHRj4Z2UK0DRIAm57won5dWvfC30305NDUbIj4heXjj40FT9WD bP9K7o/Hi+t/2sduxehW8g0PLoFE4ZJ8/01FxC8PBtbGRjLWD2iULg74tjwC0GxZ9HHM maZnqB2XanfeOCSlZ15A4KcyZVfQcCvxGld2BaEhmpATk8wTVawD/XnRY7cxXGhJEDrN gdgTRYE+0ogbXpPH/pMR/7rQQ4k3Dgf/wmRffz9O1hOe918smMt3IoLGemoATGvJpWO9 oDvQ== MIME-Version: 1.0 X-Received: by 10.180.184.14 with SMTP id eq14mr17028063wic.56.1384272733349; Tue, 12 Nov 2013 08:12:13 -0800 (PST) Received: by 10.227.27.73 with HTTP; Tue, 12 Nov 2013 08:12:13 -0800 (PST) In-Reply-To: References: <20131111121027.GA31723@sources.org> Date: Tue, 12 Nov 2013 08:12:13 -0800 Message-ID: From: Ted Hardie To: "Wiley, Glen" Content-Type: multipart/alternative; boundary=001a11c2436e8b31a004eafd1cc5 Cc: perpass , Stephane Bortzmeyer , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:12:19 -0000 --001a11c2436e8b31a004eafd1cc5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some comments in-line. On Mon, Nov 11, 2013 at 11:27 AM, Wiley, Glen wrote: > Stephane, > > Thanks for taking the time to capture this issue in a draft. I am very > supporting of providing a means to make DNS confidential. > > A few comments from a reviewers perspective: > > Section 3.2: > > I realize that this is obvious, but it might be worth noting that there i= s > often (typically) a network connection made to the subject of a DNS query > sent from a stub resolver. For example after sending a query for > www.example.com I am likely to make a connection via TCP to the address > returned. This fact reduces the value of obscuring DNS queries at the > last mile unless the most aggressive measures are taken (a VPN or tunnel)= . > If an eavesdropper can dump traffic on the wire then they will see > outbound connections to www.example.com and so it doesn't really matter > whether they were able to see the DNS query. > > While I agree it reduces the value, it doesn't eliminate the value. One reason for this is services which provide different content at the same IP, often depending on the HTTP Host: header to disambiguate among the resources available. The DNS query tells you which resource was the target even if the HTTP flow was protected by TLS. The same is true when someone uses a stub resolver to query for DNS records using a local network before passing the traffic through a VPN (there are a variety of configurations in which this can happen). regards, Ted > Section 3.3.3: > > While I agree with the sentiments in this section, is this in scope for > this draft? This feels a little more like a reprise of arguments in favo= r > of DNSSEC which does not address privacy at all. > > Section 4: > > There is enough overlap between sections 4 and 3.3 that I would combine > section 4 and section 3.3 to address the problem of properly handling > packet traces and captured DNS traffic in a way that protects end user > privacy. > > Section 6.1 > > It feels as though this section dives into the solution rather than the > problem=C5=A0.something that needs to be done, but it feels out of scope = for > this draft. This could be addressed by changing the abstract of the draf= t > or by reducing the content in this section. > > > > -- > Glen Wiley > KK4SFV > > Sr. Engineer > The Hive, Verisign, Inc. > > > > > On 11/11/13 7:10 AM, "Stephane Bortzmeyer" wrote: > > >On Wed, Sep 25, 2013 at 02:40:59PM +0200, > > Stephane Bortzmeyer wrote > > a message of 13 lines which said: > > > >> May be starting with the more modest but certainly useful "DNS > >> privacy considerations" Internet-Draft? Such a document, just > >> documenting the problem, would be a good idea, IMHO. > > > >Done. > >http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy > >_______________________________________________ > >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 > --001a11c2436e8b31a004eafd1cc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some comments in-line.
=

On Mon, Nov 11, 2013 at 11:27 AM, Wiley,= Glen <gwiley@verisign.com> wrote:
Stephane,

Thanks for taking the time to capture this issue in a draft. I am very
supporting of providing a means to make DNS confidential.

A few comments from a reviewers perspective:

Section 3.2:

I realize that this is obvious, but it might be worth noting that there is<= br> often (typically) a network connection made to the subject of a DNS query sent from a stub resolver. =C2=A0For example after sending a query for
www.example.com I = am likely to make a connection via TCP to the address
returned. =C2=A0This fact reduces the value of obscuring DNS queries at the=
last mile unless the most aggressive measures are taken (a VPN or tunnel).<= br> If an eavesdropper can dump traffic on the wire then they will see
outbound connections to www.example.com and so it doesn't really matter
whether they were able to see the DNS query.


While I agree it reduces the value, it= doesn't eliminate the value.=C2=A0 One reason for this is services whi= ch provide different content at the same IP, often depending on the HTTP Ho= st: header to disambiguate among the resources available.=C2=A0 The DNS que= ry tells you which resource was the target even if the HTTP flow was protec= ted by TLS.=C2=A0 The same is true when someone uses a stub resolver to que= ry for DNS records using a local network before passing the traffic through= a VPN (there are a variety of configurations in which this can happen).


regards,

Ted
=C2=A0
Section 3.3.3:

While I agree with the sentiments in this section, is this in scope for
this draft? =C2=A0This feels a little more like a reprise of arguments in f= avor
of DNSSEC which does not address privacy at all.

Section 4:

There is enough overlap between sections 4 and 3.3 that I would combine
section 4 and section 3.3 to address the problem of properly handling
packet traces and captured DNS traffic in a way that protects end user
privacy.

Section 6.1

It feels as though this section dives into the solution rather than the
problem=C5=A0.something that needs to be done, but it feels out of scope fo= r
this draft. =C2=A0This could be addressed by changing the abstract of the d= raft
or by reducing the content in this section.



--
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.




On 11/11/13 7:10 AM, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:

>On Wed, Sep 25, 2013 at 02:40:59PM +0200,
> Stephane Bortzmeyer <bortzmeye= r@nic.fr> wrote
> a message of 13 lines which said:
>
>> May be starting with the more modest but certainly useful "DN= S
>> privacy considerations" Internet-Draft? Such a document, just=
>> documenting the problem, would be a good idea, IMHO.
>
>Done.
>http://tools.ietf.org/html/draft-bortzmeyer-perpass-= dns-privacy
>_______________________________________________
>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

--001a11c2436e8b31a004eafd1cc5-- From watsonbladd@gmail.com Tue Nov 12 08:14:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA4F11E810C for ; Tue, 12 Nov 2013 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEsA6ATfPQuq for ; Tue, 12 Nov 2013 08:14:32 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F111E8197 for ; Tue, 12 Nov 2013 08:14:32 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id m15so1722369wgh.18 for ; Tue, 12 Nov 2013 08:14:31 -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=9bFun74q43dosX0emCFWHUM2dNoHGM6O/4TnIlg9Y/g=; b=GzllZIUcz/miJG1OfAAEa3qQvgd25saXuz1SWOjupKjLqDNoBKrB99NQOtIn3iNdrL KAjDhu74inWepVl1kgT0Sa64afV8GRqXzGVNYkGpBZ100lT6Pyl7m08f7RfOLvj1HQ4I 9fpBtkrJiGDg1Fk/eGLVMNYbBlJGWP7WzeNiwmRV64cnuo7cplQqz50yfl7Lo3+gLUuK NujboofDIB+5N7GdDinlv6X1dVe2g+WM5mfMMzPeM0eTbodil3eASzrShKgoWAZUnkvu j201nkNcMpeKoyVYiohktewRXuIhhTYfcJBQWGPxAhjdOuRrCbH21RzVEDT1NNG5UB9X XwMw== MIME-Version: 1.0 X-Received: by 10.195.12.52 with SMTP id en20mr2085143wjd.55.1384272871433; Tue, 12 Nov 2013 08:14:31 -0800 (PST) Received: by 10.194.242.131 with HTTP; Tue, 12 Nov 2013 08:14:31 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 08:14:31 -0800 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:14:33 -0000 On Tue, Nov 12, 2013 at 8:05 AM, Phillip Hallam-Baker wrote: > The biggest weakness in Internet protocols is relying on passwords for > authentication. What can we do to make the password mechanisms more secure > and to wean the Internet off passwords? Passwords are fine provided they are not reused, and transmitted over secure channels. > > I don't want to start an NSA rathole here, but I need evidence to support > the above assertion and until the GRU or MOSSAD or PLA or whatever have > their Snowden event, I am limited to using the NSA. > > 1) NSA using Password sniffing in Attack: > http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html > > 2) The NSA gets rolled by Snowden using password sharing: > http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=932 > > > I don't think this problem is as insoluble as many imagine. What I think has > been the show stopper is that strong authentication techniques are an all or > nothing proposition that require both the site and the user to adopt before > the scheme is useful. This double ended adoption requirement invariably > leads to deployment deadlock in my experience. Client certificates are already supported and widely deployed. The DOD uses them on smartcards for just about everything. The big problem is a UI issue. > > What I suggest as an alternative is the following: > > 1) The user decides to unilaterally use a password in the cloud scheme that > allows them to store their passwords on one machine and access them from any > of their browsers. > > 2) The password in the cloud scheme uses randomly generated passwords that > are unique for each site and have 128 bits of randomness (min). > > 3) The browser implementing the password in the cloud scheme alerts the site > being contacted to the fact that it can support a direct user authentication > exchange that would make the user experience seamless and support single > sign on. And we still have passwords being used. The direct exchange=autofill. > > I believe that we can make cloud log in a more secure option than current > single factor authentication. Remember that 95% of Internet accounts are not > financially sensitive. An authorization in the cloud service is completely > acceptable to me as a means of storing my Slashdot username and password. So why does it need a 128-bit strong password? The issues you raised involve much stronger issues. > > The remaining 5% have important security concerns but the real issue is > confirming critical transactions rather than access control to view the site > info. A simple cloud log in scheme is more than sufficient for access to > view my account details but I want a strong second factor to verify > transfers out of my account place stock trades, etc. Somehow my mother's bank sent her a smart card and reader to validate transactions. Other banks use lists of one-time passwords, etc. This can be done today if the customers care. > > > I plan to return to this after I get email security on a solid track with > some code. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > 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 Tue Nov 12 08:26:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23821E80AA for ; Tue, 12 Nov 2013 08:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx2j+0LAbeMo for ; Tue, 12 Nov 2013 08:26:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA621E80A1 for ; Tue, 12 Nov 2013 08:26:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BCD7CBE59; Tue, 12 Nov 2013 16:26:27 +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 5F+sgG9YMWqn; Tue, 12 Nov 2013 16:26:27 +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 9E069BE25; Tue, 12 Nov 2013 16:26:27 +0000 (GMT) Message-ID: <528256B3.8040907@cs.tcd.ie> Date: Tue, 12 Nov 2013 16:26:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ben Laurie , Nick Mathewson References: <52821AE5.7020605@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:26:34 -0000 Nick, Ben, Great thanks - consider yourselves volunteered:-) I'd say whack out a draft-laurie-tls-notgmt or whatever and see if the TLS WG like that as an update to 5246. If they don't dislike it but don't wanna care/process it we can ask if they don't mind if its AD sponsored and take it that route. Thanks, S. On 11/12/2013 03:12 PM, Ben Laurie wrote: > On 12 November 2013 14:55, Nick Mathewson wrote: >> On Tue, Nov 12, 2013 at 7:11 AM, Stephen Farrell >> wrote: >>> >>> Hiya, >>> >>> Way back in the mists of September there was a thread [1] >>> on this that seemed to have broad agreement that this was >>> a useful and quite doable change to TLS but I don't think >>> we currently have a clear owner to push it along in the >>> TLS WG. If everyone thinks someone else will get around to >>> doing this, it won't happen. >>> >>> Any takers? >> >> I'd be glad to lend my enthusiasm, time, and modest sticktoitiveness, >> but I'd need somebody with more experience working in WGs to help me >> with the process stuff. > > I can help with process stuff. > >> (An update on the topic: OpenSSL has merged my patches to randomize >> gmt_unix_time by default. I also wrote a patch to allow tlsdate, the >> one known user of gmt_unix_time that people mentioned, to support >> reading the time from HTTPS headers. That patch has also been merged.) >> >> yrs, >> -- >> Nick Mathewson >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > From iain.learmonth.09@aberdeen.ac.uk Tue Nov 12 08:28:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEEC21E8210 for ; Tue, 12 Nov 2013 08:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzX8s8vXk+Ev for ; Tue, 12 Nov 2013 08:28:27 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26021E8202 for ; Tue, 12 Nov 2013 08:28:27 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 12 Nov 2013 16:28:23 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Tue, 12 Nov 2013 16:28:23 +0000 From: "Learmonth, Iain Ross" To: Watson Ladd , Phillip Hallam-Baker Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO38EMi+m3JSb4uUeoAPlhMDxny5ohxQeAgAABGtM= Date: Tue, 12 Nov 2013 16:28:23 +0000 Message-ID: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:2c90:8397:34e2:dae8] x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(199002)(189002)(51444003)(377454003)(11905935001)(52314003)(24454002)(87936001)(2656002)(51856001)(33646001)(69226001)(76786001)(76482001)(53806001)(76796001)(54356001)(59766001)(77982001)(551544002)(77096001)(15395725003)(74876001)(46102001)(87266001)(85306002)(56776001)(54316002)(56816003)(74706001)(551934002)(49866001)(74316001)(65816001)(80022001)(74502001)(47736001)(74482001)(81342001)(81816001)(50986001)(47446002)(47976001)(63696002)(15975445006)(81542001)(4396001)(81686001)(74366001)(79102001)(83072001)(74662001)(19580405001)(83322001)(19580395003)(80976001)(31966008)(15202345003)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB153; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:2c90:8397:34e2:dae8; 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: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:28:31 -0000 > 1) The user decides to unilaterally use a password in the cloud scheme th= at=0A= > allows them to store their passwords on one machine and access them from = any=0A= > of their browsers.=0A= =0A= I already do this with LastPass[1].=0A= =0A= If we want to move forward with authentication for things like websites tho= ugh, I'd rather see the cloud storing encrypted client certificates that ar= e synchronized and then decrypted client side by a password.=0A= =0A= > 3) The browser implementing the password in the cloud scheme alerts the s= ite=0A= > being contacted to the fact that it can support a direct user authenticat= ion=0A= > exchange that would make the user experience seamless and support single= =0A= > sign on.=0A= =0A= LastPass can do an "auto-login", but this would be completely seamless with= TLS client certs. If the site has to be changed anyway, why not do it prop= erly?=0A= =0A= This also leaves the option of having my certs on a smartcard, USB dongle, = floppy disk, etc. instead of just in the "cloud".=0A= =0A= Of course, if you wanted to build a system that syncs client certs, you cou= ld also add synchronizing of passwords into it, but I think that would only= really discourage the adoption of the client certs.=0A= =0A= Iain.=0A= =0A= [1]: https://lastpass.com/=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: perpass-bounces@ietf.org on behalf of Wats= on Ladd =0A= Sent: 12 November 2013 16:14=0A= To: Phillip Hallam-Baker=0A= Cc: perpass=0A= Subject: Re: [perpass] Stopping password sniffing=0A= =0A= On Tue, Nov 12, 2013 at 8:05 AM, Phillip Hallam-Baker wr= ote:=0A= > The biggest weakness in Internet protocols is relying on passwords for=0A= > authentication. What can we do to make the password mechanisms more secur= e=0A= > and to wean the Internet off passwords?=0A= Passwords are fine provided they are not reused, and transmitted over=0A= secure channels.=0A= >=0A= > I don't want to start an NSA rathole here, but I need evidence to support= =0A= > the above assertion and until the GRU or MOSSAD or PLA or whatever have= =0A= > their Snowden event, I am limited to using the NSA.=0A= >=0A= > 1) NSA using Password sniffing in Attack:=0A= > http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html=0A= >=0A= > 2) The NSA gets rolled by Snowden using password sharing:=0A= > http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idU= SBRE9A703020131108?irpc=3D932=0A= >=0A= >=0A= > I don't think this problem is as insoluble as many imagine. What I think = has=0A= > been the show stopper is that strong authentication techniques are an all= or=0A= > nothing proposition that require both the site and the user to adopt befo= re=0A= > the scheme is useful. This double ended adoption requirement invariably= =0A= > leads to deployment deadlock in my experience.=0A= Client certificates are already supported and widely deployed. The DOD=0A= uses them on smartcards=0A= for just about everything. The big problem is a UI issue.=0A= >=0A= > What I suggest as an alternative is the following:=0A= >=0A= > 1) The user decides to unilaterally use a password in the cloud scheme th= at=0A= > allows them to store their passwords on one machine and access them from = any=0A= > of their browsers.=0A= >=0A= > 2) The password in the cloud scheme uses randomly generated passwords tha= t=0A= > are unique for each site and have 128 bits of randomness (min).=0A= >=0A= > 3) The browser implementing the password in the cloud scheme alerts the s= ite=0A= > being contacted to the fact that it can support a direct user authenticat= ion=0A= > exchange that would make the user experience seamless and support single= =0A= > sign on.=0A= And we still have passwords being used. The direct exchange=3Dautofill.=0A= >=0A= =0A= > I believe that we can make cloud log in a more secure option than current= =0A= > single factor authentication. Remember that 95% of Internet accounts are = not=0A= > financially sensitive. An authorization in the cloud service is completel= y=0A= > acceptable to me as a means of storing my Slashdot username and password.= =0A= So why does it need a 128-bit strong password? The issues you raised=0A= involve much stronger=0A= issues.=0A= >=0A= > The remaining 5% have important security concerns but the real issue is= =0A= > confirming critical transactions rather than access control to view the s= ite=0A= > info. A simple cloud log in scheme is more than sufficient for access to= =0A= > view my account details but I want a strong second factor to verify=0A= > transfers out of my account place stock trades, etc.=0A= Somehow my mother's bank sent her a smart card and reader to validate=0A= transactions. Other banks=0A= use lists of one-time passwords, etc. This can be done today if the=0A= customers care.=0A= >=0A= >=0A= > I plan to return to this after I get email security on a solid track with= =0A= > some code.=0A= >=0A= > --=0A= > Website: http://hallambaker.com/=0A= >=0A= > _______________________________________________=0A= > perpass mailing list=0A= > perpass@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/perpass=0A= >=0A= =0A= =0A= =0A= --=0A= "Those who would give up Essential Liberty to purchase a little=0A= Temporary Safety deserve neither Liberty nor Safety."=0A= -- Benjamin Franklin=0A= _______________________________________________=0A= perpass mailing list=0A= perpass@ietf.org=0A= https://www.ietf.org/mailman/listinfo/perpass=0A= From tbray@textuality.com Tue Nov 12 08:29:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130AE11E810C for ; Tue, 12 Nov 2013 08:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKGW+zOY0v2x for ; Tue, 12 Nov 2013 08:29:16 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id C4DC421E820D for ; Tue, 12 Nov 2013 08:29:14 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id lf12so2128831vcb.12 for ; Tue, 12 Nov 2013 08:29:14 -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=+LX9EpTkoUH8R1VAIm/+jA9AFUqg0vd2mx33RDRNqRk=; b=Tw4IKnD5jffq2Z5z2QOxX/Pa8QtWxXnD8/9n/sfPtepyZbPlqipwNdtgDlDmMKdZo/ CIbSDKslRJMeQWZyOXTu2a8j3tHirmSjtEO7dhJpVKHzbw1ubBikAUbVgkr12YyO3f+J 0wlePV4StyjJ9LDjS9NQjCnf21cV5k0IaXUbhjMd4hDFxk5fflDFie3/bhS6LW34yUNE rotisKx1cSoCUenerRsM5T9oIETm8a45LShFcExRCvb7Boda5Y4P92t7iQpr63PpAoet tsVOPpwBl5Mw/+UkJdz1D1Q4cDz2Oy1QuiYmO0HCUEl8oKplWl8e2998HE/hpWeqRE2e sNxQ== X-Gm-Message-State: ALoCoQl4+Z80mo+P0POTMcEKN6mPAUrFr+NmZbRYK9Zeq5AYlKBx/ow0BiiRLd4wRlxPk6/vMz4e MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr10785610ved.20.1384273753915; Tue, 12 Nov 2013 08:29:13 -0800 (PST) Received: by 10.220.110.134 with HTTP; Tue, 12 Nov 2013 08:29:13 -0800 (PST) X-Originating-IP: [50.0.137.66] In-Reply-To: References: Date: Tue, 12 Nov 2013 08:29:13 -0800 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bf15fc861207404eafd59b1 Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:29:21 -0000 --047d7bf15fc861207404eafd59b1 Content-Type: text/plain; charset=UTF-8 In terms of minimizing password pain/insecurity, you should check out the work of the Fido Alliance, which seems very promising to me. They are trying to cook up a protocol to describe the use of various 2-factor hardware such as smart cards, USB keys, number dongles, biometrics, and so on, so that you can use that stuff without getting tied to a particular vendor/implementation. Yubikey has some very slick demos. On Tue, Nov 12, 2013 at 8:05 AM, Phillip Hallam-Baker wrote: > The biggest weakness in Internet protocols is relying on passwords for > authentication. What can we do to make the password mechanisms more secure > and to wean the Internet off passwords? > > I don't want to start an NSA rathole here, but I need evidence to support > the above assertion and until the GRU or MOSSAD or PLA or whatever have > their Snowden event, I am limited to using the NSA. > > 1) NSA using Password sniffing in Attack: > http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html > > 2) The NSA gets rolled by Snowden using password sharing: > http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=932 > > > I don't think this problem is as insoluble as many imagine. What I think > has been the show stopper is that strong authentication techniques are an > all or nothing proposition that require both the site and the user to adopt > before the scheme is useful. This double ended adoption requirement > invariably leads to deployment deadlock in my experience. > > What I suggest as an alternative is the following: > > 1) The user decides to unilaterally use a password in the cloud scheme > that allows them to store their passwords on one machine and access them > from any of their browsers. > > 2) The password in the cloud scheme uses randomly generated passwords that > are unique for each site and have 128 bits of randomness (min). > > 3) The browser implementing the password in the cloud scheme alerts the > site being contacted to the fact that it can support a direct user > authentication exchange that would make the user experience seamless and > support single sign on. > > > Note that this almost describes where we are right now. Pretty much every > browser already offers password in the cloud service. They are forced to by > market forces. But they don't support an interoperable, standards based > password in the cloud service which is the requirement for us to get to > step 3. > > Interoperability is also a requirement to get to step 2. > > I am not going to lock myself into one browser no matter how much the > management of Google or Firefox or Apple or Microsoft want that. It is not > going to happen and that is why I can't let the browser generate the > password for me. > > > I believe that we can make cloud log in a more secure option than current > single factor authentication. Remember that 95% of Internet accounts are > not financially sensitive. An authorization in the cloud service is > completely acceptable to me as a means of storing my Slashdot username and > password. > > The remaining 5% have important security concerns but the real issue is > confirming critical transactions rather than access control to view the > site info. A simple cloud log in scheme is more than sufficient for access > to view my account details but I want a strong second factor to verify > transfers out of my account place stock trades, etc. > > > I plan to return to this after I get email security on a solid track with > some code. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --047d7bf15fc861207404eafd59b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In terms of minimizing password pain/insecurity, you shoul= d check out the work of the Fido Alliance, which seems very promising to me= . =C2=A0They are trying to cook up a protocol to describe the use of variou= s 2-factor hardware such as smart cards, USB keys, number dongles, biometri= cs, and so on, so that you can use that stuff without getting tied to a par= ticular vendor/implementation. Yubikey has some very slick demos.


On Tue, Nov 1= 2, 2013 at 8:05 AM, Phillip Hallam-Baker <hallam@gmail.com> w= rote:
The biggest weakness in Int= ernet protocols is relying on passwords for authentication. What can we do = to make the password mechanisms more secure and to wean the Internet off pa= sswords?

I don't want to start an NSA rathole here, but I need ev= idence to support the above assertion and until the GRU or MOSSAD or PLA or= whatever have their Snowden event, I am limited to using the NSA.

1) NSA using Password sniffing in Attack:=C2=A0http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-li= nke.html



I don't think this problem i= s as insoluble as many imagine. What I think has been the show stopper is t= hat strong authentication techniques are an all or nothing proposition that= require both the site and the user to adopt before the scheme is useful. T= his double ended adoption requirement invariably leads to deployment deadlo= ck in my experience.

What I suggest as an alternative is the following:

1) The user decides to unilaterally use a password in = the cloud scheme that allows them to store their passwords on one machine a= nd access them from any of their browsers.

2) The password in the cloud scheme uses randomly gener= ated passwords that are unique for each site and have 128 bits of randomnes= s (min).

3) The browser implementing the password = in the cloud scheme alerts the site being contacted to the fact that it can= support a direct user authentication exchange that would make the user exp= erience seamless and support single sign on.


Note that this almost describes where we= are right now. Pretty much every browser already offers password in the cl= oud service. They are forced to by market forces. But they don't suppor= t an interoperable, standards based password in the cloud service which is = the requirement for us to get to step 3.

Interoperability is also a requirement to get to step 2= .

I am not going to lock myself into one browser n= o matter how much the management of Google or Firefox or Apple or Microsoft= want that. It is not going to happen and that is why I can't let the b= rowser generate the password for me.


I believe that we can make cloud log in = a more secure option than current single factor authentication. Remember th= at 95% of Internet accounts are not financially sensitive. An authorization= in the cloud service is completely acceptable to me as a means of storing = my Slashdot username and password.

The remaining 5% have important security concerns but t= he real issue is confirming critical transactions rather than access contro= l to view the site info. A simple cloud log in scheme is more than sufficie= nt for access to view my account details but I want a strong second factor = to verify transfers out of my account place stock trades, etc.


I plan to return to this after I get ema= il security on a solid track with some code.

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

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


--047d7bf15fc861207404eafd59b1-- From nweaver@icsi.berkeley.edu Tue Nov 12 08:38:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF321F9DB8 for ; Tue, 12 Nov 2013 08:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVB6dQTsynaO for ; Tue, 12 Nov 2013 08:38:07 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2664821E80AC for ; Tue, 12 Nov 2013 08:37:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DB66A2C4016; Tue, 12 Nov 2013 08:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zunBochE8Phl; Tue, 12 Nov 2013 08:37:26 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 267C82C4014; Tue, 12 Nov 2013 08:37:26 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C54D4097-01E9-44AA-9B17-9B22C7644E57"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Tue, 12 Nov 2013 08:37:25 -0800 Message-Id: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: [perpass] Stopping packet injection: the network is attacking us (was re Password Sniffing) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:38:47 -0000 --Apple-Mail=_C54D4097-01E9-44AA-9B17-9B22C7644E57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker = wrote: > The biggest weakness in Internet protocols is relying on passwords for = authentication. What can we do to make the password mechanisms more = secure and to wean the Internet off passwords? >=20 > I don't want to start an NSA rathole here, but I need evidence to = support the above assertion and until the GRU or MOSSAD or PLA or = whatever have their Snowden event, I am limited to using the NSA. >=20 > 1) NSA using Password sniffing in Attack: = http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html Thats false. They didn't use password sniffing in this attack. And = overall reporting on that was pretty dismal. =20 This was targeting information for a QUANTUMINSERT attack [1], aka = packet injection/Man-on-the-Side for exploitation. And there was no = fake slashdot page, just fake packets. I wish they were just password = sniffing. The goal is victim browser exploitation, using one of the two following = possibilities (i'd bet the former, but both mechanisms effectively do = the same thing): a) The NSA identifies those individuals it wants to target (in this = case, technical employees at telco/internet firms in allied countries.) b) The NSA's wiretap waits for a Slashdot or LinkedIn page [1] = indicating that the intended victim is logged in by examining page = contents. Once it has identified an intended victim, it now has the = cookies for the victim.=20 c) On the next fetch from the victim to the targeted site (ideally for = some inconsequential element, but with some tricks you can do it for a = main-page), "shoot" a packet injection attack to have some = inconsequential element redirect the victim to an exploit server (NSA = calls this FOXACID, we civilians can do the same thing with Metasploit's = HTTP server). OR b) Look for DNS requests for Slashdot or Linkedin from possible = victims, and packet inject a DNS reply to your proxy server... Packet injection in either case is used instead of a traditional MITM = because its effectively as powerful for anything w/o cryptography, yet = much safer to install and use, since failures don't result in = communication cuts, if you can't keep up you don't disrupt the network, = its easier to install both with and without consent (after all, its = 'just' a wiretap), etc. The NSA has now created a world where any plaintext traffic isn't just = an information leakage, but a potential vehicle for exploitation! And by attacking allies as well as enemies, using a mechanism that is = available (albeit without quite as much targeting precision) to = effectively any adversary with a tap (France, China, Russia, Brazil, = Israel, pretty much anybody can play these games [3]), the network = backbone just became an incredibly hostile place. If you are lucky, your adversary is any country your traffic passes = through you other than your own. If you are lucky. [1] QUANTUM is the code-word/program for packet injection, and this is = confirmed by Schneier's analysis of Snowden documents. In Schneier's = analysis he specifically linked to public speculation I made months = earlier. [2] ANY cleartext site which identifies logged in users will do, as long = as the NSA has a sufficient parser to map page reply to user = identification. [3] Please contact your local Gamma International, hackingteam.it, and = Vulpen sales representatives for details. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_C54D4097-01E9-44AA-9B17-9B22C7644E57 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 iQIcBAEBCgAGBQJSgllFAAoJEG2B1w+SDi/uGdkQALHbkxntXTcFnJs9KY3opSVi zZE+l6ktYTyRhv0Z5NAUkdsZw4iyPCHHDXsyvh2vJdAC1RvJZmgBkAUPaxm7+wC4 U/TKRwQ4T6EiU/dFp0f7f8pBlb8zVhL6su+QZHrfoaZ374JuE4tjN3334AMgfN/t zXrlzDMzJX2uKel9dmz/caRQjTeKViI1uIqiHxZPVq0GHwcwZsPx8brKOgbMnbDV nP95LpM7IZ/PQvCgIufR3zO7sFXgyO05//0DFVnL8ZiFvpjjIdnRs+NGh97N+e2D vBA/R7fLrfItkzfV4Omry5hvBRNz05SdVg3LgHwBRBZwWSgr2GaAHzgDbrcQZNZ1 O/sIMcCNcZjhJYjneN1bb/w2C9dkCFbnTI4NWHjnUm0HM7hCbkPnRncFrjKG4yaC 6bRqIZM16Vfb6UBWkCPbn7keYa+9YQ3qbiaRcYqt/Rcuxd76jRSaJ/vXJpqfpDG+ +C5tTYI5JFpHNeFhv2Hp7759tm7qFWbSnz+Wc+YcGlZiZOZxlJEjXR4tVp7bzTVZ SFutAZq7ZC5rtFJy0hZJo4eJCGgmsA4DqCrWJtFKaZ34qbG7HWJbfgHd/y/EKh6n jWXwVtH2rgc1WG7VZtmuTIDzF0UeXf0fFUrFzMEFe5HcPPktXfCeUNE6o8/9zctP ds7JXTOHpOP6EDQh1TCl =2as2 -----END PGP SIGNATURE----- --Apple-Mail=_C54D4097-01E9-44AA-9B17-9B22C7644E57-- From wilton@isoc.org Tue Nov 12 08:50:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7321E81D1 for ; Tue, 12 Nov 2013 08:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSDibKecdRKm for ; Tue, 12 Nov 2013 08:50:40 -0800 (PST) Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6AA11E81AD for ; Tue, 12 Nov 2013 08:50:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 897FFE07AE; Tue, 12 Nov 2013 11:50:25 -0500 (EST) X-Virus-Scanned: OK Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id BF671E0755; Tue, 12 Nov 2013 11:50:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_D7D179FD-BB46-4BB3-8F8B-548C34E3CFBA"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Tue, 12 Nov 2013 16:50:07 +0000 Message-Id: <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> References: , <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> To: "Learmonth, Iain Ross" X-Mailer: Apple Mail (2.1283) Cc: Watson Ladd , perpass , Phillip Hallam-Baker Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:50:44 -0000 --Apple-Mail=_D7D179FD-BB46-4BB3-8F8B-548C34E3CFBA Content-Type: multipart/alternative; boundary="Apple-Mail=_114001FE-5318-4DEE-8A9A-8B84A42632D6" --Apple-Mail=_114001FE-5318-4DEE-8A9A-8B84A42632D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Iain, On 12 Nov 2013, at 16:28, Learmonth, Iain Ross wrote: >> 1) The user decides to unilaterally use a password in the cloud = scheme that >> allows them to store their passwords on one machine and access them = from any >> of their browsers. >=20 > I already do this with LastPass[1]. >=20 > If we want to move forward with authentication for things like = websites though, I'd rather see the cloud storing encrypted client = certificates that are synchronized and then decrypted client side by a = password. This sounds interesting and rational, but it contains a lot of implied = detail. Can you unpack it a little, e.g. explaining what's in the = certificate, why it needs to be stored in that form, why it's encrypted, = which steps of the protocol are assumed to depend on session-level = encryption, and so on? =20 Thx, Robin >=20 >> 3) The browser implementing the password in the cloud scheme alerts = the site >> being contacted to the fact that it can support a direct user = authentication >> exchange that would make the user experience seamless and support = single >> sign on. >=20 > LastPass can do an "auto-login", but this would be completely seamless = with TLS client certs. If the site has to be changed anyway, why not do = it properly? >=20 > This also leaves the option of having my certs on a smartcard, USB = dongle, floppy disk, etc. instead of just in the "cloud". >=20 > Of course, if you wanted to build a system that syncs client certs, = you could also add synchronizing of passwords into it, but I think that = would only really discourage the adoption of the client certs. >=20 > Iain. >=20 > [1]: https://lastpass.com/ --Apple-Mail=_114001FE-5318-4DEE-8A9A-8B84A42632D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Iain,


On 12 Nov 2013, at 16:28, Learmonth, Iain Ross = wrote:

1) The user decides to = unilaterally use a password in the cloud scheme = that
allows them to store = their passwords on one machine and access them from = any
of their = browsers.

I already do this with = LastPass[1].

If we want to move forward with authentication for = things like websites though, I'd rather see the cloud storing encrypted = client certificates that are synchronized and then decrypted client side = by a password.

This sounds = interesting and rational, but it contains a lot of implied detail. Can = you unpack it a little, e.g. explaining what's in the certificate, why = it needs to be stored in that form, why it's encrypted, which steps of = the protocol are assumed to depend on session-level encryption, and so = on?   =  

Thx,
Robin


3) The browser = implementing the password in the cloud scheme alerts the = site
being contacted to the = fact that it can support a direct user = authentication
exchange that = would make the user experience seamless and support = single
sign = on.

LastPass can do an "auto-login", but this would = be completely seamless with TLS client certs. If the site has to be = changed anyway, why not do it properly?

This also leaves the = option of having my certs on a smartcard, USB dongle, floppy disk, etc. = instead of just in the "cloud".

Of course, if you wanted to build = a system that syncs client certs, you could also add synchronizing of = passwords into it, but I think that would only really discourage the = adoption of the client certs.

Iain.

[1]: https://lastpass.com/

= --Apple-Mail=_114001FE-5318-4DEE-8A9A-8B84A42632D6-- --Apple-Mail=_D7D179FD-BB46-4BB3-8F8B-548C34E3CFBA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTEyMTY1MDA3WjAjBgkqhkiG9w0BCQQxFgQUS8bCCvRZiiLhUMkbxXW7 Cq1Z5E8wdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAAykhyZjMbL0fT7NacfvPWrb w7b8DkhH2fBgsEwIGrJpTNxLliGdYKkfmtgMYs9fupro2jWGA/ISScQC6FVAuz33Mu5Ocoj73frY KYkqhkoCMQLpYfRkAUt4sakxABalD7QH75XSuV4Z4wmY3kGc05LH9pXN2CyLbOwKDzlDd/r5AUpq PKAIQYlXOUwbtCzLlzLp+bfenFDa+YOgPts8Km3MYMYLGo0mqGsuR88uDlMI8CGI22QlLF1syS3k DR/W3ddKM1gQVV8IqNXotUNdKjJDFGBBqLEdOoNXMXtdFQpp32HTD3nV1Rv8ai6TBggh5XR2l+b2 S3AwL1lXRp4wT80AAAAAAAA= --Apple-Mail=_D7D179FD-BB46-4BB3-8F8B-548C34E3CFBA-- From wilton@isoc.org Tue Nov 12 08:56:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD521E8122 for ; Tue, 12 Nov 2013 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFpF0QelOhgq for ; Tue, 12 Nov 2013 08:56:29 -0800 (PST) Received: from smtp102.iad3a.emailsrvr.com (smtp102.iad3a.emailsrvr.com [173.203.187.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1B21E81C4 for ; Tue, 12 Nov 2013 08:56:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 275AA1280B8; Tue, 12 Nov 2013 11:56:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 702A71280C0; Tue, 12 Nov 2013 11:56:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_921CC7C1-9AE7-49A0-8773-455795994E93"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> Date: Tue, 12 Nov 2013 16:56:01 +0000 Message-Id: <81D58F19-1C6E-465C-889B-26D12CE824C3@isoc.org> References: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1283) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Stopping packet injection: the network is attacking us (was re Password Sniffing) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:56:36 -0000 --Apple-Mail=_921CC7C1-9AE7-49A0-8773-455795994E93 Content-Type: multipart/alternative; boundary="Apple-Mail=_EB3D9EF9-79BE-4E5F-970F-145676388EC6" --Apple-Mail=_EB3D9EF9-79BE-4E5F-970F-145676388EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 For once, I am delighted that the LinkedIn authentication URL embedded = in their emails to me never works... (the redirect to LinkedIn seems to work, but then the site goes into a = tight loop for some reason I am really not motivated to figure out). Incidentally, if I understood Nick's analysis correctly, steps (b) and ( = c ) are a good example of why I distrust app-based clients for services = like LinkedIn - because it seems far harder to stop them using = replayable long-term tokens than it is to stop a browser from doing so. R =20 Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 12 Nov 2013, at 16:37, Nicholas Weaver wrote: >=20 > On Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker = wrote: >=20 >> The biggest weakness in Internet protocols is relying on passwords = for authentication. What can we do to make the password mechanisms more = secure and to wean the Internet off passwords? >>=20 >> I don't want to start an NSA rathole here, but I need evidence to = support the above assertion and until the GRU or MOSSAD or PLA or = whatever have their Snowden event, I am limited to using the NSA. >>=20 >> 1) NSA using Password sniffing in Attack: = http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html >=20 > Thats false. They didn't use password sniffing in this attack. And = overall reporting on that was pretty dismal. =20 >=20 > This was targeting information for a QUANTUMINSERT attack [1], aka = packet injection/Man-on-the-Side for exploitation. And there was no = fake slashdot page, just fake packets. I wish they were just password = sniffing. >=20 >=20 > The goal is victim browser exploitation, using one of the two = following possibilities (i'd bet the former, but both mechanisms = effectively do the same thing): >=20 > a) The NSA identifies those individuals it wants to target (in this = case, technical employees at telco/internet firms in allied countries.) >=20 > b) The NSA's wiretap waits for a Slashdot or LinkedIn page [1] = indicating that the intended victim is logged in by examining page = contents. Once it has identified an intended victim, it now has the = cookies for the victim.=20 >=20 > c) On the next fetch from the victim to the targeted site (ideally = for some inconsequential element, but with some tricks you can do it for = a main-page), "shoot" a packet injection attack to have some = inconsequential element redirect the victim to an exploit server (NSA = calls this FOXACID, we civilians can do the same thing with Metasploit's = HTTP server). >=20 > OR >=20 > b) Look for DNS requests for Slashdot or Linkedin from possible = victims, and packet inject a DNS reply to your proxy server... >=20 >=20 > Packet injection in either case is used instead of a traditional MITM = because its effectively as powerful for anything w/o cryptography, yet = much safer to install and use, since failures don't result in = communication cuts, if you can't keep up you don't disrupt the network, = its easier to install both with and without consent (after all, its = 'just' a wiretap), etc. >=20 >=20 >=20 > The NSA has now created a world where any plaintext traffic isn't just = an information leakage, but a potential vehicle for exploitation! >=20 > And by attacking allies as well as enemies, using a mechanism that is = available (albeit without quite as much targeting precision) to = effectively any adversary with a tap (France, China, Russia, Brazil, = Israel, pretty much anybody can play these games [3]), the network = backbone just became an incredibly hostile place. >=20 >=20 > If you are lucky, your adversary is any country your traffic passes = through you other than your own. If you are lucky. >=20 >=20 >=20 > [1] QUANTUM is the code-word/program for packet injection, and this is = confirmed by Schneier's analysis of Snowden documents. In Schneier's = analysis he specifically linked to public speculation I made months = earlier. >=20 > [2] ANY cleartext site which identifies logged in users will do, as = long as the NSA has a sufficient parser to map page reply to user = identification. >=20 > [3] Please contact your local Gamma International, hackingteam.it, and = Vulpen sales representatives for details. >=20 > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_EB3D9EF9-79BE-4E5F-970F-145676388EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 For = once, I am delighted that the LinkedIn authentication URL embedded in = their emails to me never works...
(the redirect to LinkedIn seems to = work, but then the site goes into a tight loop for some reason I am = really not motivated to figure = out).

Incidentally, if I understood Nick's = analysis correctly, steps (b) and ( c ) are a good example of why I = distrust app-based clients for services like LinkedIn - because it seems = far harder to stop them using replayable long-term tokens than it is to = stop a browser from doing = so.

R
 
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 12 Nov 2013, at 16:37, Nicholas Weaver wrote:


On = Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker <hallam@gmail.com> = wrote:

The biggest weakness in Internet = protocols is relying on passwords for authentication. What can we do to = make the password mechanisms more secure and to wean the Internet off = passwords?

I don't want to = start an NSA rathole here, but I need evidence to support the above = assertion and until the GRU or MOSSAD or PLA or whatever have their = Snowden event, I am limited to using the = NSA.

1) NSA using = Password sniffing in Attack: http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html=

Thats false.  They didn't use password = sniffing in this attack.  And overall reporting on that was pretty = dismal.  

This was targeting information for a QUANTUMINSERT = attack [1], aka packet injection/Man-on-the-Side for exploitation. =  And there was no fake slashdot page, just fake packets.  I = wish they were just password sniffing.


The goal is victim = browser exploitation, using one of the two following possibilities (i'd = bet the former, but both mechanisms effectively do the same = thing):

a)  The NSA identifies those individuals it wants to = target (in this case, technical employees at telco/internet firms in = allied countries.)

b)  The NSA's wiretap waits for a = Slashdot or LinkedIn page [1] indicating that the intended victim is = logged in by examining page contents.  Once it has identified an = intended victim, it now has the cookies for the victim.

c) =  On the next fetch from the victim to the targeted site (ideally = for some inconsequential element, but with some tricks you can do it for = a main-page), "shoot" a packet injection attack to have some = inconsequential element redirect the victim to an exploit server (NSA = calls this FOXACID, we civilians can do the same thing with Metasploit's = HTTP server).

OR

b)  Look for DNS requests for = Slashdot or Linkedin from possible victims, and packet inject a DNS = reply to your proxy server...


Packet injection in either case = is used instead of a traditional MITM because its effectively as = powerful for anything w/o cryptography, yet much safer to install and = use, since failures don't result in communication cuts, if you can't = keep up you don't disrupt the network, its easier to install both with = and without consent (after all, its 'just' a wiretap), = etc.



The NSA has now created a world where any plaintext = traffic isn't just an information leakage, but a potential vehicle for = exploitation!

And by attacking allies as well as enemies, using a = mechanism that is available (albeit without quite as much targeting = precision) to effectively any adversary with a tap (France, China, = Russia, Brazil, Israel, pretty much anybody can play these games [3]), = the network backbone just became an incredibly hostile = place.


If you are lucky, your adversary is any country your = traffic passes through you other than your own.  If you are = lucky.



[1] QUANTUM is the code-word/program for packet = injection, and this is confirmed by Schneier's analysis of Snowden = documents.  In Schneier's analysis he specifically linked to public = speculation I made months earlier.

[2] ANY cleartext site which = identifies logged in users will do, as long as the NSA has a sufficient = parser to map page reply to user identification.

[3] Please = contact your local Gamma International, hackingteam.it, and Vulpen sales = representatives for details.

--
Nicholas Weaver =             &n= bsp;    it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu =             &n= bsp;  full of sound and fury,
510-666-2903 =             &n= bsp;           &nbs= p;       .signifying nothing
PGP: = http:= //www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

________= _______________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_EB3D9EF9-79BE-4E5F-970F-145676388EC6-- --Apple-Mail=_921CC7C1-9AE7-49A0-8773-455795994E93 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTEyMTY1NjAyWjAjBgkqhkiG9w0BCQQxFgQUkDHMmrglmByJzCjIwqet lwipjPIwdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAFV8FzAxyWbIDgYiWf7Yg0JV 6kL7BUr+GH6R/qDhpfSKIDuPIBQc9nB/dTdqMt85fX2D1Nt55+NcCQbta5GHLNy+Aeu/oUAM4ZWj k0iYP5xL+bYUffUbC/yecgBOT18BOMkoA/2SyC9ezc9R3xD3RsuC3240AW7t0LZvH5MZ7+ocz3vu YUBpZkrVvGm6qg08JMbz35PvMNBltSR2oNKkRQd5LGCTx/F3kPNhxTkmk1pYandkFXGgXuiz9HLp BDJWF0sg5Id0qtWNSfKxpKkozh+LDfSLqaRcU1JlK3fP6ZhbTSznEyg33ne1XVu21Zf/PX2xvFHT Gse5fPtfAo4gjmAAAAAAAAA= --Apple-Mail=_921CC7C1-9AE7-49A0-8773-455795994E93-- From nweaver@icsi.berkeley.edu Tue Nov 12 09:04:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3211E810D for ; Tue, 12 Nov 2013 09:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upRw1OMCsbrR for ; Tue, 12 Nov 2013 09:04:31 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3E65F11E810B for ; Tue, 12 Nov 2013 09:04:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 852EA2C4044; Tue, 12 Nov 2013 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JvS49Mnjf0i3; Tue, 12 Nov 2013 09:04:24 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DBEB02C4014; Tue, 12 Nov 2013 09:04:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_74092779-ABAD-4E87-9F9E-9579BD8C595D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <81D58F19-1C6E-465C-889B-26D12CE824C3@isoc.org> Date: Tue, 12 Nov 2013 09:04:24 -0800 Message-Id: References: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> <81D58F19-1C6E-465C-889B-26D12CE824C3@isoc.org> To: Robin Wilton X-Mailer: Apple Mail (2.1510) Cc: Phillip Hallam-Baker , perpass , Nicholas Weaver Subject: Re: [perpass] Stopping packet injection: the network is attacking us (was re Password Sniffing) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:04:36 -0000 --Apple-Mail=_74092779-ABAD-4E87-9F9E-9579BD8C595D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 12, 2013, at 8:56 AM, Robin Wilton wrote: > For once, I am delighted that the LinkedIn authentication URL embedded = in their emails to me never works... > (the redirect to LinkedIn seems to work, but then the site goes into a = tight loop for some reason I am really not motivated to figure out). Doesn't matter. Their goal is to exploit you, not the server. So as = long as you log into A site which examining page content in the clear = can identify you as you, this One Simple Trick (tm) works. There are also tons of other targets if you don't mind being a little = less discriminate. E.g. advertising elements in the clear. > Incidentally, if I understood Nick's analysis correctly, steps (b) and = ( c ) are a good example of why I distrust app-based clients for = services like LinkedIn - because it seems far harder to stop them using = replayable long-term tokens than it is to stop a browser from doing so. A bigger reason to not use app-based clients is the advertisement = libraries, which tend to also run in the clear and introduce their own = horrid suite of vulnerabilities which are also ripe targets for packet = injection, either from the blackbone or on the local WiFi: = http://www.fireeye.com/blog/technical/2013/10/ad-vulna-a-vulnaggressive-vu= lnerable-aggressive-adware-threatening-millions.html Overall, IMO, Android is only secure if you never install any = applications. As soon as you install too many random applications = (especially advertisement-sponsored applications) from the Google Play = store, your phone should be assumed to be vulnerable to network-based = attacks from any adversary who can see your traffic. iOS is much better in this respect, simply because without escalating to = root (a jailbreak exploit), even a corrupted app can't do all that much, = since apple provides a MUCH more limited API and privacy-sensitive items = are prompt on first use. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_74092779-ABAD-4E87-9F9E-9579BD8C595D 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 iQIcBAEBCgAGBQJSgl+YAAoJEG2B1w+SDi/uHCMP/1cXIs1eqtkL6k56a4lI9CGf 04oSXI4WemxeMHxbtRs8olhIoFUN9n19t4bZdzxoY4zapZGH/IjDJOLxJG1InPuY /prWVAIx55VWAcyhnVyczbr8iW8FixRd2UpkX7zfPBETlHcjr+Bsy83x6E+mU8Fe MBR3D+9zXjTFo7rjJMRvlUnsaP6v1QndL6z4kRWoubr7ggEhPUaasO58Rd1Xxw5z tZn9koFcHMBaNlpab8+Zcr3GcJ/YcABsPxlGTtP0/38BG1iSsLiv7nq+2S1F3xvA jU+4inMG3PxBfgNQ9qF7PHGdtqI2kkmPKZvtr8l9k2jIb7k2/tjtZhwS/iMKAII6 XHLrkLfcmPnX23ko39mtP+icz8oQsgmPASoZ/S8hIWqht/pr84feTKMczqoFB6JV 1d/ny3kg+MY8jeMsBkAWQm0u2mYsv7OJHpezGy3dIIB/pHnO4dS4ziU+REwTgpMz BgLyLGKkb1rezvtgp3KMqYheVqHJhzDQLizmHAMUkV+2X98Xnw6uXGGNr4jBb33/ RxPz72khHD5B1tYef5Jr3+I0jecgFor+lHeb2Cz82b5s0RGuXlfrVVg0EamuAhSe Ut0QDklsQ2TFm8kBtrPNMowSBqMYL2pxi6WjK1OyluVgOf2itdGVrvTMNnz1y24k S5+q8ZXJbT6E818SQvVI =m2sm -----END PGP SIGNATURE----- --Apple-Mail=_74092779-ABAD-4E87-9F9E-9579BD8C595D-- From derhoermi@gmx.net Tue Nov 12 09:26:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB8C11E80FE for ; Tue, 12 Nov 2013 09:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2hqx-jn-MIz for ; Tue, 12 Nov 2013 09:26:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71821E8093 for ; Tue, 12 Nov 2013 09:26:25 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.57.49]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MJGFi-1Vhwgf2602-002l7T for ; Tue, 12 Nov 2013 18:26:23 +0100 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Tue, 12 Nov 2013 18:26:24 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Ud4cTGFkknWtEqO+hYmmr1VaK3pQRWH0UbFjcAJNoFPrBvnJVsG Wc6m7W7QA1rMsb7j2tOp5sc7RPtFzyJ2bCfHFDPHs/VLN/1BS9HdVbODkwaO2RwJTple3MV uzjxDMCyWAxzTt2woqcpqVtvuery+rRlz4eDKHJ51G/q4X2s/8om38KsBX5qSRCbL3DTiAI nLZsx9Mry86PnI9RP1S7Q== Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:26:31 -0000 * Phillip Hallam-Baker wrote: >The biggest weakness in Internet protocols is relying on passwords for >authentication. What can we do to make the password mechanisms more secure >and to wean the Internet off passwords? When I started learning about web development in the late 1990s it came a bit as shock to me that other people can know my passwords. They are supposed to be secret! Later I learned it isn't even necessary for any- one other than me to know my passwords, except for convenience maybe. I also learned implementations of mechanisms like HTTP Authentication are so bad users cannot know whether they are logged in and cannot log out! These days it is normal and expected that devices and operating systems steal your passwords and passwords that have been entrusted to you. Not to mention this web forms + cookie madness. As far as web browsers are concerned, whether you are identifying to a web site, using which identity, including login and logout, is clearly a browser user interface concern, not a web site concern. My passwords are only needed on my devices so they can prove that I have them. These days I can easily synchronise them myself by holding my smartphone in front of a webcam if copying files over a wireless network is too hard. I can also easily back them up by printing a protected version of them. Beautifully, I can also use other people's devices to use services that I identify to without risking that my passwords are compromised. As far as theory is concerned anyway. That is what I would be interested in. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Tue Nov 12 09:27:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB421E8091 for ; Tue, 12 Nov 2013 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-8Q13vBvzZK for ; Tue, 12 Nov 2013 09:27:21 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE621E8122 for ; Tue, 12 Nov 2013 09:27:18 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id oz11so3416143veb.17 for ; Tue, 12 Nov 2013 09:27:15 -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=Isrkb51Rpr/vezbNW1llvZFIuRoJpZHaX/N0J9fDljA=; b=IH9maYTaCv0hL+X7NoqxjNC0R11M3W9bDI9A6mt2Vj5BHN8AGwH+/CBm2AcVSbjE7o nWwyZhcvrow7BVWZk5dj2CEssVAU8wlDOxSVyipCb6gbtSHJWwLLI/y627E3SmS4qS0x nNzCWjINvllrtLQujUQyESi8ZW8cw9BPiXKctbOfaXlP64GPNy8Ook9WIIv+WHaRq5VA p7+8Zu1AuXHeelqiD/mhOFfC9lbx+yiu8iMmmL1SjifSDi1fz+NxgQTuBxb3qt7J+dE/ ULhdE2RF/kuQRTasi/Wa2adsg/arXir9OXyE7ZSv4Rx4Te8ZWTiMr/bFReBTSLiKjEFU jPxA== X-Gm-Message-State: ALoCoQnhKcKlP/WGN+xX20pL8zWvJNAdBsB1ogPwlRkYSsPCDcfrtZ2EVPQi2tJE/549WNC7EUC8 MIME-Version: 1.0 X-Received: by 10.220.86.69 with SMTP id r5mr29984732vcl.9.1384277235119; Tue, 12 Nov 2013 09:27:15 -0800 (PST) Received: by 10.220.110.134 with HTTP; Tue, 12 Nov 2013 09:27:15 -0800 (PST) X-Originating-IP: [199.241.202.49] Received: by 10.220.110.134 with HTTP; Tue, 12 Nov 2013 09:27:15 -0800 (PST) In-Reply-To: References: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> <81D58F19-1C6E-465C-889B-26D12CE824C3@isoc.org> Date: Tue, 12 Nov 2013 09:27:15 -0800 Message-ID: From: Tim Bray To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001a11c1ff44ded7ce04eafe2867 Cc: Robin Wilton , perpass , Phillip Hallam-Baker Subject: Re: [perpass] Stopping packet injection: the network is attacking us (was re Password Sniffing) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:27:27 -0000 --001a11c1ff44ded7ce04eafe2867 Content-Type: text/plain; charset=UTF-8 On Nov 12, 2013 9:04 AM, "Nicholas Weaver" wrote: > > > Overall, IMO, Android is only secure if you never install any applications. As soon as you install too many random applications (especially advertisement-sponsored applications) from the Google Play store, your phone should be assumed to be vulnerable to network-based attacks from any adversary who can see your traffic. I disagree. A rooted/jailbroken device is obviously a bomb waiting to go off, but the Android and iOS security models are both pretty good otherwise. The discussion of when to prompt is tricky. Arguably, prompt on first use penalizes good apps, because the bad guys ask for everything at install time... people rarely actually look at those prompts. There are points on the other side too, but it's not a slam dunk. > > iOS is much better in this respect, simply because without escalating to root (a jailbreak exploit), even a corrupted app can't do all that much, since apple provides a MUCH more limited API and privacy-sensitive items are prompt on first use. > > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --001a11c1ff44ded7ce04eafe2867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 12, 2013 9:04 AM, "Nicholas Weaver" <nweaver@icsi.berkeley.edu> wrote:
>
>

> Overall, IMO, Android is only secure if you never insta= ll any applications. =C2=A0As soon as you install too many random applicati= ons (especially advertisement-sponsored applications) from the Google Play = store, your phone should be assumed to be vulnerable to network-based attac= ks from any adversary who can see your traffic.

I disagree. A rooted/jailbroken device is obviously a bomb w= aiting to go off, but the Android and iOS security models are both pretty g= ood otherwise.

The discussion of when to prompt is tricky. Arguably, prompt= on first use penalizes good apps, because the bad guys ask for everything = at install time... people rarely actually look at those prompts. There are = points on the other side too, but it's not a slam dunk.

>
> iOS is much better in this respect, simply because without escalating = to root (a jailbreak exploit), even a corrupted app can't do all that m= uch, since apple provides a MUCH more limited API and privacy-sensitive ite= ms are prompt on first use.
>
> --
> Nicholas Weaver =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0it is a tale, told by an idiot,
> nweaver@icsi.berkeley.edu= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0full of sound a= nd fury,
> 510-666-2903=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.signifying n= othing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.= ietf.org/mailman/listinfo/perpass
>

--001a11c1ff44ded7ce04eafe2867-- From wilton@isoc.org Tue Nov 12 09:45:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736B021E8136 for ; Tue, 12 Nov 2013 09:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyGaCd7XoOpd for ; Tue, 12 Nov 2013 09:45:16 -0800 (PST) Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) by ietfa.amsl.com (Postfix) with ESMTP id EB2DC21F9CF3 for ; Tue, 12 Nov 2013 09:42:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8C6C660127; Tue, 12 Nov 2013 12:42:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id EF8DD60074; Tue, 12 Nov 2013 12:42:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_CCC90206-B21C-4B68-A6D0-D56445AE82B9"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Tue, 12 Nov 2013 17:42:02 +0000 Message-Id: <7D41A6A6-6751-49E9-95F5-766FF7902D43@isoc.org> References: To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1283) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:45:36 -0000 --Apple-Mail=_CCC90206-B21C-4B68-A6D0-D56445AE82B9 Content-Type: multipart/alternative; boundary="Apple-Mail=_CB77F597-4F06-4C96-BA32-901A5A52D792" --Apple-Mail=_CB77F597-4F06-4C96-BA32-901A5A52D792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 - Stating Bj=F6rn's position slightly differently: we need to = acknowledge explicitly, as a design point, that many passwords are used = by "password-aware proxies", not by the end-user. R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 12 Nov 2013, at 17:26, Bjoern Hoehrmann wrote: > * Phillip Hallam-Baker wrote: >> The biggest weakness in Internet protocols is relying on passwords = for >> authentication. What can we do to make the password mechanisms more = secure >> and to wean the Internet off passwords? >=20 > When I started learning about web development in the late 1990s it = came > a bit as shock to me that other people can know my passwords. They are > supposed to be secret! Later I learned it isn't even necessary for = any- > one other than me to know my passwords, except for convenience maybe. = I > also learned implementations of mechanisms like HTTP Authentication = are > so bad users cannot know whether they are logged in and cannot log = out! > These days it is normal and expected that devices and operating = systems > steal your passwords and passwords that have been entrusted to you. = Not > to mention this web forms + cookie madness. >=20 > As far as web browsers are concerned, whether you are identifying to a > web site, using which identity, including login and logout, is clearly > a browser user interface concern, not a web site concern. My passwords > are only needed on my devices so they can prove that I have them. = These > days I can easily synchronise them myself by holding my smartphone in > front of a webcam if copying files over a wireless network is too = hard. > I can also easily back them up by printing a protected version of = them. > Beautifully, I can also use other people's devices to use services = that > I identify to without risking that my passwords are compromised. As = far > as theory is concerned anyway. That is what I would be interested in. > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_CB77F597-4F06-4C96-BA32-901A5A52D792 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +1 =  -  Stating Bj=F6rn's position slightly differently: we need = to acknowledge explicitly, as a design point, that many passwords are = used by "password-aware proxies", not by the = end-user.


R

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 12 Nov 2013, at 17:26, Bjoern Hoehrmann wrote:

* = Phillip Hallam-Baker wrote:
The biggest = weakness in Internet protocols is relying on passwords = for
authentication. What can = we do to make the password mechanisms more = secure
and to wean the = Internet off passwords?

When I started learning = about web development in the late 1990s it came
a bit as shock to me = that other people can know my passwords. They are
supposed to be = secret! Later I learned it isn't even necessary for any-
one other = than me to know my passwords, except for convenience maybe. I
also = learned implementations of mechanisms like HTTP Authentication are
so = bad users cannot know whether they are logged in and cannot log = out!
These days it is normal and expected that devices and operating = systems
steal your passwords and passwords that have been entrusted = to you. Not
to mention this web forms + cookie madness.

As far = as web browsers are concerned, whether you are identifying to a
web = site, using which identity, including login and logout, is clearly
a = browser user interface concern, not a web site concern. My = passwords
are only needed on my devices so they can prove that I have = them. These
days I can easily synchronise them myself by holding my = smartphone in
front of a webcam if copying files over a wireless = network is too hard.
I can also easily back them up by printing a = protected version of them.
Beautifully, I can also use other people's = devices to use services that
I identify to without risking that my = passwords are compromised. As far
as theory is concerned anyway. That = is what I would be interested in.
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de
Am = Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
2589= 9 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/ =
_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_CB77F597-4F06-4C96-BA32-901A5A52D792-- --Apple-Mail=_CCC90206-B21C-4B68-A6D0-D56445AE82B9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTEyMTc0MjAzWjAjBgkqhkiG9w0BCQQxFgQUH8Pp03xjPr8x/Tn2wjMP suT0AW0wdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAGeDe4LxEQJHdLxEMR9uNIFv vrYrsvlHOd24AewAlJdi4fw/7yNRM6jX+YXuh1cCnjUkeF72qr1QxWo26BTUmf4XQBXwgRGSmR1e 1Mkaipp6FWVfI99qJBJCREjDz8zxoLpqdsFyhfORgAxTJgjAMnjSOnc1C+X/2Tw3GnSN2YwfV+3Z 1uEbMohBBdKYB5jCj4tFB20lPAXhCKEoXIqPMNAyMpG7chIaJzYVd0c3hJWpHBcx6Z7zkb9eNFaP Jil6ZV0GdCyFz5XReuV/5xe4s0wAM2yCNfWEw1zj8ZHWk/sBCn5dr9JSYl8BxYL/gxTFJKB7H6Xn C6BwyqrVMmx8MaYAAAAAAAA= --Apple-Mail=_CCC90206-B21C-4B68-A6D0-D56445AE82B9-- From joe@oregon.uoregon.edu Tue Nov 12 10:04:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784D11E8104 for ; Tue, 12 Nov 2013 10:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD9SNTy44Gev for ; Tue, 12 Nov 2013 10:04:31 -0800 (PST) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id CD92611E815C for ; Tue, 12 Nov 2013 10:04:31 -0800 (PST) Date: Tue, 12 Nov 2013 09:32:34 -0800 (PST) Message-Id: <13111209323487_BDAC@oregon.uoregon.edu> From: "Joe St Sauver" To: watsonbladd@gmail.com X-VMS-To: SMTP%"watsonbladd@gmail.com" X-VMS-Cc: SMTP%"hallam@gmail.com",SMTP%"perpass@ietf.org" Cc: perpass@ietf.org, hallam@gmail.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:04:36 -0000 Hi, Watson commented: #Passwords are fine provided they are not reused, and transmitted over #secure channels. Has that really been everyone's experience? From my POV, passwords really seem to be inherently badly broken: -- if the user's system is botted, single channel authentication systems (including passwords) are toast out of the box; you really need a second channel, such as auth confirmation via a user's smart phone -- unless we get broad adoption of federated authentication, we'll always have *too many* usernames and passwords (and solutions like Shibboleth tend to treat mobile apps and non-web scenarios as an after thought) -- if you care about formal NIST SP800-63-1 style assurance, implementing throttling as required at section 8.2.3 can be tricky: "the Verifier shall effectively limit online Attackers to 100 failed attempts on a single account in any 30 day period." [I should probably clarify that this is "tricky" *IF* you care about avoiding denial of service attack scenarios] -- and the list goes on... #Client certificates are already supported and widely deployed. The DOD #uses them on smartcards for just about everything. The big problem is #a UI issue. I think the problems with client certs goes far beyond just issues with the user interface. While the CAC/PIV cards you mention are a nice existence proof that client cert PKI is "possible," I invite you to review https://militarycac.com/ for a practical indication of where CAC/PIV implementation is at. There are an awful lot of arcane workarounds and exception cases, and trying to use CAC/PIV cards on alternative operating systems is particularly tricky. On a scale of 1 to 100, where 100 is "perfect, painless, just works" and 1 is "totally broken, unusable," there are many scenarios where CAC/PIV cards are closer to the bottom of the thermometer than the top. If you truly believe that client certs are the answer, I invite those with that belief to begin using client certs with S/MIME to routinely sign all their email. I've got a document that walks you through the process of using client certs that I put together for the Educause/Internet2 Security Professionals Preconference Seminars, and it walks you through the process. If you want to try it, see http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf I'd also note that if you really care about the security of your client certificate credentials, and you want a public/private keypair that was created on a PKI hard token or smart card in non-exportable form, that's great, but it poses some issues if you want to use those credentials on mobile devices (such as smart phones or tablets). Yes, there are things like "CAC sleds" for some mobile devices, but they aren't cheap, which means that this is NOT a ready-for-mass-market solution as it currently stands. Regards, Joe From hallam@gmail.com Tue Nov 12 10:34:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECDC11E810B for ; Tue, 12 Nov 2013 10:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hAwyTMdwluF for ; Tue, 12 Nov 2013 10:34:54 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 98DE311E811B for ; Tue, 12 Nov 2013 10:34:53 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id eo20so5487085lab.37 for ; Tue, 12 Nov 2013 10:34:52 -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=+QUxcNuo0BXXdIIf45jqWLtfIu1PtadFMlKZHutD9Kk=; b=H/9ETRcFJqadmVfxQBaOL3C7rXukJjpVuRbEPBgaEUbeLMCOi+OBDNvV9fQhHYyvJk A9fwe/8tzSC1HNfCFTuyh3+2fCIlHdz/gZRrB+o4S84EtMRIbMirZzE0HNw6W9U3FBxT 4WjJFTyMkWUbKi/x3V+Ced09kXIthx/HuucH1uLtzaAuuezfpAlqMITVtRBIGboXpEhw o0Q2E6oLqFY9xsZF7lj5zcuRf77FAWui341PhwhdJib5BalqA3X8XJFZMTRc6BHr+TeJ dmT8g7mgPwOnT82wkNMPpJYAaOWnjrkB8dYmzHGhWSV1CA4CSD+XxWXYcXA6Y9R0+y9z tWXg== MIME-Version: 1.0 X-Received: by 10.112.143.138 with SMTP id se10mr10775499lbb.26.1384281292438; Tue, 12 Nov 2013 10:34:52 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 12 Nov 2013 10:34:52 -0800 (PST) In-Reply-To: <13111209323487_BDAC@oregon.uoregon.edu> References: <13111209323487_BDAC@oregon.uoregon.edu> Date: Tue, 12 Nov 2013 10:34:52 -0800 Message-ID: From: Phillip Hallam-Baker To: Joe St Sauver Content-Type: multipart/alternative; boundary=089e01182830b481b004eaff1ace Cc: watsonbladd@gmail.com, perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:34:55 -0000 --089e01182830b481b004eaff1ace Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 12, 2013 at 9:32 AM, Joe St Sauver wrote: > Hi, > > Watson commented: > > #Passwords are fine provided they are not reused, and transmitted over > #secure channels. > > Has that really been everyone's experience? From my POV, passwords > really seem to be inherently badly broken: > What is written is strictly accurate but misses the point that real users cannot and will not remember a different password for every site. I share the same password across all my low security sites and have no intention to change that. It is not worth my time to remember a different password to log into the Washington Post or the NYT or whatever. I am not going to use my brain cells to protect someone else's asset. Nope, not unless they are paying me to do so. All my Facebook accounts use the same password which is the same as my Twitter accounts and all the other social media accounts. Remembering my usernames is hard enough. When I am forced to change my password it takes me several months to get back to steady state which is only achieved when all the sites have the same password again. > -- if the user's system is botted, single channel authentication systems > (including passwords) are toast out of the box; you really need a > second channel, such as auth confirmation via a user's smart phone > > -- unless we get broad adoption of federated authentication, we'll always > have *too many* usernames and passwords (and solutions like Shibboleth > tend to treat mobile apps and non-web scenarios as an after thought) > > -- if you care about formal NIST SP800-63-1 style assurance, implementing > throttling as required at section 8.2.3 can be tricky: "the Verifier > shall effectively limit online Attackers to 100 failed attempts on a > single account in any 30 day period." [I should probably clarify that > this is "tricky" *IF* you care about avoiding denial of service > attack scenarios] > I frequently rack up a dozen tries because I can't remember the username/password combination. > -- and the list goes on... > > #Client certificates are already supported and widely deployed. The DOD > #uses them on smartcards for just about everything. The big problem is > #a UI issue. > > I think the problems with client certs goes far beyond just issues with > the user interface. > The main problem is that they expire. And the second problem is that none of the infrastructure expects one user to have multiple certs. So the cert has to be shared across devices which negates the security advantage. > While the CAC/PIV cards you mention are a nice existence proof that client > cert PKI is "possible," I invite you to review https://militarycac.com/for > a practical indication of where CAC/PIV implementation is at. There are an > awful lot of arcane workarounds and exception cases, and trying to use > CAC/PIV cards on alternative operating systems is particularly tricky. > The user experience is designed for checklist compliance. It isn't very good. People can be paid to use it but it really only works in closed enterprise environments right now. -- Website: http://hallambaker.com/ --089e01182830b481b004eaff1ace Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 12, 2013 at 9:32 AM, Joe St Sauver &l= t;joe@oregon.uo= regon.edu> wrote:
Hi,

Watson commented:

#Passwords are fine provided they are not reused, and transmitted over
#secure channels.

Has that really been everyone's experience? From my POV, passwords
really seem to be inherently badly broken:

<= div>What is written is strictly accurate but misses the point that real use= rs cannot and will not remember a different password for every site.=A0

I share the same password across all my low security si= tes and have no intention to change that. It is not worth my time to rememb= er a different password to log into the Washington Post or the NYT or whate= ver.=A0

I am not going to use my brain cells to protect someone= else's asset. Nope, not unless they are paying me to do so. All my Fac= ebook accounts use the same password which is the same as my Twitter accoun= ts and all the other social media accounts. Remembering my usernames is har= d enough.

When I am forced to change my password it takes me seve= ral months to get back to steady state which is only achieved when all the = sites have the same password again.


=A0
-- if the user's system is botted, single channel authentication system= s
=A0 =A0(including passwords) are toast out of the box; you really need a =A0 =A0second channel, such as auth confirmation via a user's smart pho= ne

-- unless we get broad adoption of federated authentication, we'll alwa= ys
=A0 =A0have *too many* usernames and passwords (and solutions like Shibbole= th
=A0 =A0tend to treat mobile apps and non-web scenarios as an after thought)=

-- if you care about formal NIST SP800-63-1 style assurance, implementing =A0 =A0throttling as required at section 8.2.3 can be tricky: "the Ver= ifier
=A0 =A0shall effectively limit online Attackers to 100 failed attempts on a=
=A0 =A0single account in any 30 day period." [I should probably clarif= y that
=A0 =A0this is "tricky" *IF* you care about avoiding denial of se= rvice
=A0 =A0attack scenarios]

I frequently r= ack up a dozen tries because I can't remember the username/password com= bination.

=A0
-- and the list goes on...

#Client certificates are already supported and widely deployed. The DOD
#uses them on smartcards for just about everything. The big problem is
#a UI issue.

I think the problems with client certs goes far beyond just issues with
the user interface.

The main problem is= that they expire. And the second problem is that none of the infrastructur= e expects one user to have multiple certs. So the cert has to be shared acr= oss devices which negates the security advantage.

=A0
While the CAC/PIV cards you mention are a nice existence proof that client<= br> cert PKI is "possible," I invite you to review https://militarycac.com/ for
a practical indication of where CAC/PIV implementation is at. There are an<= br> awful lot of arcane workarounds and exception cases, and trying to use
CAC/PIV cards on alternative operating systems is particularly tricky.
<= /blockquote>

The user experience is designed for checkli= st compliance. It isn't very good. People can be paid to use it but it = really only works in closed enterprise environments right now.



--
Website: http://hallambaker.com/
--089e01182830b481b004eaff1ace-- From hallam@gmail.com Tue Nov 12 10:41:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116111E810B for ; Tue, 12 Nov 2013 10:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49mk6pgFycEG for ; Tue, 12 Nov 2013 10:41:55 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B70A21F9FAB for ; Tue, 12 Nov 2013 10:41:54 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id z5so1394947lbh.15 for ; Tue, 12 Nov 2013 10:41:53 -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=oGW8fdbXM87KbYvDdNqqUqJsXoBlVRe2V4S3GZ88QWE=; b=gcIqqZbiUmETAupoO3ZogR9mM1dXq4+h1BB94D93HjKjMSQ/ylczqYiQnxxwR9J5YM VN0zUZCUJZndMNBdfC/pggahNmdNybEQ/I5KGyYGN4sy6ib8vRCnKFYU/FL8QAbu2BRJ zQpH+6KXkHJe/48Ddzs6zyRMHDoGM9BE5L6JEIZnrIsHHsHUuWvL4H52tWS4GO36ur9w RQZxlfysoekTdO9ZH0dSqO/ckUCcnPRG0TLmuV3Kg4IgOKiHA/0uR4FK/ZLZMu3gTQZk z7SAoZF8ZdTbgb4unnF+7oC0zbrocRKPCWH0nmboT1ch1KrGgrphbGI9cWMYPqeAG5Rc 3/rw== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr28361459lab.11.1384281713391; Tue, 12 Nov 2013 10:41:53 -0800 (PST) Received: by 10.112.46.98 with HTTP; Tue, 12 Nov 2013 10:41:53 -0800 (PST) In-Reply-To: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> References: <33CCA400-9D1A-4A1E-A50D-84E4EE1960EB@icsi.berkeley.edu> Date: Tue, 12 Nov 2013 10:41:53 -0800 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001a11c2672acbbe8d04eaff331d Cc: perpass Subject: Re: [perpass] Stopping packet injection: the network is attacking us (was re Password Sniffing) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:41:55 -0000 --001a11c2672acbbe8d04eaff331d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 12, 2013 at 8:37 AM, Nicholas Weaver wrote: > > On Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker > wrote: > > > The biggest weakness in Internet protocols is relying on passwords for > authentication. What can we do to make the password mechanisms more secure > and to wean the Internet off passwords? > > > > I don't want to start an NSA rathole here, but I need evidence to > support the above assertion and until the GRU or MOSSAD or PLA or whatever > have their Snowden event, I am limited to using the NSA. > > > > 1) NSA using Password sniffing in Attack: > http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html > > Thats false. They didn't use password sniffing in this attack. And > overall reporting on that was pretty dismal. > > This was targeting information for a QUANTUMINSERT attack [1], aka packet > injection/Man-on-the-Side for exploitation. And there was no fake slashdot > page, just fake packets. I wish they were just password sniffing. > The cookie stealing attack is easier to prevent: https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/ Basically the protocol is as follows: 1) Client tells server 'I accept strong cookies' 2) Server sends an algorithm and shared secret in the HTTP channel 3) Client presents the usual cookie plus a MAC value calculated over some of the request and the shared secret exchanged earlier. 4) Server authenticates response in the same way. The mechanism can be optionally bound to the TLS channel and the request content. The initial exchange is preferably protected by TLS but this is not essential. The main objective is to avoid repeated transfer of a bearer credential. If plaintext exchange is going to be frequent, a DH exchange should be available as an option. -- Website: http://hallambaker.com/ --001a11c2672acbbe8d04eaff331d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 12, 2013 at 8:37 AM, Nicholas Weaver = <nweaver@= icsi.berkeley.edu> wrote:

On Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> The biggest weakness in Internet protocols is relying on passwords for= authentication. What can we do to make the password mechanisms more secure= and to wean the Internet off passwords?
>
> I don't want to start an NSA rathole here, but I need evidence to = support the above assertion and until the GRU or MOSSAD or PLA or whatever = have their Snowden event, I am limited to using the NSA.
>
> 1) NSA using Password sniffing in Attack: http:= //boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html

Thats false. =A0They didn't use password sniffing in this attack. =A0An= d overall reporting on that was pretty dismal.
=A0
This was targeting information for a QUANTUMINSERT attack [1], aka packet i= njection/Man-on-the-Side for exploitation. =A0And there was no fake slashdo= t page, just fake packets. =A0I wish they were just password sniffing.

The cookie stealing attack is easier to pr= event:


Basically the protocol is as follows:
<= br>
1) Client tells server 'I accept strong cookies'

2) Server sends an algorithm and shared secret in the = HTTP channel

3) Client presents the usual cookie plus a MAC value ca= lculated over some of the request and the shared secret exchanged earlier.<= /div>

4) Server authenticates response in the same way.<= /div>


The mechanism can be optionally bound to= the TLS channel and the request content.=A0

The i= nitial exchange is preferably protected by TLS but this is not essential. T= he main objective is to avoid repeated transfer of a bearer credential.=A0<= /div>

If plaintext exchange is going to be frequent, a DH exc= hange should be available as an option.

--
We= bsite: http://hallambaker.com/
--001a11c2672acbbe8d04eaff331d-- From kent@bbn.com Tue Nov 12 10:45:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75011E8169 for ; Tue, 12 Nov 2013 10:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE4RdjVSRpZo for ; Tue, 12 Nov 2013 10:45:04 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4CB11E817A for ; Tue, 12 Nov 2013 10:45:04 -0800 (PST) Received: from dhcp-192-1-255-172.col.bbn.com ([192.1.255.172]:50009) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VgIxT-0007Te-JT; Tue, 12 Nov 2013 13:45:03 -0500 Message-ID: <5282772F.1040209@bbn.com> Date: Tue, 12 Nov 2013 13:45:03 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ben Laurie References: <7300A364-26EC-4966-86E1-B8463AB0D0C1@iii.ca> <527A7720.7050008@bbn.com> <527A82D5.3030502@bbn.com> <527A8C74.6020100@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:45:10 -0000 Ben, > On 6 November 2013 18:37, Stephen Kent wrote: >> Ben, >> >>>> because the constrained chains begin somewhere below the TA, which leaves >>>> EVERY >>>> TA free to create ANY subordinate CA. Also, ccTLDs represent the sort of >>>> sovereign alignment to a PKI that many folks find attractive. >>> For exactly the reason many find it unattractive :-) >> I am not a fan of viewing the Internet as an extra-national entity. >> Maybe that makes me a heretic WRT Google's idea of cyberspace and reality >> ;-) . >> >> Countries have a right to manage a lot of things within their borders, >> and managing their DNS name spaces seems quite reasonable. > Sure. But we were talking about key management. > My text talks about ccTLDs, irrespective of what types of records are stored in the DNS. Steve From martin.thomson@gmail.com Tue Nov 12 17:16:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0A21E8131 for ; Tue, 12 Nov 2013 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSo+LdXU9Lp6 for ; Tue, 12 Nov 2013 17:16:14 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3A21E809C for ; Tue, 12 Nov 2013 17:16:14 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm11so4538197wib.14 for ; Tue, 12 Nov 2013 17:16: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=qdVByRMXJyRI/Nh5nNW27B3pby9veY+PNnhRwu1XCx4=; b=wuDLkkkxELaRQQZW0ugYUIPFRfEZbYLfEXtPJtPA9W1+2ciabNBcBYU0lVtiqYWIxR ZE6/eMiZ9ZxoPq34vLEWIBu/mhB2M23md8SlSF/bUIHi2vKvMVkAlL3Ot5cmWYTT+p4b QwZaRHfgLqXP4Arao/+XVc+ZxwT8xnB3Kj2v4FupJmQZ04kNAGU34w4ih7j3csgIlCRD EfYQJOGQJg9lVOEup3MT8ziKQiUlDSNNJ5i0m66a8ei5Eq8McZCEQ1AEArLncOnIi19i 7Du0gQAeALU5xm39lGmsWGLgtW5A30Y+uO0tLRrAVNBvMWW333an4B4ibo8adws/zfdu ZwQw== MIME-Version: 1.0 X-Received: by 10.194.5.7 with SMTP id o7mr29232304wjo.17.1384305373507; Tue, 12 Nov 2013 17:16:13 -0800 (PST) Received: by 10.227.101.73 with HTTP; Tue, 12 Nov 2013 17:16:13 -0800 (PST) In-Reply-To: References: <20131111121027.GA31723@sources.org> Date: Tue, 12 Nov 2013 17:16:13 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "Wiley, Glen" , perpass , Stephane Bortzmeyer , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:16:15 -0000 On 12 November 2013 08:12, Ted Hardie wrote: > The DNS query tells you which resource was the target even if the HTTP flow > was protected by TLS. In practice, since server name indication is sent in the clear, even this doesn't help. Unless you are running a browser from 2001, you are sending SNI. That said, SNI may be pushed into an encrypted payload in TLS 1.3. The challenge there is that servers often use SNI to select what credentials to offer. From stephen.farrell@cs.tcd.ie Tue Nov 12 17:32:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AAA11E816D for ; Tue, 12 Nov 2013 17:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSdL1l5O+sTt for ; Tue, 12 Nov 2013 17:32:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4421E809C for ; Tue, 12 Nov 2013 17:32:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90C83BE73; Wed, 13 Nov 2013 01:32:20 +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 IDGn-uChz6pm; Wed, 13 Nov 2013 01:32:19 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6DCBABE6E; Wed, 13 Nov 2013 01:32:19 +0000 (GMT) Message-ID: <5282D6A3.5060205@cs.tcd.ie> Date: Wed, 13 Nov 2013 01:32:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson , Ted Hardie References: <20131111121027.GA31723@sources.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Wiley, Glen" , perpass , Stephane Bortzmeyer , Andy Wilson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:32:33 -0000 On 11/13/2013 01:16 AM, Martin Thomson wrote: > On 12 November 2013 08:12, Ted Hardie wrote: >> The DNS query tells you which resource was the target even if the HTTP flow >> was protected by TLS. > > In practice, since server name indication is sent in the clear, even > this doesn't help. Unless you are running a browser from 2001, you > are sending SNI. > > That said, SNI may be pushed into an encrypted payload in TLS 1.3. > The challenge there is that servers often use SNI to select what > credentials to offer. Actually, I think that's maybe interestingly illustrative of some of the non-crypto issues we face. The converse argument was just made on the TLS list yesterday to the effect that there's no point in TLS 1.3 (or a TLS 1.2 extension) encrypting SNI because its the same as the obviously cleartext DNS query in many cases. (Not in all cases being due to VPNs, but that's not the point.) I think there are at least two credible choices for how one regards attempts to counter traffic analysis: 1) give up, its too hard, and going to get worse no matter what we try do, or 2) try chip away at the problem as and when we can in the hope we eventually do make it better. There are probably more as well, but I'm for (2) even though I can understand those who think (1) is much more practical. Or maybe I just hate giving up;-) S. From mellon@fugue.com Tue Nov 12 18:49:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5F11E816D for ; Tue, 12 Nov 2013 18:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZYVRxFZVkmX for ; Tue, 12 Nov 2013 18:49:03 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDAC21F9E88 for ; Tue, 12 Nov 2013 18:49:03 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 52D0D2380840; Tue, 12 Nov 2013 21:48:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <5282D6A3.5060205@cs.tcd.ie> Date: Tue, 12 Nov 2013 21:48:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1822) Cc: Ted Hardie , perpass , Stephane Bortzmeyer , Andy Wilson , "Wiley, Glen" , Martin Thomson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 02:49:09 -0000 On Nov 12, 2013, at 8:32 PM, Stephen Farrell = wrote: > The converse argument was just made on the TLS list yesterday to > the effect that there's no point in TLS 1.3 (or a TLS 1.2 extension) > encrypting SNI because its the same as the obviously cleartext DNS > query in many cases. That's a terrible argument. Then every eavesdropping issue becomes a = chicken-and-egg problem, because nobody is willing to go first. From stephen.farrell@cs.tcd.ie Tue Nov 12 19:04:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC0311E8151 for ; Tue, 12 Nov 2013 19:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syc09mHB+Olr for ; Tue, 12 Nov 2013 19:03:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDB21F9EE0 for ; Tue, 12 Nov 2013 19:03:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6D417BE6F; Wed, 13 Nov 2013 03:03:52 +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 w0Ij0nTymxcr; Wed, 13 Nov 2013 03:03:51 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F16DBE6E; Wed, 13 Nov 2013 03:03:51 +0000 (GMT) Message-ID: <5282EC17.5060808@cs.tcd.ie> Date: Wed, 13 Nov 2013 03:03:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ted Lemon References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> In-Reply-To: <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ted Hardie , perpass , Stephane Bortzmeyer , Andy Wilson , "Wiley, Glen" , Martin Thomson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 03:04:03 -0000 Hey Ted, On 11/13/2013 02:48 AM, Ted Lemon wrote: > On Nov 12, 2013, at 8:32 PM, Stephen Farrell > wrote: >> The converse argument was just made on the TLS list yesterday to >> the effect that there's no point in TLS 1.3 (or a TLS 1.2 >> extension) encrypting SNI because its the same as the obviously >> cleartext DNS query in many cases. > > That's a terrible argument. Then every eavesdropping issue becomes > a chicken-and-egg problem, because nobody is willing to go first. Well, I wouldn't say terrible, but it is unfortunate, yes. In this case, there's a (presumed but realistic) tension between the relative timing of DNS and TLS updates, the absence of each of which makes the occurrence of the other less likely. And that combination makes it less likely that we (the IETF) are motivated to try "fix" either. And all that is replicated up and down the stack - "why should I make application layer privacy better when its so bad at the RF layer with fingerprinting" is an argument that I have seen made in IETF discussion. But again, I'm for trying to do it all better, to the extent we can and I'm not for giving up. S. > > > From ynir@checkpoint.com Tue Nov 12 21:23:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A121F9DB8 for ; Tue, 12 Nov 2013 21:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9APkFxz8PZWl for ; Tue, 12 Nov 2013 21:23:18 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5F27011E80F6 for ; Tue, 12 Nov 2013 21:23:07 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rAD5MTcU031349; Wed, 13 Nov 2013 07:22:34 +0200 X-CheckPoint: {52830ABE-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 07:22:29 +0200 From: Yoav Nir To: Ted Lemon Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHOuQI+/Pr09a4hmk+C3JQD1HfKoZnUjtMAgAGerYCAAAW+AIAAAWuAgEnlz4CAAHoWgIABW8uAgACX/oCAAAR/gIAAFWqAgAAq5AA= Date: Wed, 13 Nov 2013 05:22:29 +0000 Message-ID: <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> In-Reply-To: <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.64] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <2234D8D98E88F940B87C903B65188616@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:23:22 -0000 On Nov 13, 2013, at 4:48 AM, Ted Lemon wrote: > On Nov 12, 2013, at 8:32 PM, Stephen Farrell = wrote: >> The converse argument was just made on the TLS list yesterday to >> the effect that there's no point in TLS 1.3 (or a TLS 1.2 extension) >> encrypting SNI because its the same as the obviously cleartext DNS >> query in many cases. >=20 > That's a terrible argument. Then every eavesdropping issue becomes a ch= icken-and-egg problem, because nobody is willing to go first. I'm one of those that made that argument. I do think we should fix this in = TLS, but realistically, browsers are going to continue sending SNI in the c= lear for at least another 10 years. Yes, we should fix this now, because wh= enever we start, that's when the 10-year countdown begins. The same is true= for any modification to DNS, except the timeframe is likely to be even lon= ger. Yoav [1] http://www.ietf.org/mail-archive/web/tls/current/msg10555.html= From huitema@huitema.net Tue Nov 12 23:32:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3124B11E8117 for ; Tue, 12 Nov 2013 23:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZFTbuDEie-n for ; Tue, 12 Nov 2013 23:32:10 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4A11E8118 for ; Tue, 12 Nov 2013 23:32:01 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VgUt1-00057M-Tn for perpass@ietf.org; Wed, 13 Nov 2013 02:31:58 -0500 Received: (qmail 2911 invoked from network); 13 Nov 2013 07:29:14 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Nov 2013 07:29:14 -0000 From: "Christian Huitema" To: "'Yoav Nir'" , "'Ted Lemon'" References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> In-Reply-To: <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> Date: Tue, 12 Nov 2013 23:29:12 -0800 Message-ID: <01b501cee042$0dd836a0$2988a3e0$@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: AQHMMPQ/jT06VJ5UBicR1g/ghkW8WAJTDAK3Ah78sc0CYGISVALD7f2NAXR3BWsCDCTjUpm/ZUhQ Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:32:40 -0000 > I'm one of those that made that argument. I do think we should fix this in TLS, but realistically, browsers are going to continue sending SNI in the > clear for at least another 10 years. Yes, we should fix this now, because whenever we start, that's when the 10-year countdown begins. The same is > true for any modification to DNS, except the timeframe is likely to be even longer. Even if TLS is not fixed, there is still value in improving DNS privacy. Stephane makes the point in his draft: What also makes the DNS traffic different is that it may take a different path than the communication between the initiator and the recipient. For instance, an eavesdropper may be unable to tap the wire between the initiator and the recipient but may have access to the wire going to the resolver, or to the authoritative name servers. Suppose that a host sends a query for "_bittorrent-tracker._tcp.domain.example.com." If it does not have a cached copy of the NS record for "example.com," the query will go the ".com" server. Because the query carries the entire QNAME, anyone who eavesdrop on the TLD server would learn that the host is attempting to contact a bit torrent server at "domain.example.com." They would learn that even if they are not able to eavesdrop on the direct path between the host and "domain.example.com." Now suppose that instead of sending a query with the full QNAME, the host just sends to the ".com" server a query for the NS record of "example.com." Once it receives the response, the host can send the full query directly to "ns.example.com." Clearly, that too can be eavesdropped, but only if the eavesdropper has a tap on the direct path between the client and the bit torrent server. And if it has such a tap, it will find anyhow that there is TCP-IP traffic between the host and the bittorrent server at "domain.example.com," which means that parsing the DNS query would not provide extra information. So we have here a simple way to prevent leakage of information. It can actually be implemented unilaterally by resolvers, and does not require a change in the DNS protocol. It does require that the resolver somehow learn the "zone cuts," but that is not impossible to learn. -- Christian Huitema From bortzmeyer@nic.fr Wed Nov 13 01:12:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FD421E808D for ; Wed, 13 Nov 2013 01:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=3.984, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IAnZck6FhWf for ; Wed, 13 Nov 2013 01:12:31 -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 444F321F9C00 for ; Wed, 13 Nov 2013 01:12:29 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7204A2801BE; Wed, 13 Nov 2013 10:12:27 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 6C7F628019F; Wed, 13 Nov 2013 10:12:27 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 6AD044C007C; Wed, 13 Nov 2013 10:11:57 +0100 (CET) Date: Wed, 13 Nov 2013 10:11:57 +0100 From: Stephane Bortzmeyer To: Christian Huitema Message-ID: <20131113091157.GA13619@nic.fr> References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> <01b501cee042$0dd836a0$2988a3e0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b501cee042$0dd836a0$2988a3e0$@huitema.net> X-Operating-System: Debian GNU/Linux 7.2 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: 'Ted Lemon' , 'perpass' , 'Yoav Nir' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 09:12:39 -0000 On Tue, Nov 12, 2013 at 11:29:12PM -0800, Christian Huitema wrote a message of 51 lines which said: > It does require that the resolver somehow learn the "zone cuts," but > that is not impossible to learn. Specially since every DNSSEC-validating resolver has to do it, anyway (to know where to find the DS and the DNSKEY). So, in practice, BIND and Unbound has this code for a long time. From bortzmeyer@nic.fr Wed Nov 13 01:34:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397B021F9D0E for ; Wed, 13 Nov 2013 01:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=3.652, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipFkha6sxxT1 for ; Wed, 13 Nov 2013 01:33:56 -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 F1A6021F9D52 for ; Wed, 13 Nov 2013 01:33:51 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 65B382801BE; Wed, 13 Nov 2013 10:33:51 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 5EF4C280102; Wed, 13 Nov 2013 10:33:51 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 5CDA04C007C; Wed, 13 Nov 2013 10:33:21 +0100 (CET) Date: Wed, 13 Nov 2013 10:33:21 +0100 From: Stephane Bortzmeyer To: Ted Lemon Message-ID: <20131113093321.GA13706@nic.fr> References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> X-Operating-System: Debian GNU/Linux 7.2 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: Ted Hardie , perpass , Stephane Bortzmeyer , Andy Wilson , "Wiley, Glen" , Martin Thomson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 09:34:01 -0000 On Tue, Nov 12, 2013 at 09:48:57PM -0500, Ted Lemon wrote a message of 9 lines which said: > That's a terrible argument. Then every eavesdropping issue becomes > a chicken-and-egg problem, because nobody is willing to go first. Indeed. That's an argument that completely denies the point of engineering: "Finding good-enough solutions to actual problems". We do not hope to design perfect solutions. Leakages will always happen. But we try to have *less* leaks, in order, not to make surveillance impossible but, as Bruce Schneier said during the plenary, to make mass surveillance *very* expensive for the spy. Surveillance requires gathering data from several places and making sense of it. The less data, the harder it becomes. Of course, we should not spend too much efforts securing the door when the window is wide open. But each of us should spend efforts on "his" part of the Internet. As a DNS guy, I plan to make surveillance using the DNS harder and more expensive. I'm confident the TLS guys will do the same. From bortzmeyer@nic.fr Wed Nov 13 01:49:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5E21E809C for ; Wed, 13 Nov 2013 01:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.878 X-Spam-Level: X-Spam-Status: No, score=-106.878 tagged_above=-999 required=5 tests=[AWL=3.371, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHH39FRCqqRe for ; Wed, 13 Nov 2013 01:49:37 -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 A3D3D21E809D for ; Wed, 13 Nov 2013 01:49:37 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3B41B28017C; Wed, 13 Nov 2013 10:49:36 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 35D6F280102; Wed, 13 Nov 2013 10:49:36 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 340364C0006; Wed, 13 Nov 2013 10:49:06 +0100 (CET) Date: Wed, 13 Nov 2013 10:49:06 +0100 From: Stephane Bortzmeyer To: "Wiley, Glen" Message-ID: <20131113094906.GB13706@nic.fr> References: <20131111121027.GA31723@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 7.2 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 , Stephane Bortzmeyer , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 09:49:43 -0000 On Mon, Nov 11, 2013 at 07:27:25PM +0000, Wiley, Glen wrote a message of 67 lines which said: > I realize that this is obvious, but it might be worth noting that > there is often (typically) a network connection made to the subject > of a DNS query sent from a stub resolver. For example after sending > a query for www.example.com I am likely to make a connection via TCP > to the address returned. This fact reduces the value of obscuring > DNS queries That's one of the reasons that I mentioned other practices such as having a local resolver (with caching) to limit the number of actual outgoing queries. When it comes for privacy, it is very unlikely that *one* technical solution will plug all the leaks. We have to deploy a consistent set of anti-surveillance measures. Another thing, not yet mentioned in the draft, would be to send dummy queries from time to time, requests you're not interested in, just to blur the patterns. > then they will see outbound connections to www.example.com and so it > doesn't really matter whether they were able to see the DNS query. Read the draft again (section 3.2). For instance, the manager of the TLD .example sees the DNS requests coming in his name servers but typically cannot tap the TLS traffic to www.something.example. > While I agree with the sentiments in this section, is this in scope for > this draft? Yes, it is. We have seen already malwares who modifies the DNS resolvers to a server which, apparently does not lie. The only explanation I can find is that people want to spy on DNS traffic. > Section 6.1 > > It feels as though this section dives into the solution rather than the > problem. At the beginning of this draft, it was only about problem statement. Some people feared it would not be taken seriously if it never mentioned at least possible solutions. (After all, knowing a problem for which there is no solution is depressing.) May be in the future, this draft should be split in two, problem statement and best practices to limit DNS leakage. But, IMHO, it is too early in the discussion to say so. In practice, solutions would probably require several RFC since some are only practices (having a local caching resolver), some require change in software but not in protocol (sending only NS queries to the authoritative servers) and some require new protocols (encrypting DNS traffic). From iain.learmonth.09@aberdeen.ac.uk Wed Nov 13 02:24:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F4111E811A for ; Wed, 13 Nov 2013 02:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVamJrbdu2CJ for ; Wed, 13 Nov 2013 02:24:32 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0082.outbound.protection.outlook.com [213.199.154.82]) by ietfa.amsl.com (Postfix) with ESMTP id ED3AD11E8110 for ; Wed, 13 Nov 2013 02:24:31 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB154.eurprd01.prod.exchangelabs.com (10.141.2.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 13 Nov 2013 10:24:30 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Wed, 13 Nov 2013 10:24:30 +0000 From: "Learmonth, Iain Ross" To: Robin Wilton Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO38EMi+m3JSb4uUeoAPlhMDxny5ohxQeAgAABGtOAAAjYgIABJII9 Date: Wed, 13 Nov 2013 10:24:29 +0000 Message-ID: <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: , <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> In-Reply-To: <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:2c90:8397:34e2:dae8] x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(52314003)(24454002)(51444003)(189002)(199002)(69226001)(46102001)(76796001)(76786001)(77096001)(56816003)(2656002)(87266001)(59766001)(87936001)(77982001)(16236675002)(50986001)(47976001)(15395725003)(74662001)(31966008)(47736001)(49866001)(4396001)(74706001)(74876001)(551544002)(74482001)(47446002)(74502001)(56776001)(54316002)(83072001)(33646001)(15202345003)(65816001)(15975445006)(80022001)(63696002)(81342001)(19580395003)(81816001)(81542001)(81686001)(80976001)(51856001)(79102001)(74366001)(19580405001)(83322001)(76482001)(85306002)(74316001)(53806001)(54356001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB154; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:2c90:8397:34e2:dae8; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_44193667d6c94d43808e85eaa5a254e0DB3PR01MB153eurprd01pro_" MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 10:24:36 -0000 --_000_44193667d6c94d43808e85eaa5a254e0DB3PR01MB153eurprd01pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm talking about storing TLS client certificates encrypted in the cloud an= d synchronising them across browsers, decrypting them client side with a sy= mmetric key generated from a password. This removes a lot of the password specific problems like simply replaying = a password that the NSA saw you type through a CCTV camera. RFC2246 contains details about how clients can authenticate to servers usin= g TLS. The fact that TLS is being used would also mean the connection is en= crypted, avoid sniffing of the wires being a problem (unless the server's p= riv key is compromised or unless there's a downgrade attack and a NULL ciph= er is used or a poor cipher is used). It's encrypted to prevent the cloud provider from being able to hand over t= he certificate. It doesn't necessarily have to encrypted and synchronised in the cloud, an = alternative is smartcards for storage or USB dongles. These devices are alr= eady readily available[1]. Iain. [1]: http://g10code.com/p-card.html -- Iain R. Learmonth MBCS Electronics Research Group School of Engineering University of Aberdeen Kings College Aberdeen AB24 3UE Tel: +44 1224 27 2799 The University of Aberdeen is a charity registered in Scotland No.SCO13683 ________________________________ From: Robin Wilton Sent: 12 November 2013 16:50 To: Learmonth, Iain Ross Cc: Watson Ladd; Phillip Hallam-Baker; perpass Subject: Re: [perpass] Stopping password sniffing Hi Iain, On 12 Nov 2013, at 16:28, Learmonth, Iain Ross wrote: 1) The user decides to unilaterally use a password in the cloud scheme that allows them to store their passwords on one machine and access them from an= y of their browsers. I already do this with LastPass[1]. If we want to move forward with authentication for things like websites tho= ugh, I'd rather see the cloud storing encrypted client certificates that ar= e synchronized and then decrypted client side by a password. This sounds interesting and rational, but it contains a lot of implied deta= il. Can you unpack it a little, e.g. explaining what's in the certificate, = why it needs to be stored in that form, why it's encrypted, which steps of = the protocol are assumed to depend on session-level encryption, and so on? Thx, Robin 3) The browser implementing the password in the cloud scheme alerts the sit= e being contacted to the fact that it can support a direct user authenticatio= n exchange that would make the user experience seamless and support single sign on. LastPass can do an "auto-login", but this would be completely seamless with= TLS client certs. If the site has to be changed anyway, why not do it prop= erly? This also leaves the option of having my certs on a smartcard, USB dongle, = floppy disk, etc. instead of just in the "cloud". Of course, if you wanted to build a system that syncs client certs, you cou= ld also add synchronizing of passwords into it, but I think that would only= really discourage the adoption of the client certs. Iain. [1]: https://lastpass.com/ --_000_44193667d6c94d43808e85eaa5a254e0DB3PR01MB153eurprd01pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm talking about storing TLS client certificates encrypted in the cloud an= d synchronising them across browsers, decrypting them client side with a sy= mmetric key generated from a password.

This removes a lot of the password specific problems like simply replaying = a password that the NSA saw you type through a CCTV camera.


RFC2246 contains details about how clients can authenticate to servers u= sing TLS. The fact that TLS is being used would also mean the connection is= encrypted, avoid sniffing of the wires being a problem (unless the server'= s priv key is compromised or unless there's a downgrade attack and a NULL cipher is used or a poor cipher is u= sed).


It's encrypted to prevent the cloud provider from being able to hand ove= r the certificate.


It doesn't necessarily have to encrypted and synchronised in the cloud, = an alternative is smartcards for storage or USB dongles. These devices are = already readily available[1].


Iain.


[1]: http://g10code.com/p-card.html


--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683<= /span>


From: Robin Wilton <wil= ton@isoc.org>
Sent: 12 November 2013 16:50
To: Learmonth, Iain Ross
Cc: Watson Ladd; Phillip Hallam-Baker; perpass
Subject: Re: [perpass] Stopping password sniffing
 
Hi Iain,


On 12 Nov 2013, at 16:28, Learmonth, Iain Ross wrote:

1) The user decides to unilaterally use a passwor= d in the cloud scheme that
allows them to store their passwords on one machi= ne and access them from any
of their browsers.

I already do this with LastPass[1].

If we want to move forward with authentication for things like websites tho= ugh, I'd rather see the cloud storing encrypted client certificates that ar= e synchronized and then decrypted client side by a password.

This sounds interesting and rational, but it contains a lot of implied= detail. Can you unpack it a little, e.g. explaining what's in the certific= ate, why it needs to be stored in that form, why it's encrypted, which step= s of the protocol are assumed to depend on session-level encryption, and so on?    

Thx,
Robin


3) The browser implementing the password in the c= loud scheme alerts the site
being contacted to the fact that it can support a= direct user authentication
exchange that would make the user experience seam= less and support single
sign on.

LastPass can do an "auto-login", but this would be completely sea= mless with TLS client certs. If the site has to be changed anyway, why not = do it properly?

This also leaves the option of having my certs on a smartcard, USB dongle, = floppy disk, etc. instead of just in the "cloud".

Of course, if you wanted to build a system that syncs client certs, you cou= ld also add synchronizing of passwords into it, but I think that would only= really discourage the adoption of the client certs.

Iain.

[1]: https://lastpass.com/

--_000_44193667d6c94d43808e85eaa5a254e0DB3PR01MB153eurprd01pro_-- From benl@google.com Wed Nov 13 03:54:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4611E80E3 for ; Wed, 13 Nov 2013 03:54:27 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKuIneYfS239 for ; Wed, 13 Nov 2013 03:54:26 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A14D621F9EAE for ; Wed, 13 Nov 2013 03:54:26 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id i12so95988vbh.32 for ; Wed, 13 Nov 2013 03:54:26 -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=c+2W8n2fUHQdtXMQIpEBnb5iYM/Gaue8pH52lsdPi0M=; b=A2dWHifCRgkFjHG2+HRy3P7x1RecxERid9tUTdeJCEBYTatVZ58mluPEH5/hu2pP48 rS/yRq5p887G+SnZkSPCSasLwLWOv540t04WiVgwkktpbql8EZZ3uiGbKU5KGUOb84Jf vRovqXLGWWFoxpQK6F5GEyQW2HyFZbctORrnNFZ0dU6zFo5N+vfYQly4CAbMo4oxsKxB B69MoAYDQuGlryU5D8bD9X9zAq9FPgqxgacJ5QazsBQz4AmfnXru/j/CpXB5Krwy/qNE akEw4aixJs6ZeCC+B8LVH0+aoRb6DfJrKsa8E5KAD3EODf9xgABwDubyUidGPjZBVU69 BMng== 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=c+2W8n2fUHQdtXMQIpEBnb5iYM/Gaue8pH52lsdPi0M=; b=DMk6jrElxJcoPd/bvUgq/cA4MDnRkoS+oaOygLIipZcFKn0G8AOzJ5SLzYUCl2t/dV ZM7B5pgY60dR15qlojxPTLLcuzH4M+7px1cckyB+HB8KwV/GcL21OSCF7X5F4V6/O6GW dfdgQ/yiVDPlbo7sLQY+AZRric67hASuUU4RNY0VFtI7u2plSAgRpoxO6DCJRqXcsnYe 88NYoDbgUSYvgRLX28l7ss4bwfSQxnQBwwYoUqiRLrnJr9vSRkAwoBiZpA4T1U5UdQy9 IRlUuCn2RQZ9+//o0BUIMM/aNNDlO2toRb3QR406XryJjhYmF1QdU9Bk8OlNW6w/Yrxj iGZw== X-Gm-Message-State: ALoCoQlmoGoKv9vP+ffKKJexSVsHB5VhxCajlKtvcnvGDbhQqoZhW9YnqiqLBXNmrmpqjMG1+4b4oGb5rxUsFTn/trDik1J6VAgFt6owaxKpB2uiHgZYGRxYsGSyuIkPIHoRp8RYrvK0vIUMK94ODDqheVVTtYov/64lwZ5DdLtloEvmV9NbeZV1H7jMiQONx32EiBpVBzMg MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr25760727vcx.1.1384343666189; Wed, 13 Nov 2013 03:54:26 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 13 Nov 2013 03:54:25 -0800 (PST) In-Reply-To: <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Wed, 13 Nov 2013 11:54:25 +0000 Message-ID: From: Ben Laurie To: "Learmonth, Iain Ross" Content-Type: text/plain; charset=ISO-8859-1 Cc: Robin Wilton , perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 11:54:27 -0000 On 13 November 2013 10:24, Learmonth, Iain Ross wrote: > I'm talking about storing TLS client certificates encrypted in the cloud and > synchronising them across browsers, decrypting them client side with a > symmetric key generated from a password. http://www.links.org/files/nigori/nigori-protocol-01.html From ondrej.sury@nic.cz Wed Nov 13 04:11:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380D921E80DE for ; Wed, 13 Nov 2013 04:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFdwW2GZrQVk for ; Wed, 13 Nov 2013 04:11:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C611E80F5 for ; Wed, 13 Nov 2013 04:11:11 -0800 (PST) Received: from kimac.labs.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 33A7313F994; Wed, 13 Nov 2013 13:11:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1384344670; bh=CuQ1Sz8GeUEHk8JWWtU3Z+EON+8pV0Cv9kaXC9MpE4c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=FKMLcRxS5i/X2kNcrxHdHfVTp/TgGZS7+f9Z2JUzRyneMuow2bdRDK/M/JRv7thto mjbZrRwrGk1UoFxWS51kuV/AiOJbOfG/lhK4ZyQzsjK7VQ3nAh354RIV6PxsWaaJb4 pN1bEf/935Ole7bmZV+jq72+GEfl/KuhvTQ3Zuw4= Content-Type: multipart/signed; boundary="Apple-Mail=_CE8C7E33-BC7F-468A-B941-F72D53248358"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20131113094906.GB13706@nic.fr> Date: Wed, 13 Nov 2013 13:11:08 +0100 Message-Id: <3C2ED3AF-9B1C-4049-A0A8-C021F41B88F1@nic.cz> References: <20131111121027.GA31723@sources.org> <20131113094906.GB13706@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "Wiley, Glen" , perpass , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 12:11:18 -0000 --Apple-Mail=_CE8C7E33-BC7F-468A-B941-F72D53248358 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 13. 11. 2013, at 10:49, Stephane Bortzmeyer = wrote: >> then they will see outbound connections to www.example.com and so it >> doesn't really matter whether they were able to see the DNS query. >=20 > Read the draft again (section 3.2). For instance, the manager of the > TLD .example sees the DNS requests coming in his name servers but > typically cannot tap the TLS traffic to www.something.example. JFTR with my TLD hat on I fully support Stephane's draft. Every little = bit counts and neither chicken-and-egg nor too-long-to-deploy should not = stop us from making security or privacy better. And the less information I see on TLD DNS servers the better. I (as an = TLD server operator) don't want to know all the information since that = makes me vulnerable to attacks and/or legal wiretapping. The SNI/TLS cleartext should motivate people to fix TLS and not to = hinder the improvements in DNS area. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_CE8C7E33-BC7F-468A-B941-F72D53248358 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMx MTEzMTIxMTEwWjAjBgkqhkiG9w0BCQQxFgQUcxmq3krowmFx4o9dmT0wjFPCmI0wgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAHyNCOuv6YG3ko4Sju4ikbD6zkxgnDigy5mbpgSDeUJ3zEvo6Eksc6T5QDReT oLxJu/pa0F/6W7zS2bEuqYnzjeKeB9F4/W+sx5NZxYolW6i4c4hZY35ALs7ozcnHW3P+nXsd/W43 jKe0DNNvOJeKsUCJzgS4Qx655L6XbEyrncAgmC7HassV1kmvGPlUvdiZxF/Lt2o6f8rKtKbJU+tT mB6tiHNfNohKCmP+IFW0M9Z5DqfTHIiYZXQyzmiOdPYAPe1snIiAgU/kMsJC6xAkaoJHv0kcMhf/ K+Cew0ZU/RfoMI8zH+BkOShaYSB+JJUtNx1wFoQNItw3kil88sfhrwAAAAAAAA== --Apple-Mail=_CE8C7E33-BC7F-468A-B941-F72D53248358-- From hallam@gmail.com Wed Nov 13 04:52:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E5A11E8180 for ; Wed, 13 Nov 2013 04:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkPCt2ve-0Bt for ; Wed, 13 Nov 2013 04:52:17 -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 84FAD11E80F7 for ; Wed, 13 Nov 2013 04:52:17 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id eh20so297888lab.5 for ; Wed, 13 Nov 2013 04:52:16 -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=tt07J8alHUJtbhlX2nw+srXkhWpK/dAje3TZBB5v9JM=; b=k7z2IuB6vmPAzRSpOjF83HOKSqXoIbFZvMocwUG8SptezQppXxlsNGCqEaAgKoQv3u 7DxhAn/yI4BecaT86iffyRSpKeSGwqtj8oDIPe6/mb0DoC/obA5HTCz9tZ+qyeh85zWp WrNoR4QPtH0shgVhUyv6C1I5gBtdE5NnYxDmSPjp7aVdxp311X7iwNM2QVgwI226vNeR QZ/ahJsDoQQaugfm6nwdXvOHBf0ka9Ebh+DXWZHLJxU6ZDg/tqTfthjfZ5ennQhJEjLU N3EropVGR3Dr/wyPnM7wb/YxzMBUycNGgwkdIGHBjDcjIwQK5vovZlz2R38lt0uJJ6xA c3Xw== MIME-Version: 1.0 X-Received: by 10.152.28.37 with SMTP id y5mr10770618lag.23.1384347136552; Wed, 13 Nov 2013 04:52:16 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 13 Nov 2013 04:52:16 -0800 (PST) Date: Wed, 13 Nov 2013 04:52:16 -0800 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=089e0158ca0251f6f604eb0e6f98 Subject: [perpass] Secure Dropbox is Secure Email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 12:52:18 -0000 --089e0158ca0251f6f604eb0e6f98 Content-Type: text/plain; charset=ISO-8859-1 I was thinking about the secure Dropbox type application last night. Two thoughts: 1) Dropbox is really a messaging protocol only the inbound and outbound server is the same and without all the MIME encoding nonsense required to get through legacy mail systems. 2) Adding flood fill routing and breaking messages into constant size chunks makes it possible to avoid traffic analysis. Though this will inevitably have a cost impact in higher bandwidth and longer latency. People who want their messages to be untraceable are probably going to have to accept that it might take some days for a message to arrive at the intended destination. I am rather skeptical of application layer traffic analysis protection but would not want to foreclose the option. The realization that Dropbox is only a variation of mail is interesting as it suggests that rather than building a separate protocol it would be better to consider a next generation email protocol that is capable of handling large attachments. The main requirement for handling large attachments would be that the attachment is posted to the outbound mail server and is fetched by the end receiver after they decide to accept it. In addition we would want to require end to end encryption and signature (for spam control). The ability to restart transfers that were previously aborted in mid session would also be useful. -- Website: http://hallambaker.com/ --089e0158ca0251f6f604eb0e6f98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was thinking about the secure Dropbox type application l= ast night.

Two thoughts:

1) Dro= pbox is really a messaging protocol only the inbound and outbound server is= the same and without all the MIME encoding nonsense required to get throug= h legacy mail systems.

2) Adding flood fill routing and breaking messages into= constant size chunks makes it possible to avoid traffic analysis. Though t= his will inevitably have a cost impact in higher bandwidth and longer laten= cy. People who want their messages to be untraceable are probably going to = have to accept that it might take some days for a message to arrive at the = intended destination.


I am rather skeptical of applica= tion layer traffic analysis protection but would not want to foreclose the = option.

The realization that Dropbox is only a var= iation of mail is interesting as it suggests that rather than building a se= parate protocol it would be better to consider a next generation email prot= ocol that is capable of handling large attachments.

The main requirement for handling large attachments wou= ld be that the attachment is posted to the outbound mail server and is fetc= hed by the end receiver after they decide to accept it.

In addition we would want to require end to end encryption and signatu= re (for spam control). The ability to restart transfers that were previousl= y aborted in mid session would also be useful.


--
Website: http://hallam= baker.com/
--089e0158ca0251f6f604eb0e6f98-- From gwiley@verisign.com Wed Nov 13 05:00:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E987D11E8182 for ; Wed, 13 Nov 2013 05:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUAhWfC9U6X2 for ; Wed, 13 Nov 2013 05:00:14 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C111E8105 for ; Wed, 13 Nov 2013 05:00:12 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUoN33MHVMwrJSe7lI30eI93niBoiwTJB@postini.com; Wed, 13 Nov 2013 05:00:14 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rADD0Bwv007097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 08:00:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Nov 2013 08:00:11 -0500 From: "Wiley, Glen" To: Stephane Bortzmeyer Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiAgALW6QD//+GPAA== Date: Wed, 13 Nov 2013 13:00:10 +0000 Message-ID: In-Reply-To: <20131113094906.GB13706@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 13:00:20 -0000 Just to be clear - I support the draft in principle. My comments are intended to help refine the document. --=20 Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 11/13/13 4:49 AM, "Stephane Bortzmeyer" wrote: >On Mon, Nov 11, 2013 at 07:27:25PM +0000, > Wiley, Glen wrote > a message of 67 lines which said: > >> I realize that this is obvious, but it might be worth noting that >> there is often (typically) a network connection made to the subject >> of a DNS query sent from a stub resolver. For example after sending >> a query for www.example.com I am likely to make a connection via TCP >> to the address returned. This fact reduces the value of obscuring >> DNS queries > >That's one of the reasons that I mentioned other practices such as >having a local resolver (with caching) to limit the number of actual >outgoing queries. When it comes for privacy, it is very unlikely that >*one* technical solution will plug all the leaks. We have to deploy a >consistent set of anti-surveillance measures. > >Another thing, not yet mentioned in the draft, would be to send dummy >queries from time to time, requests you're not interested in, just to >blur the patterns. > >> then they will see outbound connections to www.example.com and so it >> doesn't really matter whether they were able to see the DNS query. > >Read the draft again (section 3.2). For instance, the manager of the >TLD .example sees the DNS requests coming in his name servers but >typically cannot tap the TLS traffic to www.something.example. > >> While I agree with the sentiments in this section, is this in scope for >> this draft?=20 > >Yes, it is. We have seen already malwares who modifies the DNS >resolvers to a server which, apparently does not lie. The only >explanation I can find is that people want to spy on DNS traffic. > >> Section 6.1 >>=20 >> It feels as though this section dives into the solution rather than the >> problem. > >At the beginning of this draft, it was only about problem >statement. Some people feared it would not be taken seriously if it >never mentioned at least possible solutions. (After all, knowing a >problem for which there is no solution is depressing.) > >May be in the future, this draft should be split in two, problem >statement and best practices to limit DNS leakage. But, IMHO, it is >too early in the discussion to say so. > >In practice, solutions would probably require several RFC since some >are only practices (having a local caching resolver), some require >change in software but not in protocol (sending only NS queries to the >authoritative servers) and some require new protocols (encrypting DNS >traffic). > From iain.learmonth.09@aberdeen.ac.uk Wed Nov 13 05:27:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C8D21E8139 for ; Wed, 13 Nov 2013 05:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK776tjkf0CP for ; Wed, 13 Nov 2013 05:27:03 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) by ietfa.amsl.com (Postfix) with ESMTP id A9DA121E80EE for ; Wed, 13 Nov 2013 05:27:01 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB154.eurprd01.prod.exchangelabs.com (10.141.2.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 13 Nov 2013 13:26:59 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Wed, 13 Nov 2013 13:26:59 +0000 From: "Learmonth, Iain Ross" To: Ben Laurie Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO38EMi+m3JSb4uUeoAPlhMDxny5ohxQeAgAABGtOAAAjYgIABJII9gAAbNYCAABYVyA== Date: Wed, 13 Nov 2013 13:26:59 +0000 Message-ID: <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:2c90:8397:34e2:dae8] x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(199002)(57704003)(69226001)(46102001)(76796001)(76786001)(77096001)(56816003)(2656002)(87266001)(59766001)(87936001)(77982001)(50986001)(47976001)(74662001)(31966008)(47736001)(49866001)(4396001)(74706001)(74876001)(551544002)(74482001)(47446002)(74502001)(56776001)(54316002)(83072001)(33646001)(15202345003)(65816001)(15975445006)(80022001)(63696002)(81342001)(19580395003)(81816001)(81542001)(81686001)(80976001)(51856001)(79102001)(74366001)(19580405001)(83322001)(76482001)(85306002)(74316001)(53806001)(54356001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB154; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:2c90:8397:34e2:dae8; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: Robin Wilton , perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 13:27:15 -0000 I don't know enough about crypto to make a decision as to whether or not en= ough protection is provided, but if the abstract is an accurate representat= ion, then Nigori would fit perfectly for this task.=0A= =0A= A quick web search doesn't seem to show any method of installing client cer= tificates in Firefox with an extension, but there are ways of doing it quit= e easily with Internet Explorer (using the Windows Certificate Store).=0A= =0A= Currently Nigori only seems to support the storage of passwords and RSA key= s but I imagine it wouldn't be hard to define a new type for X.509 certific= ates and keys.=0A= =0A= If Nigori can be standardized and then integrated into client applications = (like web browsers, mail clients, anything that uses or can use TLS) then I= believe we'd have half the solution. The other half would be convincing se= rvice providers to allow TLS authentication.=0A= =0A= Another thought though - How would a service provider get the public TLS ce= rt? Typically, I've had to copy and paste the cert into a box or a config f= ile.=0A= =0A= Another another thought - Is it a good idea to use multiple certs for diffe= rent services or just one for all? Reuse shouldn't be a problem here but th= ere may be cases I'm not thinking of. It would probably be a good idea to a= llow for switching "profiles" which would use a different cert store (in ca= se of multiple accounts on one service provider).=0A= =0A= If I'm logged into my email but then want to post on a different Twitter ac= count and switch store to log into that Twitter account, I'd not have my em= ail anymore. Do we need a method of selecting a cert to serve to different = websites and then remembering it for that session until the browser is told= to use a different one?=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: Ben Laurie =0A= Sent: 13 November 2013 11:54=0A= To: Learmonth, Iain Ross=0A= Cc: Robin Wilton; perpass=0A= Subject: Re: [perpass] Stopping password sniffing=0A= =0A= On 13 November 2013 10:24, Learmonth, Iain Ross=0A= wrote:=0A= > I'm talking about storing TLS client certificates encrypted in the cloud = and=0A= > synchronising them across browsers, decrypting them client side with a=0A= > symmetric key generated from a password.=0A= =0A= http://www.links.org/files/nigori/nigori-protocol-01.html=0A= From mcr@sandelman.ca Wed Nov 13 06:05:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EE921E80D3 for ; Wed, 13 Nov 2013 06:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpGK2+rzOJF9 for ; Wed, 13 Nov 2013 06:05:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 337EC11E815E for ; Wed, 13 Nov 2013 06:05:30 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27E3020343; Wed, 13 Nov 2013 10:17:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 473EC63B88; Wed, 13 Nov 2013 09:05:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 36B4E63AEF; Wed, 13 Nov 2013 09:05:20 -0500 (EST) From: Michael Richardson To: Stephen Farrell In-Reply-To: <5282EC17.5060808@cs.tcd.ie> References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> <5282EC17.5060808@cs.tcd.ie> 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: Ted Hardie , Ted Lemon , perpass , Stephane Bortzmeyer , Andy Wilson , "Wiley, Glen" , Martin Thomson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:05:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On the subject of SNI itself.... lack of support for SNI for a number of legacy browsers still in use means that few sites using SSL can do it any w= ay other than the one-IP(port) per certificate. This is a tragedy in the IPv4 world, but really hardly merits even a shrug in an IPv6 world. On the other hand, with a 1:1 mapping between IPv6 and DNS name (and certificate), you don't need to see/capture the transport or session(ssl) layer at all to know do the traffic analysis. So one gets the traffic analysis at the DNS name from the netflow (aka "Pen Registry") records without eating any multi-gigabite firehoses. If TLS could become more IKE-like, leaving the SNI and the authentication until after the PFS (maybe it can do this already now), then traffic analys= is would be defeated by putting as many sites on the same IP address as possible.=20=20=20 (Possibly, this also interacts poorly with some of the various netnanny software, which has unfairly prevented teens from learning enough to protect themselves from STD in the name of protecting them from pr0n. ) My take is that any mechanism (legal and technological) which keeps the middle boxes on a need to know basis only, is good. It might not prevent traffic analysis, but it does help maintain the end to end. (Imagine the state of the world of TCP cryptographically secured the port numbers, or if HTTPS had done that, and NAPTs simply couldn't have worked) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoOHIIqHRg3pndX9AQItjQP/QINktulU9D0NeMrMzOYjV6jp8S6SqY9j VMLJyX7mYwdHZXh2Covq1M5IPqtmcW6VBj38DsMbK2nKeju+5Ack03LE+Fud59wk 1SL+0rxOtcPw2a+XSW3IWn/tMjslzcrQ23oiPWcEw5ozTsgnhh3x+j7fB8XudMkv a/oSUIf00lQ= =m+vr -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Wed Nov 13 06:32:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BF21E8158 for ; Wed, 13 Nov 2013 06:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf07+mk4793X for ; Wed, 13 Nov 2013 06:32:40 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2F21E8139 for ; Wed, 13 Nov 2013 06:32:38 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id C2202238081B; Wed, 13 Nov 2013 09:32:37 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> Date: Wed, 13 Nov 2013 09:32:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131111121027.GA31723@sources.org> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com> <335D1A6F-A44C-444A-9379-7D03D873F543@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:32:46 -0000 On Nov 13, 2013, at 12:22 AM, Yoav Nir wrote: > I'm one of those that made that argument. I do think we should fix = this in TLS, but realistically, browsers are going to continue sending = SNI in the clear for at least another 10 years. Yes, we should fix this = now, because whenever we start, that's when the 10-year countdown = begins. The same is true for any modification to DNS, except the = timeframe is likely to be even longer. That doesn't sound *quite* like what I heard Stephen say, and I don't = disagree with it, although I don't agree either=97it's hard to predict = what browser people will do, and ten years is a long time in the browser = business. So you might as well fix the spec, and see what happens. From kent@bbn.com Wed Nov 13 06:34:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE0E11E815F for ; Wed, 13 Nov 2013 06:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfCn6SBDHWmt for ; Wed, 13 Nov 2013 06:34:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6911E814C for ; Wed, 13 Nov 2013 06:34:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41203 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VgbWn-000LMw-9p for perpass@ietf.org; Wed, 13 Nov 2013 09:34:45 -0500 Message-ID: <52838E05.9090300@bbn.com> Date: Wed, 13 Nov 2013 09:34:45 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> In-Reply-To: <5281542F.1080802@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:34:54 -0000 Stephen, I agree that mitigation is the preferred term. I am not so comfortable with using this list to incrementally develop new proposals via e-mail exchanges, instead of requiring proposals to be prepared as I-Ds. There are enough folks on the list with IETF I-D prep experience to assist anyone who needs help. The rigor of writing a document usually helps refine one's ideas (and spares others from half-baked notions :-) ). Steve From stephen.farrell@cs.tcd.ie Wed Nov 13 06:40:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B9111E8180 for ; Wed, 13 Nov 2013 06:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPVCUWfFEmtr for ; Wed, 13 Nov 2013 06:40:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2711E815A for ; Wed, 13 Nov 2013 06:40:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BCD27BE9A; Wed, 13 Nov 2013 14:40:52 +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 qVfDyeP32vgQ; Wed, 13 Nov 2013 14:40:52 +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 8B808BE8E; Wed, 13 Nov 2013 14:40:52 +0000 (GMT) Message-ID: <52838F74.6030907@cs.tcd.ie> Date: Wed, 13 Nov 2013 14:40:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Kent , perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> In-Reply-To: <52838E05.9090300@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:40:58 -0000 Hi Steve, On 11/13/2013 02:34 PM, Stephen Kent wrote: > Stephen, > > I agree that mitigation is the preferred term. > > I am not so comfortable with using this list to incrementally develop > new proposals via e-mail exchanges, instead of requiring proposals to be > prepared as I-Ds. There are enough folks on the list with IETF I-D prep > experience to assist anyone who needs help. > > The rigor of writing a document usually helps refine one's ideas > (and spares others from half-baked notions :-) ). I agree, which is why I included this bit: "Those with proposals are encouraged to embody them in detailed internet-draft specifications, rather than relying solely on email messages." I'm quite happy to make that a bit stronger if someone has words to offer, but we also don't want to push away all mail discussion of course - I think it should be fine if there's an initial discussion on a topic to see if its worth pursuing, so long as that's fairly quickly turned into an I-D and we don't get the "design via email exchanges" thing taking up everyone's cycles. S. > > Steve > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From mellon@fugue.com Wed Nov 13 06:43:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7321F9FB4 for ; Wed, 13 Nov 2013 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AioL6oVF1CZZ for ; Wed, 13 Nov 2013 06:43:28 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 44EAB21F9FAE for ; Wed, 13 Nov 2013 06:43:28 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 37F9A238081B; Wed, 13 Nov 2013 09:43:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Wed, 13 Nov 2013 09:43:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86B2A56B-6F49-4035-AFF7-46FDE26715BA@fugue.com> References: , <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> To: "Learmonth, Iain Ross" X-Mailer: Apple Mail (2.1822) Cc: Robin Wilton , perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:43:34 -0000 On Nov 13, 2013, at 5:24 AM, Learmonth, Iain Ross = wrote: > I'm talking about storing TLS client certificates encrypted in the = cloud and synchronising them across browsers, decrypting them client = side with a symmetric key generated from a password. Why use cloud sync and shared keys? Why not have a different cert on = each browser, signed by my master key, and then certify the master key? = Granted this leaves open a pretty big hole if the master key is = compromised, and we don't really care this much about most of our web = logins, but storing the client key in the cloud seems chancy, = particularly if it's protected by a password. Of course, storing the = master key on a virus-infected PC is no better, but if your PC is = infected with a virus, your cloud-stored cert will be revealed anyway. = A custom rPI that serves as your key master and never does anything else = would be a good, cheap option. From benl@google.com Wed Nov 13 06:47:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BF521E812C for ; Wed, 13 Nov 2013 06:47:46 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WViU4ASzY4UI for ; Wed, 13 Nov 2013 06:47:46 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id F034F21F9FC8 for ; Wed, 13 Nov 2013 06:47:45 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id q4so343672vbe.41 for ; Wed, 13 Nov 2013 06:47: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:content-transfer-encoding; bh=qR5Mh7yULqWVh23p2zgBr7FPQP0RdmNjT6T1x81Yfq4=; b=SigfeWqtZ2ul1z1vrnl9zc1He7SL33Nfl1okW0BFs207TzmZPKLYeiuuBqB32az62P hcALnPl90WRNHr+8jg6v3u4dICTTNqS//pLnzQ+qmvotN5q7xMKhpFkTf89X+0Gi0rCt w0DhIU/DFQoK2s6H/L5yQp2vJu/7GVe03Mis+OUUYL4sGpsLNO2w/EtEcu6ih9Xs9j8p 3jNMUkL8LxrKjyE9ydYICZxl4RykolXrwgmf5BZgWz3l7v5FkE9n0szuYnxs33DnW/Up MoioXJtXf2cXbR2M0GtgSiQ0viAv/fOW9htW0RGDsnGLOFskiA29dfT+OasbKFVgyrPu dGMw== 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=qR5Mh7yULqWVh23p2zgBr7FPQP0RdmNjT6T1x81Yfq4=; b=izIvIfzdLtyL+4BMId5emU6cuN12aaCd8+PEnGrijecrwvE8eUBFU3Ajq3B04ASHVN WckZY0f3OsqMBgTAJqiJ1cUxudlR0kwDzflV/SBfJHJqP3NfEAy3Vt8WXPHAZjGmt+Dc ygVJr5xkyZsUqwasCSrhDuhAe0f0NhbtgvrDkC9axcjPbxq5t8v4PiMAOML2jTh1TZb7 laS3jHUVvd0V/ePNbGoY+U1/S0AK5utiYgQpvYRKZ9sOPP62nYSjIxklFwBa9W1CxSRG R9jegH78SuPKCOmuP5hRno6F9LMdZQ+Iuk+mi0K+2KLtBcZUjmgduF17ttG64bHKQwog bAMA== X-Gm-Message-State: ALoCoQn6y8N2QCv7suZbJkf7aFQn7QinbOnHk7C7Xv1l6Xlg5r6XO87vSIX1jW7zx6GTUqWe4MHdW/mMmfdPRveGHm7uipN5rKP4dbN0DKfoabGwZjEpdOVF/wq67j/44ZJDgO5ZU4Mqw57I3SDq0VwSyqwm6R78KW5Zip+Eyu/xlg1U+B8tTLpl9OWsEb0U6McLLPstEobP MIME-Version: 1.0 X-Received: by 10.52.66.197 with SMTP id h5mr991728vdt.43.1384354065229; Wed, 13 Nov 2013 06:47:45 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 13 Nov 2013 06:47:45 -0800 (PST) In-Reply-To: <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Wed, 13 Nov 2013 14:47:45 +0000 Message-ID: From: Ben Laurie To: "Learmonth, Iain Ross" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robin Wilton , perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:47:46 -0000 On 13 November 2013 13:26, Learmonth, Iain Ross wrote: > Another another thought - Is it a good idea to use multiple certs for dif= ferent services or just one for all? Reuse shouldn't be a problem here but = there may be cases I'm not thinking of. It would probably be a good idea to= allow for switching "profiles" which would use a different cert store (in = case of multiple accounts on one service provider). The problem with re-use is that it introduces a pretty big privacy problem. So, I'd say a cert per service. From iain.learmonth.09@aberdeen.ac.uk Wed Nov 13 06:57:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA321E8118 for ; Wed, 13 Nov 2013 06:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLRVZhPavMVh for ; Wed, 13 Nov 2013 06:56:58 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id A051021E8105 for ; Wed, 13 Nov 2013 06:56:57 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB156.eurprd01.prod.exchangelabs.com (10.141.2.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 13 Nov 2013 14:56:56 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Wed, 13 Nov 2013 14:56:56 +0000 From: "Learmonth, Iain Ross" To: Ben Laurie Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO38EMi+m3JSb4uUeoAPlhMDxny5ohxQeAgAABGtOAAAjYgIABJII9gAAbNYCAABYVyIAAGlmAgAAAKUc= Date: Wed, 13 Nov 2013 14:56:55 +0000 Message-ID: <749160fb143d49a88e70324c9c4e1bee@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:2c90:8397:34e2:dae8] x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(199002)(189002)(87936001)(76786001)(76796001)(31966008)(19580395003)(56816003)(77096001)(83322001)(19580405001)(76482001)(74662001)(83072001)(74482001)(74502001)(47446002)(551544002)(80976001)(33646001)(4396001)(81542001)(81342001)(46102001)(69226001)(53806001)(54356001)(51856001)(2656002)(87266001)(50986001)(47976001)(49866001)(47736001)(59766001)(77982001)(81816001)(74366001)(74706001)(56776001)(54316002)(85306002)(74876001)(74316001)(81686001)(63696002)(79102001)(65816001)(80022001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB156; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:2c90:8397:34e2:dae8; 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: aberdeen.ac.uk Cc: Robin Wilton , perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:57:08 -0000 I was about to say signing client keys with a master key was a good idea. I= t would remove the need for a cloud sync as once set up, the browsers would= inherit the access from the master key without the need for synchronizatio= n.=0A= =0A= Then, yes, re-use would allow for tracking across websites. So maybe not su= ch a great idea.=0A= =0A= Maybe the compromise is not a cert per service, but a cert per identity (in= the loosest possible sense of the word). Maybe your social media accounts = where you are you are under one, and your reddit and slashdot accounts unde= r another, etc. =0A= =0A= If it's possible to have the keys available on the devices you need without= having anything on a server not controlled by the owner of the keys, that = is the best case scenario, but if new identities are created "at runtime" (= i.e. after the inital setup of the device) then those keys need to find the= ir way into the other devices.=0A= =0A= With a smartcard, this is as easy as plugging the smartcard into the device= you're using, but - another thought - would probably mean requiring multip= le smartcards as I am logged into my email on about 4 different devices at = a time.=0A= =0A= I'm not sure with TLS client authentication if it just tries all the person= al keys it has or if the server advertises which keys would be accepted. I'= m guessing it'll be the former so even if there is one key per service, the= other certs would still become known to the server when authentication usi= ng them is attempted?=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: Ben Laurie =0A= Sent: 13 November 2013 14:47=0A= To: Learmonth, Iain Ross=0A= Cc: Robin Wilton; perpass=0A= Subject: Re: [perpass] Stopping password sniffing=0A= =0A= On 13 November 2013 13:26, Learmonth, Iain Ross=0A= wrote:=0A= > Another another thought - Is it a good idea to use multiple certs for dif= ferent services or just one for all? Reuse shouldn't be a problem here but = there may be cases I'm not thinking of. It would probably be a good idea to= allow for switching "profiles" which would use a different cert store (in = case of multiple accounts on one service provider).=0A= =0A= The problem with re-use is that it introduces a pretty big privacy=0A= problem. So, I'd say a cert per service.=0A= From york@isoc.org Wed Nov 13 07:32:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787121E8145 for ; Wed, 13 Nov 2013 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkNIJ87MZD49 for ; Wed, 13 Nov 2013 07:32:09 -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 5E02B21E8130 for ; Wed, 13 Nov 2013 07:32:09 -0800 (PST) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB070.namprd06.prod.outlook.com (10.242.211.12) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 13 Nov 2013 15:32:07 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.185]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.185]) with mapi id 15.00.0785.001; Wed, 13 Nov 2013 15:32:07 +0000 From: Dan York To: Stephane Bortzmeyer , Stephen Farrell Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHOuQI4t76GJ0/ks0CciXEiX6amc5nUwR0AgAGerYCAAAW+AIAAAWyAgEnVC4CAAwkwgA== Date: Wed, 13 Nov 2013 15:32:06 +0000 Message-ID: In-Reply-To: <20131111121027.GA31723@sources.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [74.75.92.114] x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(199002)(52604005)(51704005)(479174003)(377454003)(4396001)(49866001)(66066001)(80022001)(65816001)(81686001)(63696002)(31966008)(15395725003)(79102001)(15975445006)(74662001)(74502001)(81816001)(47446002)(50986001)(47976001)(15202345003)(47736001)(51856001)(59766001)(74876001)(54316002)(2656002)(87266001)(81542001)(77982001)(74366001)(53806001)(54356001)(69226001)(76482001)(46102001)(81342001)(74706001)(56776001)(83072001)(80976001)(83322001)(19580395003)(77096001)(56816003)(85306002)(76786001)(76176001)(36756003)(76796001)(19580405001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR06MB070; H:BN1PR06MB072.namprd06.prod.outlook.com; CLIP:74.75.92.114; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <96B9160A6CEFCF40851EBB12CF075FB5@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: perpass , Andy Wilson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 15:32:13 -0000 Stephane, On 11/11/13 7:10 AM, "Stephane Bortzmeyer" wrote: >> May be starting with the more modest but certainly useful "DNS >> privacy considerations" Internet-Draft? Such a document, just >> documenting the problem, would be a good idea, IMHO. > >Done.=20 >http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy Excellent draft! Thank you for taking the time to write this and I very much support the draft and the material you've written. A few comments: In section 3.2, "On the wire", it might be worth expanding a bit to note that the attack surface between the stub resolver and the caching resolver can vary widely depending upon how the end user's computer is configured. It seems to me there are typically 4 different locations that may be configured as the caching resolver. Here is some draft text for your consideration: ---- 1. Resolver at the ISP - For most residential users and potentially other networks the typical case is for the end user's computer to be configured (typically automatically through DHCP) with the addresses of the DNS resolver at the ISP. The attack surface for on-the-wire attacks is therefore from the end user system across the local network and across the ISPs network to the ISP's resolvers. 2. Resolver at the local network edge - For many/most enterprise networks and for some residential users the caching resolver may exist on a server at the edge of the local network. In this case the attack surface is the local network. Note that in large enterprise networks the DNS resolver may not be located at the edge of the local network but rather at the edge of the overall enterprise network. In this case the enterprise network could be thought of as similar to the ISP network referenced above. 3. Resolver at a public DNS service - Some end users may be configured to use public DNS resolvers such as those operated by Google's Public DNS or the OpenDNS team. The end user may have configured their machine to use these DNS resolvers themselves - or their ISP may choose to use the public DNS resolvers rather than operating their own resolvers. In this case the attack surface is the entire public Internet between the end user's connection and the public DNS service. 4. Resolver on the end user's computer - In a small number of cases, individuals may choose to operate their own DNS resolver on their local machine. In this case the attack surface for the stub resolver to caching resolver connection is limited to that single machine. ---- There could be additional cases but those are what came to my mind. From an attack perspective it's obviously much harder to do an on-the-wire attack between a stub resolver and caching resolver against someone running a caching resolver on the edge of their local network (or on their machine) than it is against someone using a public DNS service. In some of Geoff Huston's recent DNSSEC measurements that he's presented at various events, one interesting aspect was the very high percentage of people in some regions who were using Google's Public DNS servers. I seem to recall at Geoff's presentation at the IEPG meeting in Berlin in July he mentioned that it seemed like the major ISPs in some countries had all decided to use Google's servers vs running their own. In section 3.3.2 you state: ---- As of today, all the instances of one root name server, L-root, receive together around 20 kq/s. ---- I can't find "kq/s" defined anywhere in the draft and so you might want to expand this here. I'm assuming you mean "kilo-queries per second", correct? In section 6.1 about possible solutions to "On the wire" attacks, I would suggest perhaps putting all the text into a 6.1.1 titled "Encryption" and then creating a 6.1.2 called perhaps "Reducing the attack surface" with text along these lines (assuming text similar to what I wrote above is incorporated into section 3.2): ---- One mechanism to potentially mitigate on the wire attacks between stub resolvers and caching resolvers is to determine if the network location of the caching resolver can be moved closer to the end user's computer. As noted earlier in section 3.2, if an end user's computer is configured with a caching resolver on the edge of the local network, an attacker would need to gain access to that local network in order to successfully execute an on the wire attack against the stub resolver. On the other hand, if the end user's computer is configured to use a public DNS service as the caching resolver, the attacker needs to simply get in the network path between the end user and the public DNS server and so there is a much greater opportunity for a successful attack. Configuring a caching resolver closer to the end user can reduce the possibility of on the wire attacks. ---- Or something like that=8A I enjoyed your section 7! :-) I have a few other editorial nits regarding wording that I'll send you privately. Again=8A great draft. Thanks for taking the time to put it together. Dan --=20 Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/=20 From ted.ietf@gmail.com Wed Nov 13 08:17:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9BA21E80A9 for ; Wed, 13 Nov 2013 08:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWFKnVhjFJDR for ; Wed, 13 Nov 2013 08:17:01 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1910821E8152 for ; Wed, 13 Nov 2013 08:16:55 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn6so2625535wib.10 for ; Wed, 13 Nov 2013 08:16:55 -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=jf/dUMIBFKn1ImjUwHFeIDITfBENiYvSooeYwD+CWnA=; b=xEvkEF7OoJSEVcYrfQMsWlX4h9b/l89ML8fHg47n8VVYy48YCMHoFaG3IwiI8zExui TaUSERzzMVIbuazGTn5MOKOivmsBNlabPGosKHGaKqKw9hpA5vLM1oxgyHwjZ+BSYenM A4pPyGMLbCYMNh0a8G3iTWSscMhYhyEDqpL5lcu5kYl3dD9wMvuCuHssdbB7HsWU9hFo 64ZQBd7XMQf6/lEZMpp7WogTCwMncATrl9EraxaWiMtkHxm/kI6EaRkkqhw7MRWLdn/J Bj86CENDspcDnHhs+nC3BzA03MJu7pFo3e/V187oyU7hvzzX08oDWtYIcltYN0GEdHxx iQEA== MIME-Version: 1.0 X-Received: by 10.180.94.162 with SMTP id dd2mr17669101wib.38.1384359415252; Wed, 13 Nov 2013 08:16:55 -0800 (PST) Received: by 10.227.27.73 with HTTP; Wed, 13 Nov 2013 08:16:55 -0800 (PST) In-Reply-To: References: <20131111121027.GA31723@sources.org> Date: Wed, 13 Nov 2013 08:16:55 -0800 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d04462ea830335d04eb114b65 Cc: "Wiley, Glen" , perpass , Stephane Bortzmeyer , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:17:04 -0000 --f46d04462ea830335d04eb114b65 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson wrote: > On 12 November 2013 08:12, Ted Hardie wrote: > > The DNS query tells you which resource was the target even if the HTTP > flow > > was protected by TLS. > > In practice, since server name indication is sent in the clear, even > this doesn't help. Unless you are running a browser from 2001, you > are sending SNI. > > That said, SNI may be pushed into an encrypted payload in TLS 1.3. > The challenge there is that servers often use SNI to select what > credentials to offer. > True; I'd been thinking about the blogspot-style use cases where you get an initial negotiation at one name followed by a large set of alternate names, but that's not the common case. The VPN case is still an issue, though. Having read through the rest of the thread, pushing SNI into the encrypted portion of TLS in 1.3 seems like a good thing to do. Ted --f46d04462ea830335d04eb114b65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 12 November 2013 08:12,= Ted Hardie <ted.ietf@gmail.com> wrote:
> The DNS query tells you which resource was the target even if the HTTP= flow
> was protected by TLS.

In practice, since server name indication is sent in the clear, even<= br> this doesn't help. =A0Unless you are running a browser from 2001, you are sending SNI.

That said, SNI may be pushed into an encrypted payload in TLS 1.3.
The challenge there is that servers often use SNI to select what
credentials to offer.

True; I'd been = thinking about the blogspot-style use cases where you get an initial negoti= ation at one name followed by a large set of alternate names, but that'= s not the common case.=A0 The VPN case is still an issue, though.

Having read through the rest of the th= read, pushing SNI into the encrypted portion of TLS in 1.3 seems like a goo= d thing to do.

Ted
--f46d04462ea830335d04eb114b65-- From gwiley@verisign.com Wed Nov 13 08:21:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D58621E8143 for ; Wed, 13 Nov 2013 08:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgzPHn785H3P for ; Wed, 13 Nov 2013 08:21:41 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23721E80A9 for ; Wed, 13 Nov 2013 08:21:38 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUoOnDCqnqJXiUrL2lcvU31hBceG+MU6u@postini.com; Wed, 13 Nov 2013 08:21:39 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rADGLSQ8008854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 11:21:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Nov 2013 11:21:26 -0500 From: "Wiley, Glen" To: Ted Hardie , Martin Thomson Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiAgAGvn4CAAJf+gIAA+6eA//+tbwA= Date: Wed, 13 Nov 2013 16:21:26 +0000 Message-ID: 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.8.130913 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CEA910D426418gwileyverisigncom_" MIME-Version: 1.0 Cc: perpass , Stephane Bortzmeyer , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:21:48 -0000 --_000_CEA910D426418gwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I certainly support the idea of confidential DNS, I wonder whether it= is a good idea to impose the overhead involved in TLS on the high volume n= ame servers? -- Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. From: Ted Hardie > Date: Wednesday, November 13, 2013 11:16 AM To: Martin Thomson > Cc: "Wiley, Glen" >, perpas= s >, Stephane Bortzmeyer >, Andy Wilson >, Stephen Farrell > Subject: Re: [perpass] DNS confidentiality On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson > wrote: On 12 November 2013 08:12, Ted Hardie > wrote: > The DNS query tells you which resource was the target even if the HTTP fl= ow > was protected by TLS. In practice, since server name indication is sent in the clear, even this doesn't help. Unless you are running a browser from 2001, you are sending SNI. That said, SNI may be pushed into an encrypted payload in TLS 1.3. The challenge there is that servers often use SNI to select what credentials to offer. True; I'd been thinking about the blogspot-style use cases where you get an= initial negotiation at one name followed by a large set of alternate names= , but that's not the common case. The VPN case is still an issue, though. Having read through the rest of the thread, pushing SNI into the encrypted = portion of TLS in 1.3 seems like a good thing to do. Ted --_000_CEA910D426418gwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4173294BFFCDC84CA1D5970C6219FEBA@verisign.com> Content-Transfer-Encoding: quoted-printable
While I certainly support the idea of confidential DNS, I wonder wheth= er it is a good idea to impose the overhead involved in TLS on the high vol= ume name servers?  
-- 
Glen Wiley
KK4SFV
Sr. Engineer
The Hive, Verisign, Inc.

From: Ted Hardie <ted.ietf@gmail.com>
Date: Wednesday, November 13, 2013 = 11:16 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Wiley, Glen" <gwiley@verisign.com>, perpass &l= t;perpass@ietf.org>, Stephane Bo= rtzmeyer <bortzmeyer@nic.fr>= , Andy Wilson <andrewgwilson@g= mail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [perpass] DNS confiden= tiality

On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 12 November 2013 08:12, Ted Hardie <ted.ietf@gmail.com> wrote:
> The DNS query tells you which resource was the target even if the HTTP= flow
> was protected by TLS.

In practice, since server name indication is sent in the clear, even
this doesn't help.  Unless you are running a browser from 2001, you are sending SNI.

That said, SNI may be pushed into an encrypted payload in TLS 1.3.
The challenge there is that servers often use SNI to select what
credentials to offer.

True; I'd been thinking about the blogspot-style= use cases where you get an initial negotiation at one name followed by a l= arge set of alternate names, but that's not the common case.  The VPN = case is still an issue, though.

Having read through the rest of the thread, push= ing SNI into the encrypted portion of TLS in 1.3 seems like a good thing to= do.

Ted
--_000_CEA910D426418gwileyverisigncom_-- From iain.learmonth.09@aberdeen.ac.uk Wed Nov 13 08:30:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8034721F9D5E for ; Wed, 13 Nov 2013 08:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqstz3HmXWK9 for ; Wed, 13 Nov 2013 08:30:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5B21F9CA4 for ; Wed, 13 Nov 2013 08:30:13 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 13 Nov 2013 16:30:12 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Wed, 13 Nov 2013 16:30:12 +0000 From: "Learmonth, Iain Ross" To: Ted Lemon Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO38EMi+m3JSb4uUeoAPlhMDxny5ohxQeAgAABGtOAAAjYgIABJII9gAAbNYCAABYVyIAAGlmAgAAAKUeAABeWgIAAAlbs Date: Wed, 13 Nov 2013 16:30:11 +0000 Message-ID: <6edb5f581f134c919b77b1ff53178a2e@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <749160fb143d49a88e70324c9c4e1bee@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <44F367BF-0082-4A96-A275-BA2F5705A633@fugue.com> In-Reply-To: <44F367BF-0082-4A96-A275-BA2F5705A633@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:2c90:8397:34e2:dae8] x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(189002)(199002)(377454003)(24454002)(87936001)(2656002)(51856001)(33646001)(69226001)(76786001)(76482001)(53806001)(76796001)(54356001)(59766001)(77982001)(551544002)(77096001)(74876001)(46102001)(87266001)(85306002)(54316002)(56816003)(56776001)(74706001)(49866001)(74316001)(65816001)(80022001)(74502001)(47736001)(74482001)(81816001)(81342001)(47446002)(50986001)(63696002)(47976001)(4396001)(81542001)(81686001)(74366001)(79102001)(83072001)(74662001)(19580405001)(83322001)(31966008)(19580395003)(80976001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB153; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:2c90:8397:34e2:dae8; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:30:19 -0000 > What would be ideal would be for the site to provide a site ID that can b= e validated using existing PKI.=0A= =0A= combined with=0A= =0A= > one master key per site=0A= =0A= does sound good. This is going to require modifications (an extension) to T= LS though, which is possible but does mean developing new technology, not j= ust new ways of leveraging existing ones. I'm not against this, just pointi= ng it out.=0A= =0A= > single-purpose key server=0A= =0A= How would this key server work? Looking at X.509 key servers, they only eve= r seem to store the public key, which the website would already have anyway= . I know with gpg-agent you can forward that to remote servers, but I've ne= ver seen anyone pulling it from somewhere.=0A= =0A= A privacy bonus: if you have a key for each site you have an account on, yo= u know where you have accounts and don't have old inaccessible accounts lea= king information (unless you lose the keys).=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: Ted Lemon =0A= Sent: 13 November 2013 16:12=0A= To: Learmonth, Iain Ross=0A= Subject: Re: [perpass] Stopping password sniffing=0A= =0A= On Nov 13, 2013, at 9:56 AM, Learmonth, Iain Ross wrote:=0A= > I was about to say signing client keys with a master key was a good idea.= It would remove the need for a cloud sync as once set up, the browsers wou= ld inherit the access from the master key without the need for synchronizat= ion.=0A= >=0A= > Then, yes, re-use would allow for tracking across websites. So maybe not = such a great idea.=0A= =0A= Yeah, that's a flaw.=0A= =0A= > Maybe the compromise is not a cert per service, but a cert per identity (= in the loosest possible sense of the word). Maybe your social media account= s where you are you are under one, and your reddit and slashdot accounts un= der another, etc.=0A= =0A= There's no particular reason not to have one key per site, other than that = it's hard to define what "site" means. This could generalize to one maste= r key per site, so you preserve privacy but still get the nice properties o= f a master key versus a cloud keychain. Of course now you need to generat= e keys more frequently, so that places some new pressure on the key server.= =0A= =0A= > With a smartcard, this is as easy as plugging the smartcard into the devi= ce you're using, but - another thought - would probably mean requiring mult= iple smartcards as I am logged into my email on about 4 different devices a= t a time.=0A= =0A= I don't think the smartcard works, because your devices may not have a conv= enient way to connect to it other than over the network. And in that case= , why not just have a single-purpose key server?=0A= =0A= > I'm not sure with TLS client authentication if it just tries all the pers= onal keys it has or if the server advertises which keys would be accepted. = I'm guessing it'll be the former so even if there is one key per service, t= he other certs would still become known to the server when authentication u= sing them is attempted?=0A= =0A= What would be ideal would be for the site to provide a site ID that can be = validated using existing PKI. Once the site ID has been validated, you lo= ok in your key cache for an identity that is associated with that site ID. = If you find one, you use the cert to log in. If you don't fine one, you= don't have an account on that site.=0A= =0A= From trammell@tik.ee.ethz.ch Wed Nov 13 08:54:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA511E8119 for ; Wed, 13 Nov 2013 08:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL7G9BpIf1MC for ; Wed, 13 Nov 2013 08:54:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC521F9AE7 for ; Wed, 13 Nov 2013 08:54:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 46AD9D930D for ; Wed, 13 Nov 2013 17:54:13 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id grNBcL7ctk3u for ; Wed, 13 Nov 2013 17:54:13 +0100 (MET) Received: from commodity-noc-40.sc13.org (commodity-noc-40.sc13.org [140.221.248.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C47DFD930C for ; Wed, 13 Nov 2013 17:54:12 +0100 (MET) Message-ID: <5283AEB2.5010605@tik.ee.ethz.ch> Date: Wed, 13 Nov 2013 09:54:10 -0700 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: perpass References: <20131113164845.30542.54801.idtracker@ietfa.amsl.com> In-Reply-To: <20131113164845.30542.54801.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFD0F1B8195DD1A10CB4841B4" Subject: [perpass] Fwd: New Version Notification for draft-trammell-perpass-ppa-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:54:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD0F1B8195DD1A10CB4841B4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Greetings, all, We've posted a new revision of the threat model draft, incorporating commentary from the list and the meeting in Vancouver, pulling sections on traffic analysis from draft-huitema-, and otherwise largely completing those sections missing from the -00 revision. Some open issues remain, and IMO the document still has room for improvement. Please read and comment to the list. Best regards, Brian -------- Original Message -------- Subject: New Version Notification for draft-trammell-perpass-ppa-01.txt Date: Wed, 13 Nov 2013 08:48:45 -0800 From: internet-drafts@ietf.org To: Daniel Borkmann , Brian Trammell , Christian Huitema A new version of I-D, draft-trammell-perpass-ppa-01.txt has been successfully submitted by Brian Trammell and posted to the IETF repository. Filename: draft-trammell-perpass-ppa Revision: 01 Title: A Threat Model for Pervasive Passive Surveillance Creation date: 2013-11-13 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-trammell-perpass-ppa-01.txt Status: http://datatracker.ietf.org/doc/draft-trammell-perpass-p= pa Htmlized: http://tools.ietf.org/html/draft-trammell-perpass-ppa-01= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-perpass-ppa-01 Abstract: This document elaborates a threat model for pervasive surveillance. We assume an adversary with an interest in indiscriminate eavesdropping that can passively observe network traffic at every layer at every point in the network between the endpoints. It is intended to demonstrate to protocol designers and implementors the observability and inferability of information and metainformation transported over their respective protocols, to assist in the evaluation of the performance of these protocols and the effectiveness of their protection mechanisms under pervasive passive surveillance. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------enigFD0F1B8195DD1A10CB4841B4 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJSg66yAAoJENt3nsOmbNJccK4IAMgoiSkBqNPmCDDw+lUesAJt qKTjH3pWpIDKgmTmBj/5DRMyt3r4Hh/FS0YkveSkIevIzLZk29cmgfH94er9WnPR dOmdXEu5i7ddA9xLsATweSRV2/DhXYedOIVlM+Env6pmRICfRWVjYZsxoAEGpYYJ p+v4fRXhuRzi4ph2Pym4/Q9hSouBUlefwmONRoCRb9E8Qrttcfsyx9VxvZJKtqPe r7+brzRcZKlEDAdt2TxsyzuH3CpkYzogFmIK6XVA+XSnTymC1dPNjHNti5CotltO b4QP258ImZRd7/ny9f9bliSGSha+/hlPHTARmM1yqrDpGsAFS3+3s93Mcv4vlLI= =Y6ZD -----END PGP SIGNATURE----- --------------enigFD0F1B8195DD1A10CB4841B4-- From hallam@gmail.com Wed Nov 13 09:56:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCD221E8096 for ; Wed, 13 Nov 2013 09:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3AkGp0ZCEgl for ; Wed, 13 Nov 2013 09:56:32 -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 CD3E621E80A8 for ; Wed, 13 Nov 2013 09:56:31 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u14so641981lbd.39 for ; Wed, 13 Nov 2013 09:56:28 -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=o83MWfHjCzR/lPKCMlgR7SAFut2W2bEWOQgHpoNf5u8=; b=KDpYkkneLMg+7s+fc/bRng+tPx/RIKr9XwB5a+1/GN+yXn2IYrY9YHJzc4Abs8YTUp ol9IDRbtXsWIX93PE3SxAbpa3xeJKI2UvHZNQHkvE8K36v8Uwl1+0b3bzgmlf/tSwQy0 FtBH1LCIHfyGyHb4mLn1N34oUSuo1MxaX+1azGmIhg45xd9LFNC18dir094Vwq4Nuhm8 smn5ddxCu2nWbQfM+05nEjNiG352h3MhvqqVobrkKcup2Jdp9RiHu4Mn8GVzbqel9/Mr dAcclHpCpSLjqRlExciAiGfc4oomCJWV1t6c/kAR5ER0vMEz5usliqVSbocvpoE8a9wY TsIw== MIME-Version: 1.0 X-Received: by 10.112.210.197 with SMTP id mw5mr2038729lbc.42.1384365388103; Wed, 13 Nov 2013 09:56:28 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 13 Nov 2013 09:56:28 -0800 (PST) In-Reply-To: <52838F74.6030907@cs.tcd.ie> References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> <52838F74.6030907@cs.tcd.ie> Date: Wed, 13 Nov 2013 12:56:28 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c3c7dc3285c704eb12afbb Cc: perpass , Stephen Kent Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 17:56:35 -0000 --001a11c3c7dc3285c704eb12afbb Content-Type: text/plain; charset=ISO-8859-1 I think I have something like 12 Internet drafts at the moment, at least six of which are on these issues. I don't write a draft on every proposal and far more people read the emails than the drafts. Often the idea changes substantially during list discussions. Since many of my drafts are now written by a computer, there is not a great deal more innovative content in the drafts than the on list discussion in any case. On Wed, Nov 13, 2013 at 9:40 AM, Stephen Farrell wrote: > > Hi Steve, > > On 11/13/2013 02:34 PM, Stephen Kent wrote: > > Stephen, > > > > I agree that mitigation is the preferred term. > > > > I am not so comfortable with using this list to incrementally develop > > new proposals via e-mail exchanges, instead of requiring proposals to be > > prepared as I-Ds. There are enough folks on the list with IETF I-D prep > > experience to assist anyone who needs help. > > > > The rigor of writing a document usually helps refine one's ideas > > (and spares others from half-baked notions :-) ). > > I agree, which is why I included this bit: > > "Those with proposals are encouraged to embody them in > detailed internet-draft specifications, rather than > relying solely on email messages." > > I'm quite happy to make that a bit stronger if someone > has words to offer, but we also don't want to push away > all mail discussion of course - I think it should be > fine if there's an initial discussion on a topic to see > if its worth pursuing, so long as that's fairly quickly > turned into an I-D and we don't get the "design via > email exchanges" thing taking up everyone's cycles. > > S. > > > > > > > > Steve > > _______________________________________________ > > 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 > -- Website: http://hallambaker.com/ --001a11c3c7dc3285c704eb12afbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think I have something like 12 Internet drafts at the mo= ment, at least six of which are on these issues.

I don&#= 39;t write a draft on every proposal and far more people read the emails th= an the drafts. Often the idea changes substantially during list discussions= .

Since many of my drafts are now written by a computer, = there is not a great deal more innovative content in the drafts than the on= list discussion in any case.



On Wed, Nov 13, 2013 at 9:40 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Steve,

On 11/13/2013 02:34 PM, Stephen Kent wrote:
> Stephen,
>
> I agree that mitigation is the preferred term.
>
> I am not so comfortable with using this list to incrementally develop<= br> > new proposals via e-mail exchanges, instead of requiring proposals to = be
> prepared as I-Ds. There are enough folks on the list with IETF I-D pre= p
> experience to assist anyone who needs help.
>
> The rigor of writing a document usually helps refine one's ideas > (and spares others from half-baked notions :-) ).

I agree, which is why I included this bit:

"Those with proposals are encouraged to embody them in
detailed internet-draft specifications, rather than
relying solely on email messages."

I'm quite happy to make that a bit stronger if someone
has words to offer, but we also don't want to push away
all mail discussion of course - I think it should be
fine if there's an initial discussion on a topic to see
if its worth pursuing, so long as that's fairly quickly
turned into an I-D and we don't get the "design via
email exchanges" thing taking up everyone's cycles.

S.




>
> Steve
> _______________________________________________
> 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



--
= Website: http://hallambaker.com/
--001a11c3c7dc3285c704eb12afbb-- From mellon@fugue.com Wed Nov 13 10:06:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC53E11E81A0 for ; Wed, 13 Nov 2013 10:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WohKsfYfWcP for ; Wed, 13 Nov 2013 10:06:19 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9E11E813A for ; Wed, 13 Nov 2013 10:06:19 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id B2D69238081B; Wed, 13 Nov 2013 13:06:15 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <6edb5f581f134c919b77b1ff53178a2e@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Wed, 13 Nov 2013 13:06:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <749160fb143d49a88e70324c9c4e1bee@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <44F367BF-0082-4A96-A275-BA2F5705A633@fugue.com> <6edb5f581f134c919b77b1ff53178a2e@DB3PR01MB153.eurprd01.prod.exchangelabs.com> To: "Learmonth, Iain Ross" X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:06:34 -0000 On Nov 13, 2013, at 11:30 AM, Learmonth, Iain Ross = wrote: > How would this key server work? Looking at X.509 key servers, they = only ever seem to store the public key, which the website would already = have anyway. I know with gpg-agent you can forward that to remote = servers, but I've never seen anyone pulling it from somewhere. The key server would have a collection of public/private key pairs. = When you establish an account at a new site, your browser contacts the = server and asks it to generate a new master key pair for the site. The = browser generates a per-site key pair and sends the public half to the = server; the server hands back a cert signing that key with the new = per-site master key it generated. Your other devices are notified = asynchronously of the new relationship, and generate their own keys, = which are signed with the same per-site master key. No secret key ever = crosses the network. > A privacy bonus: if you have a key for each site you have an account = on, you know where you have accounts and don't have old inaccessible = accounts leaking information (unless you lose the keys). Yup. And if you lose your key server, the usual strategies for = recovering your password would still work. And your key server can do = live certificate revocation. So if someone manages to associate a = device with your key server that you didn't intend, you can see it on = the list of devices and revoke all its keys. Which means that the = compromise of the key store on one of your devices need not require that = you re-key all your accounts=97only the compromise of the server would = require that. Of course, live certificate revocation loses you the privacy win of = using separate keys, since the IP address would be the same for all = queries, so maybe that part isn't such a good idea. A distributed = revocation service would prevent that, but it probably wouldn't be = possible to notice keys quite as easily. And of course if all your HTTP queries come from the same IP address, = sites that communicate can do correlation that way anyway, which means = that the per-site master key isn't that useful without a scheme for = obfuscating IP addresses. Sigh. Privacy is hard.= From dean.willis@softarmor.com Wed Nov 13 10:24:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1757221E80BB for ; Wed, 13 Nov 2013 10:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auNOdoZJvNmg for ; Wed, 13 Nov 2013 10:24:06 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A00D11E80FA for ; Wed, 13 Nov 2013 10:24:06 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id g10so562446vbg.34 for ; Wed, 13 Nov 2013 10:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mMOrT01I7iTkuwY06+bzkXmDWc1v6WP679vv14KNFoM=; b=V+VUD8t3jwguyWp+45VrTw7MRzHKb0QP+49g3UYVP1I/ttQC8b/MqSaykpHmwphtfA qtNv5yIZlbWSF6pdS91pWNy3VFlf6aDz+ixMUH9hqSopuJ0XeDM6IITcIapF5jRnCBXz Dw8FiWbZh61xZwEf3tKopsEfkV2VpD3RihZJ4= 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=mMOrT01I7iTkuwY06+bzkXmDWc1v6WP679vv14KNFoM=; b=I+EEt13ZLRQt80wHTKiCaQLCi8CIjTtbOtvYiZ3zCzZ0cHKiUCdYW4lCU9oCdurtlO Q/HiM9aYmMXJLCe9VedqAOyhxMJgum1OLNv3rKsMxkCmvGKudwdcLq2y+k8WvGXL9SuC uSa8Z22X8lmM+DmqOVTV4TA16XG9c+1O7duFgC8NNQwPQfAudiN1G6ivIb1Q/ZIgp5Sc sL6f23ja4Zy086DerL+PyO2TE8JpOPUwxj9stWxu7uov6XQl/KeoFe7KgkkbgNolI+DD V3e3VZjNkZn9B3N51gNUYG4PMiprzN+JgXmiRVW1xLgP//l3Sj4Gpy5eYOC71BIObKHp aQIw== X-Gm-Message-State: ALoCoQmxq3kG7obU9ty4gUw4fcbNFTmo3XtR96+8WSL/RRBuwZazEG1VqrE5xZ2zwL4nbhZiSk8F MIME-Version: 1.0 X-Received: by 10.220.11.7 with SMTP id r7mr35582274vcr.12.1384367045195; Wed, 13 Nov 2013 10:24:05 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 13 Nov 2013 10:24:05 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 13 Nov 2013 10:24:05 -0800 (PST) In-Reply-To: <52823817.409@ping.de> References: <52821AE5.7020605@cs.tcd.ie> <52823817.409@ping.de> Date: Wed, 13 Nov 2013 12:24:05 -0600 Message-ID: From: Dean Willis To: Andreas Kuckartz Content-Type: multipart/alternative; boundary=001a11c3e47cf8095f04eb131163 Cc: perpass , Stephen Farrell Subject: Re: [perpass] Issue tracker Re: orphan thread on gmt_unix_time - any takers to work this with the TLS wg? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:24:07 -0000 --001a11c3e47cf8095f04eb131163 Content-Type: text/plain; charset=ISO-8859-1 I believe the tools team has made a web-based issue tracker available to each WG. Are we going to keep perpass going long enough to justify using an issue tracker? On Nov 12, 2013 8:16 AM, "Andreas Kuckartz" wrote: > Stephen Farrell: > > Way back in the mists of September there was a thread [1] > > on this that seemed to have broad agreement that this was > > a useful and quite doable change to TLS but I don't think > > we currently have a clear owner to push it along in the > > TLS WG. If everyone thinks someone else will get around to > > doing this, it won't happen. > > > > Any takers? > > Does the IETF have an issue tracking system for such issues (besides > mailing lists) ? > > Cheers, > Andreas > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --001a11c3e47cf8095f04eb131163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I believe the tools team has made a web-based issue tracker = available to each WG. Are we going to keep perpass going long enough to jus= tify using an issue tracker?

On Nov 12, 2013 8:16 AM, "Andreas Kuckartz&= quot; <a.kuckartz@ping.de> = wrote:
Stephen Farrell:
> Way back in the mists of September there was a thread [1]
> on this that seemed to have broad agreement that this was
> a useful and quite doable change to TLS but I don't think
> we currently have a clear owner to push it along in the
> TLS WG. If everyone thinks someone else will get around to
> doing this, it won't happen.
>
> Any takers?

Does the IETF have an issue tracking system for such issues (besides
mailing lists) ?

Cheers,
Andreas
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--001a11c3e47cf8095f04eb131163-- From dean.willis@softarmor.com Wed Nov 13 10:39:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2411E8104 for ; Wed, 13 Nov 2013 10:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rIETnru2C1g for ; Wed, 13 Nov 2013 10:39:35 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B17EE11E813A for ; Wed, 13 Nov 2013 10:39:27 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id if17so590628vcb.33 for ; Wed, 13 Nov 2013 10:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qnq1WmgKPACrElu/8LkK4Nk3u4b2d+/gfb+QyULCUZ0=; b=MuWl9gq2MvIP1XFFxJoERCXw1ZokpwMEq4dFj+WyCPJrxmzUhQkoRVWZYQciblDjg/ AZ0iffQ6KypgFKLmcA/RarDy66POlj0SbZ4Ic0495HP6zQQusNPpPJMz8JnqvwRexbBJ RLNOib/mlu2l5SLoelqXHLy/E4yZXCt1nN0UM= 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=qnq1WmgKPACrElu/8LkK4Nk3u4b2d+/gfb+QyULCUZ0=; b=ZFynp+BR7Zb8oBX39LJnFnFIL/Ea3VRREORF0mPnf2efXtqTcnyMh0a+T6g20BsIRl wRlm9z0msf8iexibU7tJCV4UwQS6ZXKXWkeBZSCyxuoCorX6w5rFf1IiCxeqVjR3nqPn 3fsjU+lXvnmj7jgL7ijKVKSsD0E8BHrHHXLh1433RTX+AIjb7kXDB1lecGIh52Rlgkt9 JHsaysWGD0hvRftMRZkuxmxh9UQNbHLb0UPM/+sMG6YkBI2Bj9cLEHohznjG/QAbC6u6 MWfgX8ZzXs7IwiSd8WlyWJYd0ffEeBEv/JVIbetHK19w88rV2QLvbQxOXtDcL0zlnT7K 0TnA== X-Gm-Message-State: ALoCoQkCV0vskTUCkApjw4bYfuLSdyK3En/yT5oDbi8NKulaqnpw2sx2FXNAkil1sJ5slwhNeJAY MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr35439356vcb.5.1384367967230; Wed, 13 Nov 2013 10:39:27 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 13 Nov 2013 10:39:27 -0800 (PST) Received: by 10.58.173.72 with HTTP; Wed, 13 Nov 2013 10:39:27 -0800 (PST) In-Reply-To: <52812BBC.1050508@gmail.com> References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> Date: Wed, 13 Nov 2013 12:39:27 -0600 Message-ID: From: Dean Willis To: Tony Rutkowski Content-Type: multipart/alternative; boundary=001a1133158eecf65004eb134804 Cc: perpass , Stephen Farrell Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:39:36 -0000 --001a1133158eecf65004eb134804 Content-Type: text/plain; charset=ISO-8859-1 On Nov 11, 2013 1:11 PM, "Tony Rutkowski" wrote: > What if one believes that mitigation is not > appropriate, or that it pervasive monitoring > should be enhanced? Those apostates should > go somewhere else? > > Guess you don't want discuss improving the > protocols to enhance DPI or data retention. :-) I think you've got it! But it might be nice to have another group that is working "red team" enhancements to DPI so we know what and who to watch out for... --001a1133158eecf65004eb134804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 11, 2013 1:11 PM, "Tony Rutkowski" <rutkowski.tony@gmail.com> wrote:
> What if one believes that mitigation is not
> appropriate, or that it pervasive monitoring
> should be enhanced? =A0Those apostates should
> go somewhere else?
>
> Guess you don't want discuss improving the
> protocols to enhance DPI or data retention. :-)

I think you've got it!

But it might be nice to have another group that is working &= quot;red team" enhancements to DPI so we know what and who to watch ou= t for...

--001a1133158eecf65004eb134804-- From hallam@gmail.com Wed Nov 13 12:18:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72021E80B2 for ; Wed, 13 Nov 2013 12:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5slRhsKhQdGY for ; Wed, 13 Nov 2013 12:18:43 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C711E8107 for ; Wed, 13 Nov 2013 12:18:43 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so819421lab.29 for ; Wed, 13 Nov 2013 12:18:35 -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=wfSRWpXTCkOgzNZwAUhpobagCw0eBSAMHJQIQV2Tt20=; b=rXJmgONgWQEdjBOVh8yl0TUrY6ovD5CLJ6v+B36rHvW9p15EjX5nOtwX3jJr/ndTX/ I4yXrR6eh28wK8Zy6tuDiHqibB1ffG/ARXZLpq5flYPlvU0R7FZrQmklhSC5iHrFUv+m 5p9StlCYIp9fGtShnel8SmtvuHX3NycgLHJ8j8K/iwwi7oigRHZuJxjrGceCChIRg7wx 2O7uf9mEEeFlboc1cwP5GZ6PsNojlsRcBNfMZ7yrBYXwrsNw4lt6nX2E9vMOlE3BKFCi Qr7Pzr3n9W1q8z54zXfIrOzQ342L2EkFHbDzoSHOFmXk0fl8amnFVWGQ5wk+peEvYlUM E0fw== MIME-Version: 1.0 X-Received: by 10.152.115.230 with SMTP id jr6mr177608lab.45.1384373915709; Wed, 13 Nov 2013 12:18:35 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 13 Nov 2013 12:18:35 -0800 (PST) In-Reply-To: References: <68a47e25e4e0476796de2a6c990a9416@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <0A23EF00-0C3F-4C0B-94B2-0FB416157C9D@isoc.org> <44193667d6c94d43808e85eaa5a254e0@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <34454651a7684b91861bcbc7783225b2@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <749160fb143d49a88e70324c9c4e1bee@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <44F367BF-0082-4A96-A275-BA2F5705A633@fugue.com> <6edb5f581f134c919b77b1ff53178a2e@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Wed, 13 Nov 2013 15:18:35 -0500 Message-ID: From: Phillip Hallam-Baker To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c367427b785d04eb14ab8c Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:18:44 -0000 --001a11c367427b785d04eb14ab8c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 13, 2013 at 1:06 PM, Ted Lemon wrote: > On Nov 13, 2013, at 11:30 AM, Learmonth, Iain Ross < > iain.learmonth.09@aberdeen.ac.uk> wrote: > > How would this key server work? Looking at X.509 key servers, they only > ever seem to store the public key, which the website would already have > anyway. I know with gpg-agent you can forward that to remote servers, but > I've never seen anyone pulling it from somewhere. > > The key server would have a collection of public/private key pairs. When > you establish an account at a new site, your browser contacts the server > and asks it to generate a new master key pair for the site. The browser > generates a per-site key pair and sends the public half to the server; the > server hands back a cert signing that key with the new per-site master key > it generated. Your other devices are notified asynchronously of the new > relationship, and generate their own keys, which are signed with the same > per-site master key. No secret key ever crosses the network. That is essentially the CardSpace model but taking account of roaming needs. My view is that either you should use one public keypair per device or if the authentication keys are going to be per site then you should use a strong (non user chosen) symmetric key and a proof of possession scheme. There is really no value to a public key scheme for authentication if there are only two parties to the conversation and no need for non repudiation. -- Website: http://hallambaker.com/ --001a11c367427b785d04eb14ab8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 13, 2013 at 1:06 PM, Ted Lemon <mellon@fugue.com>= ; wrote:
On Nov 13, 2013, at 11:30 = AM, Learmonth, Iain Ross <iain.learmonth.09@aberdeen.ac.uk> wrote:
> How would this key server work? Looking at X.509 key servers, they onl= y ever seem to store the public key, which the website would already have a= nyway. I know with gpg-agent you can forward that to remote servers, but I&= #39;ve never seen anyone pulling it from somewhere.

The key server would have a collection of public/private key pairs. = =A0 When you establish an account at a new site, your browser contacts the = server and asks it to generate a new master key pair for the site. =A0 The = browser generates a per-site key pair and sends the public half to the serv= er; the server hands back a cert signing that key with the new per-site mas= ter key it generated. =A0 Your other devices are notified asynchronously of= the new relationship, and generate their own keys, which are signed with t= he same per-site master key. =A0 No secret key ever crosses the network.

That is essentially the CardSpace model but taking acco= unt of roaming needs.

My view is that either you s= hould use one public keypair per device or if the authentication keys are g= oing to be per site then you should use a strong (non user chosen) symmetri= c key and a proof of possession scheme.

There is really no value to a public key scheme for aut= hentication if there are only two parties to the conversation and no need f= or non repudiation.=A0


--
W= ebsite: http://hallambaker.com/
--001a11c367427b785d04eb14ab8c-- From bortzmeyer@nic.fr Wed Nov 13 13:33:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FFF21E811A for ; Wed, 13 Nov 2013 13:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm30V-zCPcbt for ; Wed, 13 Nov 2013 13:33:07 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1221E80DB for ; Wed, 13 Nov 2013 13:33:07 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C0FCD3B719; Wed, 13 Nov 2013 21:33:06 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id 2C386190B49; Wed, 13 Nov 2013 22:28:17 +0100 (CET) Date: Wed, 13 Nov 2013 22:28:17 +0100 From: Stephane Bortzmeyer To: "Wiley, Glen" Message-ID: <20131113212817.GB8596@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.2 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:33:12 -0000 On Wed, Nov 13, 2013 at 04:21:26PM +0000, Wiley, Glen wrote a message of 150 lines which said: > While I certainly support the idea of confidential DNS, I wonder > whether it is a good idea to impose the overhead involved in TLS on > the high volume name servers? First, it may not be TLS. I mention dnscrypt and there is also at least one (not published yet) proposal to encrypt DNS without TLS (or DTLS). Second, I do not think we want to impose anything ("MUST encrypt all queries and MUST accept encrypted queries"...) My vision is that some servers will adopt encryption and not all. The resolvers will have to decide (local policy) what to do if the remote server does not support encryption. This approach seems the only realistic one, for incremental deployment. An interesting consequence is that the end-user will have trouble knowing if his queries are encrypted or not (specially if his resolver uses a forwarded). From stephen.farrell@cs.tcd.ie Wed Nov 13 14:05:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8512821E811A; Wed, 13 Nov 2013 14:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awvabs-ic2w7; Wed, 13 Nov 2013 14:05:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3B21E8104; Wed, 13 Nov 2013 14:05:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F171BBE80; Wed, 13 Nov 2013 22: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 nFovoWoxQeEh; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.61.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14096BE7D; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Message-ID: <5283F7A2.5040106@cs.tcd.ie> Date: Wed, 13 Nov 2013 22:05:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "\"saag@ietf.org\" per" , perpass , "cfrg@irtf.org" , "secdir@ietf.org" References: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> In-Reply-To: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: [perpass] Fwd: New Non-WG Mailing List: dsfjdssdfsd X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:05:34 -0000 Hi, There was some discussion in Vancouver at the secdir lunch and the perpass BoF about better randomness recommendations and we agreed to set up a new list. Details for that are below. Many thanks to Dan Harkins and Paul Hoffman for agreeing to moderate this. I think Don Eastlake is also working on an update to RFC 4086 so this could be a useful place to talk about that. I'm hoping that one of them will kick off the discussion in a few days, once folks have had a chance to sign up. Regards, Stephen. -------- Original Message -------- Subject: New Non-WG Mailing List: dsfjdssdfsd Date: Wed, 13 Nov 2013 13:58:22 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: dsfjdssdfsd@ietf.org, dharkins@lounge.org, paul.hoffman@vpnc.org A new IETF non-working group email list has been created. List address: dsfjdssdfsd@ietf.org Archive: http://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/dsfjdssdfsd Purpose: The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086. For additional information, please contact the list administrators. From kent@bbn.com Wed Nov 13 14:37:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AFB21E808A for ; Wed, 13 Nov 2013 14:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttkMSVBbYz+y for ; Wed, 13 Nov 2013 14:37:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6E11E80E6 for ; Wed, 13 Nov 2013 14:37:24 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:37957 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vgj3o-000KgO-RL; Wed, 13 Nov 2013 17:37:20 -0500 Message-ID: <5283FF21.7060803@bbn.com> Date: Wed, 13 Nov 2013 17:37:21 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Farrell , perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> <52838F74.6030907@cs.tcd.ie> In-Reply-To: <52838F74.6030907@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:37:30 -0000 Stephen, ... > I agree, which is why I included this bit: > > "Those with proposals are encouraged to embody them in > detailed internet-draft specifications, rather than > relying solely on email messages." > > I'm quite happy to make that a bit stronger if someone > has words to offer, but we also don't want to push away > all mail discussion of course - I think it should be > fine if there's an initial discussion on a topic to see > if its worth pursuing, so long as that's fairly quickly > turned into an I-D and we don't get the "design via > email exchanges" thing taking up everyone's cycles. we're in agreement. so long as you moderate the list to maintain the desired balance, I think it will be fine. Steve From stephen.farrell@cs.tcd.ie Wed Nov 13 15:22:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B425E11E810C for ; Wed, 13 Nov 2013 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohZ3e9AAaKy0 for ; Wed, 13 Nov 2013 15:22:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C434711E810B for ; Wed, 13 Nov 2013 15:22:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6A2FBE80; Wed, 13 Nov 2013 23:22:49 +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 O2EPPUARoT2u; Wed, 13 Nov 2013 23:22:48 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.61.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A9372BE7C; Wed, 13 Nov 2013 23:22:48 +0000 (GMT) Message-ID: <528409C8.4050102@cs.tcd.ie> Date: Wed, 13 Nov 2013 23:22:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Kent , perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> <52838F74.6030907@cs.tcd.ie> <5283FF21.7060803@bbn.com> In-Reply-To: <5283FF21.7060803@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:22:56 -0000 On 11/13/2013 10:37 PM, Stephen Kent wrote: >> > we're in agreement. so long as you moderate the list to maintain > the desired balance, I think it will be fine. Cool - and speaking of which, anyone else who's willing to volunteer to help moderate this list please drop a mail to Sean and I. And if someone thinks some thread is out of control or has other comments for the moderators, please do send those on. I'll update the list description text as per this discussion tomorrow. Thanks, S. From stephen.farrell@cs.tcd.ie Thu Nov 14 03:07:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FFF21E80B5 for ; Thu, 14 Nov 2013 03:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.762 X-Spam-Level: X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yap8L26oAVUH for ; Thu, 14 Nov 2013 03:07: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 530EB21E80AD for ; Thu, 14 Nov 2013 03:07:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 490AEBE38 for ; Thu, 14 Nov 2013 11:07:11 +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 XlaljDo29sk5 for ; Thu, 14 Nov 2013 11:07:11 +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 330A0BE29 for ; Thu, 14 Nov 2013 11:07:11 +0000 (GMT) Message-ID: <5284AEDF.60905@cs.tcd.ie> Date: Thu, 14 Nov 2013 11:07:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> <52838F74.6030907@cs.tcd.ie> <5283FF21.7060803@bbn.com> <528409C8.4050102@cs.tcd.ie> In-Reply-To: <528409C8.4050102@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 11:07:26 -0000 The new list description is up now. [1] Thanks for not turning that into an endless debate! I'd like to also thank Paul Wouters and Dave Crocker for volunteering to do list moderation, so please heed what they say if they need to put on that hat here in future. Sean and I will still be listed as moderators for a bit, but we'll be depending on Paul and Dave to handle any issues that arise from now on. Cheers and thanks again to Dave and Paul, S. [1] https://www.ietf.org/mailman/listinfo/perpass From pindar.wong@gmail.com Thu Nov 14 03:22:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9621E81FD for ; Thu, 14 Nov 2013 03:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7NB7t7WSz0B for ; Thu, 14 Nov 2013 03:22:29 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1721E81FA for ; Thu, 14 Nov 2013 03:22:28 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so1791029wes.12 for ; Thu, 14 Nov 2013 03:22:28 -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=rARTv8NEcjGm/fZs9DcPqt9Ow8xQ8EQT7NpNZLWFtiw=; b=x3dLBFROxpZIxyQ/jVaEAtHGDpLjL+3e2LwEy4/fk1YKeG1xCLeBoFM0jYQ4ra0wYR B3tc6CyFW3O4XQ6AT2on/jaKGeDLj8zxhiWoWwYnjSK1sWvxytdZfJtsmoJLohCGEdHV /8PqCJNOc9mpaEQWTqJi1jPcmLMxPNaXPBCyr8Fm14a2sXqgGPe4Rdb4q73u5fV1I6K1 HTQNAgBWRQOTYtxb0FDRe3RCRfq6NS0JAP/pxHorT3aqYCgCSG8pHjpxifnWM011XJHM +wZwKVlk3qDmpJMteEW9O3cNXLK7lOZgoSUbYIMnHZP5AylcArN/JoMwVqMg4albJoE0 a7zQ== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr1087597wjt.64.1384428147967; Thu, 14 Nov 2013 03:22:27 -0800 (PST) Received: by 10.194.93.138 with HTTP; Thu, 14 Nov 2013 03:22:27 -0800 (PST) In-Reply-To: <5284AEDF.60905@cs.tcd.ie> References: <52811A32.3010706@cs.tcd.ie> <5281542F.1080802@cs.tcd.ie> <52838E05.9090300@bbn.com> <52838F74.6030907@cs.tcd.ie> <5283FF21.7060803@bbn.com> <528409C8.4050102@cs.tcd.ie> <5284AEDF.60905@cs.tcd.ie> Date: Thu, 14 Nov 2013 19:22:27 +0800 Message-ID: From: pindar wong To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b3440dafa0c0f04eb214b59 Cc: perpass@ietf.org Subject: Re: [perpass] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 11:22:30 -0000 --047d7b3440dafa0c0f04eb214b59 Content-Type: text/plain; charset=ISO-8859-1 sorry I'm perhaps too late ... but I would have suggested that instead of better mitigation for pervasive monitoring we use better mitigation of pervasive monitoring i.e. mitigation of damages -- instead of mitigation for damages *http://legal-dictionary.thefreedictionary.com/Mitigation *or better pervasive monitoring mitigation. I guess Tony will correct me. p. On Thu, Nov 14, 2013 at 7:07 PM, Stephen Farrell wrote: > > The new list description is up now. [1] Thanks for > not turning that into an endless debate! > > I'd like to also thank Paul Wouters and Dave Crocker > for volunteering to do list moderation, so please heed > what they say if they need to put on that hat here > in future. Sean and I will still be listed as > moderators for a bit, but we'll be depending on Paul > and Dave to handle any issues that arise from now on. > > Cheers and thanks again to Dave and Paul, > S. > > [1] https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --047d7b3440dafa0c0f04eb214b59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
sorry I'm perhaps too late ... but I wo= uld have suggested that instead of

better mitigation for pervasive = monitoring

we use

better mitigation of pervasive monit= oring

i.e. mitigation of damages -- instead of mitigation for damages

= htt= p://legal-dictionary.thefreedictionary.com/Mitigation

or

better pervasive monitoring mitigation.

I guess= Tony will correct me.

p.



On Thu, Nov 14, 2013 at 7:07 PM, Ste= phen Farrell <stephen.farrell@cs.tcd.ie> wrote:

The new list description is up now. [1] Thanks for
not turning that into an endless debate!

I'd like to also thank Paul Wouters and Dave Crocker
for volunteering to do list moderation, so please heed
what they say if they need to put on that hat here
in future. Sean and I will still be listed as
moderators for a bit, but we'll be depending on Paul
and Dave to handle any issues that arise from now on.

Cheers and thanks again to Dave and Paul,
S.

[1] https://www.ietf.org/mailman/listinfo/perpass
___________________________________= ____________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--047d7b3440dafa0c0f04eb214b59-- From jacob@appelbaum.net Thu Nov 14 03:49:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1251121E80B6 for ; Thu, 14 Nov 2013 03:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogQZzEd9zDoz for ; Thu, 14 Nov 2013 03:49:31 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA4AE21E8095 for ; Thu, 14 Nov 2013 03:49:22 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id w16so999178bkz.29 for ; Thu, 14 Nov 2013 03:49:21 -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:mime-version:to:subject :openpgp:content-type:content-transfer-encoding; bh=CPRabgYZS+ygEq0voKZIc4ylgeDWtgKupdecEOaDGS4=; b=Ei0uQWLzksumjBBsEPc3hd4EGjPZA3miQ3OGS/U0vzB/Tjq2WrQC7eKRmF8cD08Wps KzDPf9pqtKXCfCF8chSL9mihiupK0K0c7a6exjHgX32KIsJ1iWOzOvncyTNI6PQdip+7 HtshYFmSkw9Kfouu9bYHuWFxNmVQuaDv1IWfUBibc3ZhdiM7QZT76kNkzx2TGIAnffWL WktNeeexWK/ExK16zV1N2lHxbstzZ374exjFZ4YyZm+jB2khhYTFJgJWdTVneS2nMsDw bvs+S3BaulKhaECpEgU4EoxQeJ92cju/oZ5dpRf2v0ueufHpB5dWb7VKfooL4WfsHNId NBDQ== X-Gm-Message-State: ALoCoQnoOrZSHs+BG4eNfZQhnES9hGxX7a06UOjS8iMsO7dxrdH/IIq7Qj5v3XUSBaJWW3Erd5Pu X-Received: by 10.205.74.4 with SMTP id yu4mr860355bkb.104.1384429761503; Thu, 14 Nov 2013 03:49:21 -0800 (PST) Received: from 127.0.0.1 (tor21.anonymizer.ccc.de. [31.172.30.4]) by mx.google.com with ESMTPSA id pn6sm2712449bkb.14.2013.11.14.03.49.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 03:49:20 -0800 (PST) Message-ID: <5284B7C9.9080800@appelbaum.net> Date: Thu, 14 Nov 2013 11:45:13 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org OpenPGP: id=4193A197 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [perpass] draft-grothoff-iesg-special-use-p2p-names-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 11:49:42 -0000 Hi, I think that our latest draft is in the spirit of the perpass list: Abstract Today, the Domain Name System (DNS) is a key service for the Internet. DNS is primarily used to map human-memorable names to IP addresses, which are used for routing but generally not meaningful for humans. However, the hierarchical nature of DNS makes it unsuitable for various Peer-to-Peer (P2P) Name Systems. As compatibility with applications using DNS names is desired, these overlay networks often define alternative pseudo Top-Level Domains (pTLDs) to integrate names from the P2P domain into the DNS hierarchy. This memo describes common Special-Use Domain Names [RFC6761] pseudo Top-Level DNS Names designed to help harden name resolution security (e.g., [RFC6840][RFC6975]), provide censorship resistance, and protect the users' privacy on the Internet. In this IESG Approval document we are asking for domain name reservations for five Special-Use Domain Names [RFC6761] TLDs: ".gnu", ".zkey", ".onion", ".exit", and ".i2p". http://www.ietf.org/staging/draft-grothoff-iesg-special-use-p2p-names-00.txt We'd love some feedback. All the best, Jacob From sm@resistor.net Thu Nov 14 04:49:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4271821E81A4 for ; Thu, 14 Nov 2013 04:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch1QayvVGkha for ; Thu, 14 Nov 2013 04:49:37 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CAA21E8085 for ; Thu, 14 Nov 2013 04:49:37 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAECmw7I008614; Thu, 14 Nov 2013 04:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384433346; bh=iVBhUAxl5SYyzANeuK7nJ8986A0Mjlg9A9155H6Iy5s=; h=Date:To:From:Subject:Cc; b=VRPv7/BdnrioqRJYfyxsZJYxmS7R07kYpGOXHLit+IukEUGqnAtDhgXKCWypJVRIx XxG3Si4+bGhXyrScD13avKwAWjFv9HyUG7gdRZ5BjInNaN7Yc1L0BoWN72C3Orv3dB 8GsZOdHuMorIhh6GtV2vd7ukDNY1Vxbo7MHQDU0k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384433346; i=@resistor.net; bh=iVBhUAxl5SYyzANeuK7nJ8986A0Mjlg9A9155H6Iy5s=; h=Date:To:From:Subject:Cc; b=UEAb1RBAzL39UzHRDSyVXVhju983JpuA2YVHJw+cpnM7i4ss4+WMl+JAUx+wUJLa/ 4mZYc6QDNfay5RAm+ItsP9tiGfX+adNFiyed5sulOowuA7nz4JNKy8eQSTl/iLxVty VBn/ATh+0Il5LIvaLxvly7HEKguGKaIVGk5eT43Q= Message-Id: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Nov 2013 04:48:26 -0800 To: Christian Grothoff , Matthias Wachs , "Hellekin O. Wolf" , Jacob Appelbaum From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 12:49:38 -0000 Hello, I took at quick look at draft-grothoff-iesg-special-use-p2p-names-00. The intended status is "IESG Approval". I read the usual IETF documentation. I could not find any mention of an IESG Approval document specification. The draft focuses on domain names. It is going to be problematic to pass such a proposal through. RFC 6761 was controversial. I suggest contacting an Area Director for guidance about the draft. Regards, -sm From christian@grothoff.org Thu Nov 14 04:54:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D4311E80E2 for ; Thu, 14 Nov 2013 04:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY1NbxjpY-de for ; Thu, 14 Nov 2013 04:54:30 -0800 (PST) Received: from smtp1.informatik.tu-muenchen.de (smtp1.informatik.tu-muenchen.de [131.159.0.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC721F9005 for ; Thu, 14 Nov 2013 04:54:30 -0800 (PST) Received: from [131.159.20.32] (pixel.net.in.tum.de [131.159.20.32]) by mail.net.in.tum.de (Postfix) with ESMTP id 6E861192201C; Thu, 14 Nov 2013 13:54:26 +0100 (CET) Message-ID: <5284C802.8070403@grothoff.org> Date: Thu, 14 Nov 2013 13:54:26 +0100 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> In-Reply-To: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ONGKFTPOSMRLMWBCSNQL" X-Mailman-Approved-At: Thu, 14 Nov 2013 04:57:42 -0800 Cc: "Hellekin O. Wolf" , perpass@ietf.org, Matthias Wachs , Jacob Appelbaum Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 12:57:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ONGKFTPOSMRLMWBCSNQL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/2013 01:48 PM, SM wrote: > Hello, > > I took at quick look at draft-grothoff-iesg-special-use-p2p-names-00.=20 > The intended status is "IESG Approval". I read the usual IETF > documentation. I could not find any mention of an IESG Approval > document specification. > That's right, but this is what is mentioned in RFC 6761 (Section 4, Procedure). > The draft focuses on domain names. It is going to be problematic to > pass such a proposal through. RFC 6761 was controversial. I suggest > contacting an Area Director for guidance about the draft. > Well, RFC 6761 being controversial hopefully doesn't mean that one cannot _use_ it. "An" Area Director is a big generic, do you have somebody in mind? Happy hacking! Christian ------enig2ONGKFTPOSMRLMWBCSNQL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlKEyAIACgkQv2Bwi0hCbH5vmwCfdmKSJtKFD/p+tfHU73K28gvA 4SUAoJ6fUL0ESoM/pZSOCxiVn2fK6dd8 =y91+ -----END PGP SIGNATURE----- ------enig2ONGKFTPOSMRLMWBCSNQL-- From a.kuckartz@ping.de Thu Nov 14 05:26:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8659B21E80C8 for ; Thu, 14 Nov 2013 05:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yos7S44YN+q5 for ; Thu, 14 Nov 2013 05:26:41 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id 41A5121E80D2 for ; Thu, 14 Nov 2013 05:26:40 -0800 (PST) Received: (qmail 13581 invoked from network); 14 Nov 2013 13:26:38 -0000 Received: (ofmipd 83.97.42.23); 14 Nov 2013 13:26:16 -0000 Received: from 85-22-24-88.ip.dokom21.de ([85.22.24.88] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1VgwwQ-0003UK-5D for perpass@ietf.org; Thu, 14 Nov 2013 14:26:38 +0100 Date: 14 Nov 2013 14:26:32 +0100 Message-ID: <5284CF88.404@ping.de> From: "Andreas Kuckartz" To: perpass@ietf.org MIME-Version: 1.0 References: <5284B7C9.9080800@appelbaum.net> In-Reply-To: <5284B7C9.9080800@appelbaum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 13:26:45 -0000 > http://www.ietf.org/staging/draft-grothoff-iesg-special-use-p2p-names-00.txt I am currently seeing a 404 error for that URL but I was able to access the document there about an hour ago. BTW: The list of currently registered Special-Use Domain Names is here: http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml Cheers, Andreas From stephen.farrell@cs.tcd.ie Thu Nov 14 05:49:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759BC11E80E2 for ; Thu, 14 Nov 2013 05:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlvYq8mqAWlZ for ; Thu, 14 Nov 2013 05:49: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 7D40D11E8132 for ; Thu, 14 Nov 2013 05:49:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8EC76BE39; Thu, 14 Nov 2013 13:49:52 +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 wah8FaIJik0e; Thu, 14 Nov 2013 13:49:52 +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 72ECEBE33; Thu, 14 Nov 2013 13:49:52 +0000 (GMT) Message-ID: <5284D500.8050206@cs.tcd.ie> Date: Thu, 14 Nov 2013 13:49:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andreas Kuckartz , perpass@ietf.org References: <5284B7C9.9080800@appelbaum.net> <5284CF88.404@ping.de> In-Reply-To: <5284CF88.404@ping.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 13:49:58 -0000 On 11/14/2013 01:26 PM, Andreas Kuckartz wrote: >> > http://www.ietf.org/staging/draft-grothoff-iesg-special-use-p2p-names-00.txt > > I am currently seeing a 404 error for that URL but I was able to access > the document there about an hour ago. Well, the "staging" in the URL is a good hint at least for native English speakers:-) It's now fully published and at [1]. S. [1] https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-00 > > BTW: The list of currently registered Special-Use Domain Names is here: > http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml > > Cheers, > Andreas > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From stephen.farrell@cs.tcd.ie Thu Nov 14 06:43:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910AE21F9A7D for ; Thu, 14 Nov 2013 06:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSiouIQK4aAo for ; Thu, 14 Nov 2013 06:43:41 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CCAA321F9A0C for ; Thu, 14 Nov 2013 06:43:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 653D1BE33 for ; Thu, 14 Nov 2013 14:43:39 +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 gjfkofEjOLid for ; Thu, 14 Nov 2013 14:43:39 +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 508A3BE29 for ; Thu, 14 Nov 2013 14:43:39 +0000 (GMT) Message-ID: <5284E19B.4050007@cs.tcd.ie> Date: Thu, 14 Nov 2013 14:43:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] draft meeting minutes posted X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 14:43:45 -0000 Hi all, Thanks again to our note takers and jabber scribes, who were: Paul Woulters, Karen O'Donoghue, Wendy Selzer, Dan York and Peter StAndre. I've posted the draft minutes [1]. Please send any corrections in the next week or two but I think its ok that these aren't pretty, I'll be sending my hopefully more digestable synopsis in a minute. Thanks, S. [1] http://www.ietf.org/proceedings/88/minutes/minutes-88-perpass From stephen.farrell@cs.tcd.ie Thu Nov 14 06:45:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4367221E80F1 for ; Thu, 14 Nov 2013 06:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, SARE_BAYES_5x8=0.8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISzsvHpNYUXQ for ; Thu, 14 Nov 2013 06:45: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 36EC321E80E7 for ; Thu, 14 Nov 2013 06:45:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65AE5BE33 for ; Thu, 14 Nov 2013 14:45:33 +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 JYslybr7CbPQ for ; Thu, 14 Nov 2013 14:45:33 +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 40C79BE29 for ; Thu, 14 Nov 2013 14:45:33 +0000 (GMT) Message-ID: <5284E20D.8000402@cs.tcd.ie> Date: Thu, 14 Nov 2013 14:45:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] my synopsis of the BoF session outcome X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 14:45:41 -0000 Hi all, Here's what I took from the meeting notes and having listened back to the recording. Overall, there was a good bit more here that was concrete than I thought was the case on the day, so thanks all for that! I put the most vague first and the most concrete last. Apologies in advance if I've annoyed you for how I've characterised your valuable input:-) As always, comments, discussion, volunteering are as welcome as ever! Please start separate threads though unless your follow-up is about the synopsis itself. General thoughts/recommendations, some almost platitudinal: - there's a tension between n/w mgmt & confid - make middleboxes explicit - write more code, connect with OSS communities - think about how our code is implemented/operated, e.g. UPnP - embedded ecosystem doesn't have updates, freezes in bugs, prevents deploying e.g. IPv6 - sometimes we get it wrong when we add too much security - e.g SIP wouldn't have been successful if we'd done security "right" - successful crypto happens where the client just does it and doesn't have to ask, don't sacrifice usability - better documented protocols have fewer security problems - some protocols can't really be secured (e.g. DHCP) so shouldn't be used for lots of config stuff - IPv6 + IPsec + RFC 6092 => IKE, ESP get in, could make things better? - NAT is terrible:-) Research topics, maybe for IAB w/s or IRTF?: - it'd be good to have privacy metrics - think through consequences of mitigations, there will be some - if we get to OE, then how do we get from there to authentication when we want authentication - problems handling security protocol failures (e.g. cert expiry) Review stuff, hard to see such boring work being done: - review old mouldy stuff (even in new docs), incl crypto uses - e2e - maybe a survey of landscape is needed first? - go look at why are existing protocols not being deployed? - organised effort to privacy review existing protocols (directorate?) Actionable maybe, nothing done yet: - either find usable security folks to get involved or else make sure there's no UI, don't require large scale key mgmt - maybe get servers (web) and CA people together to try develop some usable certification protocols - same as above for DNS zone signing tools - IETF should go beyond legislative definitions of personal data e.g. meta-data, define PII as privacy impacting information - should we revise some security BCPs? which? how? who? - (plenary) we should set the GAAP equivalent for security and privacy Lots about OE, but quite actionable: - define OE and how to do it - SF has asked someone if they'd write a HOWTO-pimp-my-protocol-with-OE draft, define it better and how to use it, and be careful with naming it to not imply you get more than you actually get - OE: don't forget active attacks, they can also be somewhat pervasive - OE: don't forget active attacks, they are worse attacks - OE: don't forget active attacks, OE could be oversold - OE: don't forget active attacks, they are more expensive and easier to detect - OE: don't forget active attacks, cost increase may not be as good as you think, e.g. MITM to gather call records - OE: don't forget active attacks, include ways to auto detect them (maybe after the fact) Specific enough to have been actioned already:-) - consider traffic analysis as part of protocol design (-> threat model?, asked Brian) - define a "strong" RNG - a list has been setup for this that's, dsfjdssdfsd@ietf.org and has been announced - reform privacy directive (asked, got 3-4 interested so far, not enough) if it happens, rfc6973 might help this time = got mail so far from: Scott Brim, Jim Fenton, Rhys Smith, Klass Wierenga more welcome = maybe include more, e.g. "privdir" review to be done when appsawg "adopts" or something? - consider DNS confid, e.g. QNAMEs in DNS queries Bortzmeyer, Koch drafts, discussion with INT and OPS ADs ongoing for where to do that work Regards, S. From stephen.farrell@cs.tcd.ie Thu Nov 14 06:47:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3681021E80FA for ; Thu, 14 Nov 2013 06:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qixGiX1W0iB9 for ; Thu, 14 Nov 2013 06:47:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 817B621E80F3 for ; Thu, 14 Nov 2013 06:47:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6EB7BE3E for ; Thu, 14 Nov 2013 14:47:27 +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 TNXFhs36KOEv for ; Thu, 14 Nov 2013 14:47:27 +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 C9E93BE33 for ; Thu, 14 Nov 2013 14:47:27 +0000 (GMT) Message-ID: <5284E280.3060008@cs.tcd.ie> Date: Thu, 14 Nov 2013 14:47:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] current status and plan for things that are in progress already... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 14:47:37 -0000 Hi again, I've updated that file of the current list of topics with what I think it their status [1] and below is what I think is the plan for those. As before comments, discussion, suggestions, volunteering for stuff all all welcome! Cheers, S. There are four kinds of things at [1]: 1. Topics where we've identified people and where to process them. Those are done as far as the perpass list is concerned. 2. Problem statement drafts. I think it'd be good to amalgamate those along with material from Dave Thaler's perpass BoF presentation into a single RFC that describes the situation in detail. I don't think we need or want that to be on the critical path for other work, but its useful to document the situation as we know it. Richard Barnes has agreed to take the lead on working with the folks who've written text to get all that done. 3. Other "perpass" drafts with no other home right now 3a. a TBD "it's an attack" draft that's being discussed by the IESG/IAB to reflect the outcome of the IETF-88 tech plenary. I think that could maybe get done quickly and hope to see a -00 out soon 3b. the threat model, Brian is progressing this 3c. the privacy BCP, needs work, Alissa has the pen 3d. a TBD draft that explains OE and how to do it well, I'm looking for volunteers for that, who've recently implemented e.g. ECDH. I've asked one person who's not yet committed so let me know if you think you could help. 4. Stuff that's still in-progress for the perpass list - that's a list that'll (I hope) grow and shrink as we identify bits of work and volunteers. Please continue discussing and adding to that list. [1] http://down.dsg.cs.tcd.ie/misc/perpass.txt From paul@cypherpunks.ca Thu Nov 14 07:09:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2229111E8133 for ; Thu, 14 Nov 2013 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZkO-E94ww0G for ; Thu, 14 Nov 2013 07:09:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id F395211E80F2 for ; Thu, 14 Nov 2013 07:09:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dL5hV4zJTz75L; Thu, 14 Nov 2013 10:09:46 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WnTj-pXJjpfz; Thu, 14 Nov 2013 10:09:46 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 14 Nov 2013 10:09:45 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7BA0D80103; Thu, 14 Nov 2013 10:09:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6B62C8009A; Thu, 14 Nov 2013 10:09:43 -0500 (EST) Date: Thu, 14 Nov 2013 10:09:43 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Stephen Farrell In-Reply-To: <5284E280.3060008@cs.tcd.ie> Message-ID: References: <5284E280.3060008@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass Subject: Re: [perpass] current status and plan for things that are in progress already... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 15:09:56 -0000 On Thu, 14 Nov 2013, Stephen Farrell wrote: > 3d. a TBD draft that explains OE and how to do it well, I'm > looking for volunteers for that, who've recently implemented > e.g. ECDH. I've asked one person who's not yet committed > so let me know if you think you could help. I'm happy to help here. Paul From a.kuckartz@ping.de Thu Nov 14 07:18:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676C921E80E7 for ; Thu, 14 Nov 2013 07:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBSn0Vaj6gf5 for ; Thu, 14 Nov 2013 07:18:31 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id AAD7B11E8132 for ; Thu, 14 Nov 2013 07:18:27 -0800 (PST) Received: (qmail 6947 invoked from network); 14 Nov 2013 15:18:21 -0000 Received: (ofmipd 83.97.42.23); 14 Nov 2013 15:17:59 -0000 Received: from 85-22-24-88.ip.dokom21.de ([85.22.24.88] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1VgygV-0006UA-U7 for perpass@ietf.org; Thu, 14 Nov 2013 16:18:20 +0100 Date: 14 Nov 2013 16:18:18 +0100 Message-ID: <5284E9BA.4050108@ping.de> From: "Andreas Kuckartz" To: "perpass" MIME-Version: 1.0 References: <5284E20D.8000402@cs.tcd.ie> In-Reply-To: <5284E20D.8000402@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] my synopsis of the BoF session outcome X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 15:18:38 -0000 Stephen Farrell: > - write more code, connect with OSS communities I will forward the most relevant information to the W3C Federated Social Web Community Group. Several FOSS projects are represented there. > - e2e - maybe a survey of landscape is needed first? I am willing to participate in that. Compiling requirements is important. I am especially interested in e2e encryption with more than two ends, such as closed groups ("e3e" ?). Cheers, Andreas From bortzmeyer@nic.fr Thu Nov 14 07:19:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F133121E80F4 for ; Thu, 14 Nov 2013 07:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.51 X-Spam-Level: X-Spam-Status: No, score=-107.51 tagged_above=-999 required=5 tests=[AWL=2.739, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZOE4h4I6EwM for ; Thu, 14 Nov 2013 07:19:49 -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 BE91311E8132 for ; Thu, 14 Nov 2013 07:19:49 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 4FB012804CE; Thu, 14 Nov 2013 16:19:38 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 4A48B2804C9; Thu, 14 Nov 2013 16:19:38 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 3E6184C007C; Thu, 14 Nov 2013 16:19:08 +0100 (CET) Date: Thu, 14 Nov 2013 16:19:08 +0100 From: Stephane Bortzmeyer To: Tony Rutkowski Message-ID: <20131114151908.GB26141@nic.fr> References: <52811A32.3010706@cs.tcd.ie> <52812BBC.1050508@gmail.com> <52815E59.8010606@cs.tcd.ie> <52816CF0.4070803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52816CF0.4070803@gmail.com> X-Operating-System: Debian GNU/Linux 7.2 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] refining the description of the perpass list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 15:19:55 -0000 On Mon, Nov 11, 2013 at 06:49:04PM -0500, Tony Rutkowski wrote a message of 22 lines which said: > It is also interesting to contrast that behavior with the many other > bodies industry bodies in this sector. I have the feeling that many (most?) of SDO are indeed driven by large corporations eager to sell surveillance systems to various actors (good or bad, as long as they have money) and are therefore willing, not to increase the security of the user but, quite contrary, to help surveillance, for instance by standardizing tools for it (see ITU's NGN project, for instance). I'm happy that IETF is different. From bortzmeyer@nic.fr Thu Nov 14 07:40:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB121F96CA for ; Thu, 14 Nov 2013 07:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.671 X-Spam-Level: X-Spam-Status: No, score=-107.671 tagged_above=-999 required=5 tests=[AWL=2.578, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C63MOPLMM5KS for ; Thu, 14 Nov 2013 07:40:45 -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 6F2C221F994A for ; Thu, 14 Nov 2013 07:40:35 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6089C2804E4; Thu, 14 Nov 2013 16:40:34 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 5C2FE2804C9; Thu, 14 Nov 2013 16:40:34 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 504924C007C; Thu, 14 Nov 2013 16:40:04 +0100 (CET) Date: Thu, 14 Nov 2013 16:40:04 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20131114154003.GC26141@nic.fr> References: <5284E280.3060008@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5284E280.3060008@cs.tcd.ie> X-Operating-System: Debian GNU/Linux 7.2 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] current status and plan for things that are in progress already... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 15:40:50 -0000 On Thu, Nov 14, 2013 at 02:47:28PM +0000, Stephen Farrell wrote a message of 53 lines which said: > problem statement drafts. I think it'd be good to amalgamate those > along with material from Dave Thaler's perpass BoF presentation into > a single RFC that describes the situation in detail. I'm of course willing to send the source of draft-bortzmeyer-perpass-dns-privacy to the catenater but I believe it is too early: there are not many "problem statement" drafts and they are typically only at the beginning. From Jeff.Hodges@KingsMountain.com Thu Nov 14 11:43:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2BA21E8126 for ; Thu, 14 Nov 2013 11:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.627 X-Spam-Level: X-Spam-Status: No, score=-101.627 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQVo+lkEX+oY for ; Thu, 14 Nov 2013 11:43:43 -0800 (PST) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 7DDB721E8130 for ; Thu, 14 Nov 2013 11:43:38 -0800 (PST) Received: (qmail 15611 invoked by uid 0); 14 Nov 2013 19:43:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy13.mail.unifiedlayer.com with SMTP; 14 Nov 2013 19:43:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=7Y4jKNZFmVfhsAAePbPiGASEVow9p5HrrpVhFTPP5zQ=; b=HqA1B1373er4v58bSxf4GpV3J6ihRhaTqm8+4mfaUAO8h6+fofB3uyUg2ZGHg9bj4fnpfExsRLW5kXjEsbrsQHFEUl3t6IOHrzAaraoGhEyROF5IJ+YWE8AeSht/4C2G; Received: from [24.4.122.173] (port=58153 helo=[192.168.11.15]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1Vh2op-0002BW-M5 for perpass@ietf.org; Thu, 14 Nov 2013 12:43:11 -0700 Message-ID: <528527CE.4090102@KingsMountain.com> Date: Thu, 14 Nov 2013 11:43:10 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [perpass] Stopping password sniffing -- FIDO X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 19:43:48 -0000 > In terms of minimizing password pain/insecurity, you should check out the > work of the Fido Alliance, which seems very promising to me. They are > trying to cook up a protocol to describe the use of various 2-factor > hardware such as smart cards, USB keys, number dongles, biometrics, and so > on, so that you can use that stuff without getting tied to a particular > vendor/implementation. Yubikey has some very slick demos. Here's some further context... RSA Europe 2013 "Scalable Authentication" see also.. http://fidoalliance.org/ HTH, =JeffH From gwiley@verisign.com Thu Nov 14 11:50:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBC11E80FA for ; Thu, 14 Nov 2013 11:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STU4lzh6IL87 for ; Thu, 14 Nov 2013 11:49:44 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A31421F9C6A for ; Thu, 14 Nov 2013 11:49:42 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUoUpViUipfzx2jQ9MYa8UxXv4uf9rH2s@postini.com; Thu, 14 Nov 2013 11:49:44 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAEJnf5O015694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 14:49:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Nov 2013 14:49:40 -0500 From: "Wiley, Glen" To: Stephane Bortzmeyer Thread-Topic: [perpass] DNS confidentiality Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiAgAGvn4CAAJf+gIAA+6eA//+tbwCAAKmQgIABIvMA Date: Thu, 14 Nov 2013 19:49:39 +0000 Message-ID: In-Reply-To: <20131113212817.GB8596@sources.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6285048E1035494DBD05660926A700C8@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 19:50:06 -0000 On 11/13/13 4:28 PM, "Stephane Bortzmeyer" wrote: >On Wed, Nov 13, 2013 at 04:21:26PM +0000, > Wiley, Glen wrote > a message of 150 lines which said: > >> While I certainly support the idea of confidential DNS, I wonder >> whether it is a good idea to impose the overhead involved in TLS on >> the high volume name servers? > >First, it may not be TLS. I mention dnscrypt and there is also at >least one (not published yet) proposal to encrypt DNS without TLS (or >DTLS). Thanks - I had TLS on the brain while I was reading. > >Second, I do not think we want to impose anything ("MUST encrypt all >queries and MUST accept encrypted queries"...) My vision is that some >servers will adopt encryption and not all. The resolvers will have to >decide (local policy) what to do if the remote server does not support >encryption. The idea of making it opportunistic makes sense to me. > >This approach seems the only realistic one, for incremental >deployment. An interesting consequence is that the end-user will have >trouble knowing if his queries are encrypted or not (specially if his >resolver uses a forwarded). I agree. If he uses a secure transport then one way for the end user to know whether the queries are encrypted is to handle the iteration himself and hit the authoritative servers directly rather than query a recursive resolver. In order to do anything more definite we would need to alter the DNS protocol. > From sm@resistor.net Fri Nov 15 00:26:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8630211E8128 for ; Fri, 15 Nov 2013 00:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=1.322, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc8GRRq2jO2Y for ; Fri, 15 Nov 2013 00:26:52 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB82F11E80F6 for ; Fri, 15 Nov 2013 00:26:43 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAF8Prnl028904; Fri, 15 Nov 2013 00:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384503971; bh=jStD5ZkbjXxuwmpyZSf+izNGswm+w+c+IdE5SRX/ZZg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4Ewqm0b5hCzpcHGt/x5+qa3BzgGk17I+zkG+/Znv0nzIxWSpsp+BrS7KrXQ+LlHTH DjXOL1NeqeauEesB/p3ngriiiGXxNTqYzvIQROj0QosWKbdz5EP1SWKR8zvUPrCfHk W0cHTbIiis+qTohcjOoGODSX66iA/FGUk2T0LEWc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384503971; i=@resistor.net; bh=jStD5ZkbjXxuwmpyZSf+izNGswm+w+c+IdE5SRX/ZZg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VfDpyewmfv+AymbXlr/021Z2KTmcvYbHYJXFDoov3QAoif5mk7ZB7Njyu/TG/m/oV YZu/Cqq2rOHkRTIHIt2UaqZKV9TCqzLHHpj5z8rznqjHh7zLgANfgYq4lyLJZqjbNm YjJMr29Q5PYo4UA7XiRvvZbicFlP5jHTrRPIzE20= Message-Id: <6.2.5.6.2.20131115001541.06c33e20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 15 Nov 2013 00:24:32 -0800 To: Christian Grothoff From: SM In-Reply-To: <5284C802.8070403@grothoff.org> References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> <5284C802.8070403@grothoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Hellekin O. Wolf" , perpass@ietf.org, Matthias Wachs , Jacob Appelbaum Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 08:26:52 -0000 Hi Christian, At 04:54 14-11-2013, Christian Grothoff wrote: >"An" Area Director is a big generic, do you have somebody in mind? I'll suggest Brian Haberman (brian@innovationslab.net) or Ted Lemon (ted.lemon@nominum.com). Regards, -sm From bortzmeyer@nic.fr Fri Nov 15 01:10:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4631011E810A for ; Fri, 15 Nov 2013 01:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMPy92z7mvaE for ; Fri, 15 Nov 2013 01:10:19 -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 E829E11E8108 for ; Fri, 15 Nov 2013 01:10:12 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 8CB20280231; Fri, 15 Nov 2013 10:10:05 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 881FE280129; Fri, 15 Nov 2013 10:10:05 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 7C7934C0053; Fri, 15 Nov 2013 10:09:35 +0100 (CET) Date: Fri, 15 Nov 2013 10:09:35 +0100 From: Stephane Bortzmeyer To: Dan York Message-ID: <20131115090935.GA24775@nic.fr> References: <20131111121027.GA31723@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 7.2 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] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 09:10:29 -0000 On Wed, Nov 13, 2013 at 03:32:06PM +0000, Dan York wrote a message of 117 lines which said: > I very much support the draft By the way, the draft talks only about *passive* attacks, in line with the perpass "charter", and therefore does not mention DNSSEC. But evil projects like QUANTUM and FOXACID are known to use *active* attacks to make mass surveillance easier. Against these attacks, DNSSEC may have a role. Good summary (and plead for DNSSEC deployment) in From alexey.melnikov@isode.com Fri Nov 15 02:59:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907111E818A for ; Fri, 15 Nov 2013 02:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t0rS5k2AWmU for ; Fri, 15 Nov 2013 02:59:48 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5501911E8186 for ; Fri, 15 Nov 2013 02:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1384513186; d=isode.com; s=selector; i=@isode.com; bh=xZyn/ft83ZSePhpAnZQSrUOsAgQywVzsRZYd2Hj5bkQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fnqt4DaQJJxJZv06eYN2FRf7frZqelNIdqsVChJ4TkldXnrXZvcK7gIyejGUBfxRmZJEs7 oVU52zxWSeGLx2A40uBiCuKb2I7BxxgGlFtj0zzKZzABl3SbTKdbLTUJzcCAxi9LbtMHD6 pZvhBnK1srSocfaBYQ3YQVCiavfvAB4=; Received: from [172.16.1.224] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 15 Nov 2013 10:59:46 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5285FEAA.10203@isode.com> Date: Fri, 15 Nov 2013 10:59:54 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Phillip Hallam-Baker References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Secure Dropbox is Secure Email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 10:59:53 -0000 On 13/11/2013 12:52, Phillip Hallam-Baker wrote: [...] > In addition we would want to require end to end encryption and > signature (for spam control). The ability to restart transfers that > were previously aborted in mid session would also be useful. Coincidently this was already done for SMTP: http://www.rfc-editor.org/rfc/rfc1845.txt. I even implemented it in 1999. From hallam@gmail.com Fri Nov 15 06:30:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60711E8147 for ; Fri, 15 Nov 2013 06:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fznjTt0AZlzh for ; Fri, 15 Nov 2013 06:30:11 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 895BE11E81B6 for ; Fri, 15 Nov 2013 06:29:47 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so2837538lab.29 for ; Fri, 15 Nov 2013 06:29: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=YfbrPoVowrL6gihtt40mzg3rDesE1wJRYT59tQ2LsyI=; b=WlyVW55erMT8PLMEnwdiuqEAXzthNVvGZeXrxRmTBou+ztb2SVVoeAm8vr6iAWxgpu pekzjlKURGzf0B0s6RDFrX1cYwmxeX6NwcIBtwmagoq8CVQWJqbhBtxXPjLrGRSNsYJR RIqI+X1oWAum9hGI13pqOweC0i2lNGZgY/HBOQtZSkqaj0HQewwAz0n4M/5nuBY4u2rw lHcZFcjZCXCg1GY9MTvhrY4g3tde1paqxzLmHMy75jeZuKWNXvfmsuOcT7cb8gGXj1jE I2Fao2h1cTW40rOOXIKVXQnaB3dpD7MghgGvtSVaRVxD9NoEeoKysuNM+4ffmpsiakQ3 /boA== MIME-Version: 1.0 X-Received: by 10.152.115.230 with SMTP id jr6mr254493lab.45.1384525786451; Fri, 15 Nov 2013 06:29:46 -0800 (PST) Received: by 10.112.46.98 with HTTP; Fri, 15 Nov 2013 06:29:46 -0800 (PST) In-Reply-To: <5285FEAA.10203@isode.com> References: <5285FEAA.10203@isode.com> Date: Fri, 15 Nov 2013 09:29:46 -0500 Message-ID: From: Phillip Hallam-Baker To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c36742af126e04eb380710 Cc: perpass Subject: Re: [perpass] Secure Dropbox is Secure Email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 14:30:12 -0000 --001a11c36742af126e04eb380710 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 15, 2013 at 5:59 AM, Alexey Melnikov wrote: > On 13/11/2013 12:52, Phillip Hallam-Baker wrote: > [...] > > In addition we would want to require end to end encryption and signature >> (for spam control). The ability to restart transfers that were previously >> aborted in mid session would also be useful. >> > Coincidently this was already done for SMTP: > http://www.rfc-editor.org/rfc/rfc1845.txt. I even implemented it in 1999. > It is one of the few HTTP protocol extensions I see value in. The other area that could be fixed in a new protocol would be to provide a mechanism that allowed gateways to add disclaimers to messages without breaking the message signature. -- Website: http://hallambaker.com/ --001a11c36742af126e04eb380710 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 15, 2013 at 5:59 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 13/11/2013 12:52, Phillip Ha= llam-Baker wrote:
=A0[...]

In addition we would want to require end to end encryption and signature (f= or spam control). The ability to restart transfers that were previously abo= rted in mid session would also be useful.
Coincidently this was already done for SMTP: http://www.rfc-editor.org/rfc/= rfc1845.txt. I even implemented it in 1999.

It is one of the few HTTP protocol extensions I see = value in.=A0

The other area that could be fixed in a new protocol would be to pro= vide a mechanism that allowed gateways to add disclaimers to messages witho= ut breaking the message signature.

--
Website: http://h= allambaker.com/
--001a11c36742af126e04eb380710-- From bortzmeyer@nic.fr Fri Nov 15 06:56:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14B21F9AD5 for ; Fri, 15 Nov 2013 06:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoVhbsGHH2Sm for ; Fri, 15 Nov 2013 06:56:01 -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 DEBF821F9AA3 for ; Fri, 15 Nov 2013 06:56:00 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C3F392801AC; Fri, 15 Nov 2013 15:55:55 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id BE07928018A; Fri, 15 Nov 2013 15:55:55 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id B1C834C007C; Fri, 15 Nov 2013 15:55:25 +0100 (CET) Date: Fri, 15 Nov 2013 15:55:25 +0100 From: Stephane Bortzmeyer To: Joe St Sauver Message-ID: <20131115145525.GA26468@nic.fr> References: <13111209323487_BDAC@oregon.uoregon.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13111209323487_BDAC@oregon.uoregon.edu> X-Operating-System: Debian GNU/Linux 7.2 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: watsonbladd@gmail.com, perpass@ietf.org, hallam@gmail.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 14:56:11 -0000 On Tue, Nov 12, 2013 at 09:32:34AM -0800, Joe St Sauver wrote a message of 68 lines which said: > -- unless we get broad adoption of federated authentication, we'll > always have *too many* usernames and passwords This problem has been solved a long time ago, by password managers. Every Web browser have a pretty good one these days and, if you don't like them (or for other uses than the Web), there are many good password managers, under many licences, for many platforms. From leo@vegoda.org Fri Nov 15 07:02:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43711E810C for ; Fri, 15 Nov 2013 07:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSZqeLtvL5a7 for ; Fri, 15 Nov 2013 07:02:32 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4558711E80E7 for ; Fri, 15 Nov 2013 07:02:31 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id i7so4005908oag.6 for ; Fri, 15 Nov 2013 07:02: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:date :message-id:subject:from:to:cc:content-type; bh=RgXAM+XQPbIKP0RYdoOYd6BFoDGhRywqKwS41kw4Pf0=; b=eXFIo5t772UmeEx8WAP+m4oIncC/kdl1NjCMlmM3AsbFK4FwPtNJoL5SVRmxy7wluE WToQ+DmasyJd/tgKXajugl6AAJjPD43DIUWWRfr2CKD5TV8grl1F2aITYMAZG2lMpTBd mhOEjRp1oIPQQMd9kfTPFST6aBhpyx5HCuiqMBhUibrnviDp5UmVR4hjVCSCucnqsn4u gJikOaAc4iqyAsnTfF/kpGyYdzvlf/3VaPsK6OhvA/hvjYk7E6jlLybn4mjhaLqA0MLF zjFLlA8upqYO6Fvqt8kv4w3M8Sb0OJO4f5mmcSvQ6pxvX5vLd9Y7WY87yvKgFAoA86Ky 5S2A== X-Gm-Message-State: ALoCoQkhJTYEcLO7SgqjyLquoF5mP20ptKGdNFwhHEy+fErLNZAAxAVL78quXaKX/t5YYfbIwb1F MIME-Version: 1.0 X-Received: by 10.60.59.5 with SMTP id v5mr7311670oeq.30.1384527751303; Fri, 15 Nov 2013 07:02:31 -0800 (PST) Received: by 10.76.92.97 with HTTP; Fri, 15 Nov 2013 07:02:31 -0800 (PST) Received: by 10.76.92.97 with HTTP; Fri, 15 Nov 2013 07:02:31 -0800 (PST) In-Reply-To: <20131115145525.GA26468@nic.fr> References: <13111209323487_BDAC@oregon.uoregon.edu> <20131115145525.GA26468@nic.fr> Date: Fri, 15 Nov 2013 07:02:31 -0800 Message-ID: From: Leo Vegoda To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=089e015376b6cc6b7704eb387c44 Cc: Joe St Sauver , perpass@ietf.org, hallam@gmail.com, watsonbladd@gmail.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:02:37 -0000 --089e015376b6cc6b7704eb387c44 Content-Type: text/plain; charset=UTF-8 On 15 Nov 2013 09:56, "Stephane Bortzmeyer" wrote: > > On Tue, Nov 12, 2013 at 09:32:34AM -0800, > Joe St Sauver wrote > a message of 68 lines which said: > > > -- unless we get broad adoption of federated authentication, we'll > > always have *too many* usernames and passwords > > This problem has been solved a long time ago, by password > managers. Every Web browser have a pretty good one these days and, if > you don't like them (or for other uses than the Web), there are many > good password managers, under many licences, for many platforms. Yes, the problem is that the overwhelming majority of users don't see a reason to have different or complex passwords. The problem isn't a lack of good solutions. --089e015376b6cc6b7704eb387c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 15 Nov 2013 09:56, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:
>
> On Tue, Nov 12, 2013 at 09:32:34AM -0800,
> =C2=A0Joe St Sauver <joe@= oregon.uoregon.edu> wrote
> =C2=A0a message of 68 lines which said:
>
> > -- unless we get broad adoption of federated authentication, we&#= 39;ll
> > =C2=A0 =C2=A0always have *too many* usernames and passwords
>
> This problem has been solved a long time ago, by password
> managers. Every Web browser have a pretty good one these days and, if<= br> > you don't like them (or for other uses than the Web), there are ma= ny
> good password managers, under many licences, for many platforms.

Yes, the problem is that the overwhelming majority of users = don't see a reason to have different or complex passwords. The problem = isn't a lack of good solutions.

--089e015376b6cc6b7704eb387c44-- From tbray@textuality.com Fri Nov 15 07:04:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C838011E813F for ; Fri, 15 Nov 2013 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsDEMeSWrHaT for ; Fri, 15 Nov 2013 07:04:55 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 045B911E81B0 for ; Fri, 15 Nov 2013 07:04:54 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id x11so2843522vbb.37 for ; Fri, 15 Nov 2013 07:04:54 -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=cjDHfaI1ugslSW1WPWk2WKiVXODGfkI6YLnxk9uitKs=; b=iumkbu8+sQF4xMrDDk6o9wqS8mCVD4soyWSq5lFw/PMCtFxq9ilhvnpopSL8E+giaI Esc+YnerVHU/FUq6e5Pj7pG39aONGAKU7nGoVVph4IexLaFKw8XJrwuxhJ4JAJ4USobq YgkuGQmgAJuByuvJqbgHjeawdLFXAyU/2QDsLWbqJqO4c5QHt2okWKwot1YJoOscGrCA 3evxh2+eOEYYzktUQfjyh24hVK+mKFFasUC8DsojRGCq0CzNYNcqMWbkKVBqQUVZcyHX dPrB9iQiLQagzGBLcBdTykuoc/KkotayNXzUc6DDStA74MZJiGMXVZTtnZBb7qWypnn3 AdSQ== X-Gm-Message-State: ALoCoQkJ+97vO9VVT0Fwf20DQpVVj4eXErcURIxBtPiyk+VzAl2KG1UekDUyLpmX5E6mtC0YtmXU MIME-Version: 1.0 X-Received: by 10.52.76.36 with SMTP id h4mr79372vdw.46.1384527894250; Fri, 15 Nov 2013 07:04:54 -0800 (PST) Received: by 10.220.198.199 with HTTP; Fri, 15 Nov 2013 07:04:54 -0800 (PST) X-Originating-IP: [24.84.235.32] Received: by 10.220.198.199 with HTTP; Fri, 15 Nov 2013 07:04:54 -0800 (PST) In-Reply-To: <20131115145525.GA26468@nic.fr> References: <13111209323487_BDAC@oregon.uoregon.edu> <20131115145525.GA26468@nic.fr> Date: Fri, 15 Nov 2013 07:04:54 -0800 Message-ID: From: Tim Bray To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=20cf3071c8c251b1f504eb388529 Cc: Joe St Sauver , perpass , hallam@gmail.com, watsonbladd@gmail.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:04:59 -0000 --20cf3071c8c251b1f504eb388529 Content-Type: text/plain; charset=UTF-8 I've had very poor success in getting non-geek civilians to use password managers. On Nov 15, 2013 6:56 AM, "Stephane Bortzmeyer" wrote: > On Tue, Nov 12, 2013 at 09:32:34AM -0800, > Joe St Sauver wrote > a message of 68 lines which said: > > > -- unless we get broad adoption of federated authentication, we'll > > always have *too many* usernames and passwords > > This problem has been solved a long time ago, by password > managers. Every Web browser have a pretty good one these days and, if > you don't like them (or for other uses than the Web), there are many > good password managers, under many licences, for many platforms. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --20cf3071c8c251b1f504eb388529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I've had very poor success in getting non-geek civilians= to use password managers.

On Nov 15, 2013 6:56 AM, "Stephane Bortzmey= er" <bortzmeyer@nic.fr>= wrote:
On Tue, Nov 12, 2013 at 09:32:34AM -0800,
=C2=A0Joe St Sauver <joe@orego= n.uoregon.edu> wrote
=C2=A0a message of 68 lines which said:

> -- unless we get broad adoption of federated authentication, we'll=
> =C2=A0 =C2=A0always have *too many* usernames and passwords

This problem has been solved a long time ago, by password
managers. Every Web browser have a pretty good one these days and, if
you don't like them (or for other uses than the Web), there are many good password managers, under many licences, for many platforms.
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--20cf3071c8c251b1f504eb388529-- From bortzmeyer@nic.fr Fri Nov 15 07:12:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD0411E810D for ; Fri, 15 Nov 2013 07:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKVppQULBY1A for ; Fri, 15 Nov 2013 07:12:19 -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 EDD1011E80F5 for ; Fri, 15 Nov 2013 07:12:18 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5F3B82803B1; Fri, 15 Nov 2013 16:12:18 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 592A028018A; Fri, 15 Nov 2013 16:12:18 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 4D6FC4C007C; Fri, 15 Nov 2013 16:11:48 +0100 (CET) Date: Fri, 15 Nov 2013 16:11:48 +0100 From: Stephane Bortzmeyer To: Tim Bray Message-ID: <20131115151141.GA28153@nic.fr> References: <13111209323487_BDAC@oregon.uoregon.edu> <20131115145525.GA26468@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 7.2 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: Joe St Sauver , perpass , watsonbladd@gmail.com, Stephane Bortzmeyer , hallam@gmail.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:12:24 -0000 On Fri, Nov 15, 2013 at 07:04:54AM -0800, Tim Bray wrote a message of 56 lines which said: > I've had very poor success in getting non-geek civilians to use > password managers. And in getting them to use Shibboleth or smartcards or other fancy passwordless systems? :-) From hallam@gmail.com Fri Nov 15 08:00:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465111E822B for ; Fri, 15 Nov 2013 08:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6ew3w7VvIY9 for ; Fri, 15 Nov 2013 08:00:14 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7348611E81C7 for ; Fri, 15 Nov 2013 07:57:48 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id ev20so2935517lab.13 for ; Fri, 15 Nov 2013 07:57:47 -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=5cPcsTwl1HBwIzlL/ZiGmJDnmyffSZ3CrkcpNdy1eAI=; b=geXy4d2IJQkFu0XTnjYAv2a4534gXpKFFVGLJc70Yn6Jk/uhj120TKBXUVzUl6Jw3P 3BotgwBpuQCrcFefLtWQbRPBKFiBZpLORiCIHDgaD/eaujxYEmbYsoS5E27wgx7W7Xzy g1dMRMw4HKXZGm0AqFsXM5aWX+LMHmv6gzgpcbJSvBs2Kx0mDLLEGqe9dm483u7vrYK+ uC6+clSf8cynZMuSZZ8ofqSx4KBkfls0YvNGvc+qbzRghy0/B1h2xslUIf6rn0cTSt3z azCNgLBHoWrhvh0hdIOcuHWlAkp1IZc0x8vFOsUi9HZTv1sQ4QjTEVBnOtZeU0V1VbhJ /a7A== MIME-Version: 1.0 X-Received: by 10.112.199.41 with SMTP id jh9mr4455218lbc.24.1384531067416; Fri, 15 Nov 2013 07:57:47 -0800 (PST) Received: by 10.112.46.98 with HTTP; Fri, 15 Nov 2013 07:57:47 -0800 (PST) In-Reply-To: <20131115145525.GA26468@nic.fr> References: <13111209323487_BDAC@oregon.uoregon.edu> <20131115145525.GA26468@nic.fr> Date: Fri, 15 Nov 2013 10:57:47 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=001a11c2368274366404eb394212 Cc: Joe St Sauver , perpass , Watson Ladd Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 16:00:16 -0000 --001a11c2368274366404eb394212 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 15, 2013 at 9:55 AM, Stephane Bortzmeyer wrote: > On Tue, Nov 12, 2013 at 09:32:34AM -0800, > Joe St Sauver wrote > a message of 68 lines which said: > > > -- unless we get broad adoption of federated authentication, we'll > > always have *too many* usernames and passwords > > This problem has been solved a long time ago, by password > managers. Every Web browser have a pretty good one these days and, if > you don't like them (or for other uses than the Web), there are many > good password managers, under many licences, for many platforms. > You are confusing an optional proprietary extension that is supported on some systems for a solution. Most of us are forced to use more than one browser and those of us who like one particular browser do not want to be locked into one password manager. And none of the password managers out there is particularly good because there are many sites that actively try to prevent password storage, especially those that really aren't a security issue for users. None of them work well enough to let the service choose a strong password for me (i.e. 128 bit). What we need here is a standardized mechanism for storing passwords to meet the needs of users that also provides a strong authentication mechanism that meets the needs of the sites. Unfortunately we are back in the competitive stage of the browser war where all the players are trying to protect their position by raising the switching costs on their platform. -- Website: http://hallambaker.com/ --001a11c2368274366404eb394212 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 15, 2013 at 9:55 AM, Stephane Bortzmeyer <bor= tzmeyer@nic.fr> wrote:
On Tue, Nov 12, 2013 at 09:32:34AM -0800,
=A0Joe St Sauver <joe@oregon.uoregon.edu> wrote
=A0a message of 68 lines which said:

> -- unless we get broad adoption of federated authentication, we'll=
> =A0 =A0always have *too many* usernames and passwords

This problem has been solved a long time ago, by password
managers. Every Web browser have a pretty good one these days and, if
you don't like them (or for other uses than the Web), there are many good password managers, under many licences, for many platforms.

You are confusing an optional proprietary extension = that is supported on some systems for a solution.

Most of us are forced to use mo= re than one browser and those of us who like one particular browser do not = want to be locked into one password manager. And none of the password manag= ers out there is particularly good because there are many sites that active= ly try to prevent password storage, especially those that really aren't= a security issue for users.

None of the= m work well enough to let the service choose a strong password for me (i.e.= 128 bit).

What we need here is a standardized mechanism for storing passwords to meet= the needs of users that also provides a strong authentication mechanism th= at meets the needs of the sites.

Unfortunately we are back in the competitive sta= ge of the browser war where all the players are trying to protect their pos= ition by raising the switching costs on their platform.

--
Website: http://hallam= baker.com/
--001a11c2368274366404eb394212-- From joe@oregon.uoregon.edu Fri Nov 15 09:14:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4FD11E81A5 for ; Fri, 15 Nov 2013 09:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7nZz63uuVUt for ; Fri, 15 Nov 2013 09:14:46 -0800 (PST) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id 7025A11E80F8 for ; Fri, 15 Nov 2013 09:14:46 -0800 (PST) Date: Fri, 15 Nov 2013 09:08:31 -0800 (PST) Message-Id: <13111509083098_AF3B@oregon.uoregon.edu> From: "Joe St Sauver" To: bortzmeyer@nic.fr X-VMS-To: SMTP%"bortzmeyer@nic.fr" X-VMS-Cc: SMTP%"perpass@ietf.org" Cc: perpass@ietf.org Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 17:14:50 -0000 Hi, Stephane commented in response to my assertion: #> -- unless we get broad adoption of federated authentication, we'll #> always have *too many* usernames and passwords # #This problem has been solved a long time ago, by password #managers. Every Web browser have a pretty good one these days [...] I must confess that the password managers in some browsers may not meet my security expectations for secure password storage, although arguably we're making progress: "Google may lock down access to Chrome's stored passwords to bolster security," http://www.theverge.com/2013/11/4/5064592/google-may-lock-down-access-chrome-stored-passwords Regards, Joe From fergdawgster@mykolab.com Fri Nov 15 09:28:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABD411E814F for ; Fri, 15 Nov 2013 09:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3KikKX1DoL1 for ; Fri, 15 Nov 2013 09:28:06 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEAC11E81C0 for ; Fri, 15 Nov 2013 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52865997.3050406@mykolab.com> Date: Fri, 15 Nov 2013 09:27:51 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Joe St Sauver References: <13111509083098_AF3B@oregon.uoregon.edu> In-Reply-To: <13111509083098_AF3B@oregon.uoregon.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fergdawgster@mykolab.com 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, 15 Nov 2013 17:28:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2013 9:08 AM, Joe St Sauver wrote: > Hi, > > Stephane commented in response to my assertion: > > #> -- unless we get broad adoption of federated authentication, we'll > #> always have *too many* usernames and passwords > # > #This problem has been solved a long time ago, by password > #managers. Every Web browser have a pretty good one these days [...] > > I must confess that the password managers in some browsers may not > meet my security expectations for secure password storage, although > arguably we're making progress: > > "Google may lock down access to Chrome's stored passwords to bolster > security," > http://www.theverge.com/2013/11/4/5064592/google-may-lock-down-access-chr > ome-stored-passwords > Ditto -- I would more trust (and do use) a stand-alone password manager such as Roboform, Keepass, etc. Browsers leak. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFShlmOq1pz9mNUZTMRAkZWAJ9FJA+ndV2SS1UFIXBaOXMeHZ2qNACfc+rk BrYvnpVHeBM3pZLEKby1eWM= =/KW8 -----END PGP SIGNATURE----- From iain.learmonth.09@aberdeen.ac.uk Sat Nov 16 05:30:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1D211E8169 for ; Sat, 16 Nov 2013 05:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ9WzcTv5eG6 for ; Sat, 16 Nov 2013 05:30:55 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5525A11E80EC for ; Sat, 16 Nov 2013 05:30:53 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB156.eurprd01.prod.exchangelabs.com (10.141.2.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 16 Nov 2013 13:30:51 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Sat, 16 Nov 2013 13:30:51 +0000 From: "Learmonth, Iain Ross" To: perpass Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO4iVPi+m3JSb4uUeoAPlhMDxny5omi7qAgAFPPO8= Date: Sat, 16 Nov 2013 13:30:50 +0000 Message-ID: References: <13111509083098_AF3B@oregon.uoregon.edu>, <52865997.3050406@mykolab.com> In-Reply-To: <52865997.3050406@mykolab.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:bd5a:ff16:2b2c:8c50] x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(243025003)(87936001)(76796001)(83322001)(19580395003)(77096001)(56816003)(31966008)(83072001)(15202345003)(19300405004)(74482001)(74502001)(76482001)(47446002)(80976001)(551544002)(74662001)(51856001)(76786001)(4396001)(33646001)(81542001)(81342001)(46102001)(53806001)(69226001)(54356001)(54316002)(87266001)(2656002)(50986001)(47976001)(49866001)(47736001)(59766001)(77982001)(81816001)(85306002)(56776001)(74366001)(74876001)(74706001)(15975445006)(74316001)(81686001)(80022001)(79102001)(63696002)(65816001)(3826001)(24736002)(562404015)(15398625002)(19400905002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB156; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:bd5a:ff16:2b2c:8c50; 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: aberdeen.ac.uk Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 13:30:59 -0000 I've put together a summary of the discussion in this thread so far:=0A= =0A= The ability to prove your identity to a remote system in order to gain acce= ss to=0A= remote resources is an important ability to have. The main method deployed = for =0A= current Internet systems is the use of a password, a word or phrase known o= nly =0A= to the user. Passwords present a large number of attack vectors due to the = fact=0A= that the same password, the secret, is transmitted every time the user want= s to=0A= prove their identity, and that secret can be used by anyone that holds it. = Using=0A= a keylogger, sniffing the wire or an offline brute-force attack or a rainbo= w =0A= table lookup with hashes from a stolen database are all methods through whi= ch a =0A= password could be acquired.=0A= =0A= Databases containing user data are often leaked by crackers [1] and are rea= dily=0A= available to criminals and we have also seen that the NSA have the co-opera= tion=0A= of ISPs when it comes to broad capturing of data [2] on the wire which woul= d=0A= contain passwords. Once a password has been accquired, there is a good chan= ce=0A= that the user will have reused the same password for multiple remote system= s=0A= (61% in 2012 [3]). In 2012, 21% of consumers had an online account compromi= sed=0A= and yet 89% of consumers felt secure with their password management and use= =0A= habits [3]. Clearly, something is wrong.=0A= =0A= Phillip Hallam-Baker suggested that the problem is that moving to strong=0A= authentication techniques is an "all or nothing" proposition requiring both= the=0A= site and the user to adopt before the scheme is useful [4]. He mentions tha= t the=0A= double ended adoption requirement invariably leads to deployment deadlock i= n his=0A= experience.=0A= =0A= For web systems, he suggests a cloud-synchronised password manager be=0A= standardised that would also allow the browser to notify the remote site th= at it=0A= can perform an authentication exchange to create a seamless single-sign-on = user=0A= experience.=0A= =0A= Bjoern Hoehrmann followed up with complaints regarding HTTP Authentication = about=0A= how browsers do not offer a method of "logging out" nor do they show when a= user=0A= is logged in. In his opinion, the use of web forms and cookies for managing= =0A= authentication is wrong and HTTP Authentication and browser UIs should be= =0A= improved [5]. Robin Wilton raises the point that many passwords are used by= =0A= "password proxies" instead of directly by the user [6].=0A= =0A= Tim Bray brought attention to the Fido Alliance [7]:=0A= =0A= > The FIDO (Fast IDentity Online) Alliance was formed in July 2012 to addre= ss=0A= > the lack of interoperability among strong authentication devices as well = as=0A= > the problems users face with creating and remembering multiple usernames = and=0A= > passwords. The Alliance plans to change the nature of authentication by= =0A= > developing specifications that define an open, scalable, interoperable se= t of=0A= > mechanisms that supplant reliance on passwords to securely authenticate u= sers=0A= > of online services. [8]=0A= =0A= Watson Ladd mentions that client certificates are already supported and wid= ely=0A= deployed and the big problem is with the UI and UX of applications [9]. The= DoD=0A= use them for "just about everything" [10].=0A= =0A= Iain Learmonth mentions that the scheme Phillip Hallam-Baker suggested is= =0A= already implemented by LastPass [11] although not as a defined standard.=0A= He suggests moving forward with the idea of TLS client authentication as it= can=0A= provide a seamless UX. These client keys could be synchronised somehow thro= ugh=0A= the cloud, or used with smartcards or dongles, depending on the user's=0A= needs.=0A= =0A= Robin Wilton found the TLS client authentication idea "rational and interes= ting"=0A= and requested more detail [13]. Iain replied [14] that for the cloud=0A= synchronisation the client key pairs would be encrypted and stored in the c= loud,=0A= decrypted with a symmetric key derived from a password allowing synchronisa= tion =0A= of the key chain across devices securely. The master key would never be pas= sed,=0A= encrypted or in plaintext, across the wire. RFC2246 [12] contains the detai= ls=0A= for TLS client authentication.=0A= =0A= Ben Laurie points out Nigori [15][16] which is a Google protocol for storin= g=0A= secrets in the cloud. Iain points out that Nigori only currently supports t= he=0A= storage of RSA keys and so this would need to be extended to store X.509 ke= ys=0A= and certificated [17], but is otherwise suited to this task. He then has so= me=0A= thoughts:=0A= =0A= * How does the service provider get the public certificate?=0A= * Should certificates be reused across sites?=0A= * Does a certificate represent an account or an identity?=0A= * Should both use cases be considered?=0A= * How do we handle multiple accounts on the same site?=0A= =0A= Robin points out that reuse would introduce privacy concerns and so recomme= nds=0A= one certificate per service [18].=0A= =0A= Iain then raises a concern about a privacy issue with TLS itself, regarding= =0A= whether all keys would be tried for each service until one works and whethe= r or=0A= not this would leak any identifying data that could be used for cross-site= =0A= tracking [19].=0A= =0A= Ted Lemon suggests that as part of the TLS handshake, a site ID would be=0A= provided to select a key and then one master key would exist per site with= =0A= client keys on devices signed by this master key. These keys would be manag= ed=0A= by a key server. Iain thought this idea sounded good but asked for futher= =0A= clarification about how the key server would work.=0A= =0A= Ted replied stating the key server would have a collection of public/privat= e=0A= key pairs. When you establish an account at a new site, your browser contac= ts=0A= the server and asks it to generate a new master key pair for the site. The= =0A= browser generates a per-site key pair and sends the public half to the serv= er;=0A= the server hands back a cert signing that key with the new per-site master = key=0A= it generated. Your other devices are notified asynchronously of the new=0A= relationship, and generate their own keys, which are signed with the same= =0A= per-site master key. No secret key ever crosses the network.=0A= =0A= Phillip Hallam-Baker mentions that this is essentially the CardSpace model = [20]=0A= but taking roaming into account. His view is that you should use one public= =0A= keypair per device or if the authentication keys are going to be per site t= hen=0A= you should use a strong (non user chosen) symmetric key and a proof of=0A= possession scheme. There is really no value to a public key scheme for=0A= authentication if there are only two parties to the conversation and no nee= d for=0A= non repudiation. This is only possible if TLS supports the use of symmetric= =0A= schemes for client authentication.=0A= =0A= Paul Ferguson raised concerns [21] about having the authentication manageme= nt=0A= built into the browser as browsers tend to have vulnerabilities that can le= ak=0A= data and would prefer to use a standalone solution.=0A= =0A= The threading went a bit funny, but I tried to get everything and in the ri= ght order.=0A= =0A= Iain.=0A= =0A= [1]: https://pwnedlist.com/stats/account-imports-area-chart-per-month=0A= [2]: https://www.eff.org/files/filenode/att/presskit/ATT_onepager.pdf=0A= [3]: http://www.csid.com/wp-content/uploads/2012/09/CS_PasswordSurvey_FullR= eport_FINAL.pdf=0A= [4]: http://www.ietf.org/mail-archive/web/perpass/current/msg00954.html=0A= [5]: http://www.ietf.org/mail-archive/web/perpass/current/msg00964.html=0A= [6]: http://www.ietf.org/mail-archive/web/perpass/current/msg00966.html=0A= [7]: http://www.ietf.org/mail-archive/web/perpass/current/msg00959.html=0A= [8]: http://www.fidoalliance.org/=0A= [9]: http://www.ietf.org/mail-archive/web/perpass/current/msg00956.html=0A= [10]: http://www.cac.mil/=0A= [11]: http://www.lastpass.com/=0A= [12]: http://www.ietf.org/rfc/rfc2246.txt=0A= [13]: http://www.ietf.org/mail-archive/web/perpass/current/msg00961.html=0A= [14]: http://www.ietf.org/mail-archive/web/perpass/current/msg00980.html=0A= [15]: http://www.ietf.org/mail-archive/web/perpass/current/msg00981.html=0A= [16]: http://www.links.org/files/nigori/nigori-protocol-01.html=0A= [17]: http://www.ietf.org/mail-archive/web/perpass/current/msg00985.html=0A= [18]: http://www.ietf.org/mail-archive/web/perpass/current/msg00991.html=0A= [19]: http://www.ietf.org/mail-archive/web/perpass/current/msg00992.html=0A= [20]: http://en.wikipedia.org/wiki/Windows_CardSpace=0A= [21]: http://www.ietf.org/mail-archive/web/perpass/current/msg01033.html=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= From mellon@fugue.com Sat Nov 16 05:55:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC011E8220 for ; Sat, 16 Nov 2013 05:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKjvtGoFhHwD for ; Sat, 16 Nov 2013 05:55:21 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B068C11E80EC for ; Sat, 16 Nov 2013 05:55:20 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id A827423805A5; Sat, 16 Nov 2013 08:55:19 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Sat, 16 Nov 2013 08:55:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13111509083098_AF3B@oregon.uoregon.edu>, <52865997.3050406@mykolab.com> To: "Learmonth, Iain Ross" X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 13:55:27 -0000 On Nov 16, 2013, at 8:30 AM, Learmonth, Iain Ross = wrote: > Phillip Hallam-Baker mentions that this is essentially the CardSpace = model [20] > but taking roaming into account. His view is that you should use one = public > keypair per device or if the authentication keys are going to be per = site then > you should use a strong (non user chosen) symmetric key and a proof of > possession scheme. There is really no value to a public key scheme for > authentication if there are only two parties to the conversation and = no need for > non repudiation. This is only possible if TLS supports the use of = symmetric > schemes for client authentication. I think you've slightly misrepresented PHB's modification=97what he said = was that you would keep the public/private keypair per site on the key = server, but the keys you use to authenticate to the site would be = private keys. This saves having to generate multiple public/private = key pairs per site, and works fine as long as you have repudiation. Two additional things that have occurred to me since we had this = conversation: - Repudiation can be done by having any device contact the key server = and repudiate any key, after having gotten the repudiation message = signed by the key server using the private key associated with that = site; this avoids the privacy issue of revealing the key server's IP = address, but requires that the site actually implement the repudiation = protocol; if they don't, you're SOL. One could also have a distributed = repudiation model, but I don't think it adds anything. And even with = online repudiation, it's up to the site to check that the key hasn't = been repudiated, so no matter what, you are relying on the site to do = repudiation correctly. The good news is that it's easy to test whether = they are doing it, and indeed that could be written into the protocol. - One use case for this is, e.g., if you have a financial manager who = needs access to some of your accounts in order to make trades on your = behalf, and you want to give them a key, but you'd like to be able to = revoke the key. No change to the proposed protocol is required=97it's = simply another case where this security model would win massively. Thanks for writing up the summary. From iain.learmonth.09@aberdeen.ac.uk Sat Nov 16 06:32:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2BA11E8114 for ; Sat, 16 Nov 2013 06:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=1.707, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9QF2oRgKQ4j for ; Sat, 16 Nov 2013 06:32:17 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8E76711E8173 for ; Sat, 16 Nov 2013 06:31:53 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 16 Nov 2013 14:31:45 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Sat, 16 Nov 2013 14:31:45 +0000 From: "Learmonth, Iain Ross" To: Ted Lemon Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO4iVPi+m3JSb4uUeoAPlhMDxny5omi7qAgAFPPO+AAAe1gIAACSYV Date: Sat, 16 Nov 2013 14:31:44 +0000 Message-ID: <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <13111509083098_AF3B@oregon.uoregon.edu>, <52865997.3050406@mykolab.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:bd5a:ff16:2b2c:8c50] x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(2656002)(87936001)(51856001)(33646001)(76796001)(76482001)(69226001)(53806001)(77982001)(59766001)(77096001)(46102001)(81342001)(87266001)(56776001)(54316002)(85306002)(74482001)(4396001)(56816003)(74876001)(74706001)(49866001)(74316001)(65816001)(80022001)(74502001)(47736001)(74662001)(19580405001)(63696002)(81816001)(50986001)(47446002)(54356001)(47976001)(74366001)(81542001)(81686001)(76786001)(83072001)(31966008)(83322001)(80976001)(19580395003)(79102001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB153; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:bd5a:ff16:2b2c:8c50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 14:32:27 -0000 From: Ted Lemon =0A= =0A= >I think you've slightly misrepresented PHB's modification=97what he said w= as that you would keep the public/private keypair per >site on the key serv= er, but the keys you use to authenticate to the site would be private keys.= This saves having to generate >multiple public/private key pairs per sit= e, and works fine as long as you have repudiation.=0A= =0A= But can this authentication be performed using TLS as it currently exists? = That was my concern.=0A= =0A= >Two additional things that have occurred to me since we had this conversat= ion:=0A= >- Repudiation can be done by having any device contact the key server and = repudiate any key, after having gotten the repudiation message signed by th= e key server using the private key associated with that site; this avoids t= he privacy issue of revealing the key server's IP address, but requires tha= t the site actually implement the repudiation protocol; if they don't, you'= re SOL. One could also have a distributed repudiation model, but I don't = think it adds anything. And even with online repudiation, it's up to the = site to check that the key hasn't been repudiated, so no matter what, you a= re relying on the site to do repudiation correctly. The good news is that= it's easy to test whether they are doing it, and indeed that could be writ= ten into the protocol.=0A= >- One use case for this is, e.g., if you have a financial manager who need= s access to some of your accounts in order to make trades on your behalf, a= nd you want to give them a key, but you'd like to be able to revoke the key= . No change to the proposed protocol is required=97it's simply another ca= se where this security model would win massively.=0A= =0A= Sounds good to me.=0A= =0A= Iain.= From iain.learmonth.09@aberdeen.ac.uk Sat Nov 16 07:38:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890F711E81A0 for ; Sat, 16 Nov 2013 07:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2chwVye0wfSM for ; Sat, 16 Nov 2013 07:37:40 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB211E8164 for ; Sat, 16 Nov 2013 07:37:30 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB155.eurprd01.prod.exchangelabs.com (10.141.2.154) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 16 Nov 2013 15:37:28 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Sat, 16 Nov 2013 15:37:28 +0000 From: "Learmonth, Iain Ross" To: Ted Lemon Thread-Topic: [perpass] Stopping password sniffing Thread-Index: AQHO4iVPi+m3JSb4uUeoAPlhMDxny5omi7qAgAFPPO+AAAe1gIAACSYVgAAPAoCAAAGaKg== Date: Sat, 16 Nov 2013 15:37:27 +0000 Message-ID: <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <13111509083098_AF3B@oregon.uoregon.edu>, <52865997.3050406@mykolab.com> , <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:bd5a:ff16:2b2c:8c50] x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(377454003)(81816001)(59766001)(77982001)(47976001)(56776001)(87266001)(15975445006)(49866001)(47736001)(63696002)(81686001)(79102001)(80022001)(65816001)(54316002)(74706001)(74366001)(74316001)(85306002)(74876001)(551544002)(80976001)(83072001)(76482001)(47446002)(74502001)(74482001)(15202345003)(74662001)(4396001)(81542001)(33646001)(54356001)(51856001)(76786001)(76796001)(87936001)(19580405001)(31966008)(56816003)(77096001)(83322001)(19580395003)(81342001)(50986001)(2656002)(46102001)(69226001)(53806001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB155; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:bd5a:ff16:2b2c:8c50; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 15:38:00 -0000 >From what I can tell from Wikipedia [1] it's not possible to authenticate u= sing a symmetric key. When TLS was designed, they must have considered the = computation expense of using PKI with public and private keypairs and decid= ed that it was fine, so I think we can trust them.=0A= =0A= [1]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authentic= ated_TLS_handshake=0A= =0A= As for revoking certificates, no extension to TLS is required as long as th= ere's a method of notifying the server of revocations. With one keypair per= service, it shouldn't be too hard to push a revocation to the service the = keypair is linked to that it can add to its list.=0A= =0A= I'd really like to avoid making changes to TLS if possible, as then this mi= ght get complicated.=0A= =0A= We could define a scheme for HTTP only (we'd have to pay attention to secti= on 5.1.2 of draft-ietf-httpbis-p7-auth) then we could do crazier things, bu= t working out how to do this at the TLS layer using TLS as it exists means = it's portable to things like mail clients, FTP clients and clients no one's= even thought of yet.=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: Ted Lemon =0A= Sent: 16 November 2013 15:21=0A= To: Learmonth, Iain Ross=0A= Subject: Re: [perpass] Stopping password sniffing=0A= =0A= On Nov 16, 2013, at 9:31 AM, Learmonth, Iain Ross wrote:=0A= > But can this authentication be performed using TLS as it currently exists= ? That was my concern.=0A= =0A= You're asking the wrong person=97I am as innocent as I can manage as to the= details of TLS.=0A= =0A= From mellon@fugue.com Sat Nov 16 10:25:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD32511E812D for ; Sat, 16 Nov 2013 10:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sDAAF96p58E for ; Sat, 16 Nov 2013 10:25:47 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B511E8158 for ; Sat, 16 Nov 2013 10:25:46 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 615CC23805A5; Sat, 16 Nov 2013 13:25:44 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Date: Sat, 16 Nov 2013 13:25:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13111509083098_AF3B@oregon.uoregon.edu>, <52865997.3050406@mykolab.com> , <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com>, <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> To: "Learmonth, Iain Ross" X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 18:25:52 -0000 On Nov 16, 2013, at 10:37 AM, Learmonth, Iain Ross = wrote: > As for revoking certificates, no extension to TLS is required as long = as there's a method of notifying the server of revocations. With one = keypair per service, it shouldn't be too hard to push a revocation to = the service the keypair is linked to that it can add to its list. TLS Certificate revocation mechanisms _won't work_ because they allow = different sites to tell that a particular key belongs to the same = person. > I'd really like to avoid making changes to TLS if possible, as then = this might get complicated. What we are discussing requires substantial changes on both browsers and = service provider sites. Trying to crowbar it into the existing support = for TLS will probably result in the providers not implementing = certificate revocation at all. Service providers don't currently even = _allow_ client authentication using client certs anyway. So we're = talking about deploying something new; might as well do it right. > We could define a scheme for HTTP only (we'd have to pay attention to = section 5.1.2 of draft-ietf-httpbis-p7-auth) then we could do crazier = things, but working out how to do this at the TLS layer using TLS as it = exists means it's portable to things like mail clients, FTP clients and = clients no one's even thought of yet. I understand why you want to stuff this in at the TLS layer, but = realistically you have to change the IMAP, POP, FTP and other = implementations to use client certs anyway, so again, why not do it = right? I don't see any point in designing something that isn't a = complete solution to account for existing implementations that don't = exist! :) From hallam@gmail.com Sat Nov 16 13:47:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4211E8366 for ; Sat, 16 Nov 2013 13:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aguoq-7rI2gZ for ; Sat, 16 Nov 2013 13:47:06 -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 811C311E8365 for ; Sat, 16 Nov 2013 13:47:03 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so1336881lbv.10 for ; Sat, 16 Nov 2013 13:47:02 -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=JKnWAZBDx3etA8sC//ldqZDeFvxC1tc4RkO6LKfMmTo=; b=y1tHrKg1/vOh1Tv/fhmDtEUBDe3CSQmPwg0YWGMmFNGfpL7mpjtcOoV1sMSTyyFX8t NktexgaRzIfgqLtgTcjlE5/uZ/RYlDw1/9AmlfcXvRMexbLw3wxjrPhVFbELvwO98JrE FjxMQ8iUDrBsTFm1Ua8LN8b4ATAnvXuSkkz8HGLQJ+YvW9hP1wspwE5EDyMKI0sFgVma aou8PuM5+4RxKVPsI1ufqDstZDAb4YMm+lovmQWW6s+DO9YwIX8GKIfPA/V+TPmMycga /yHsyWEGUUFhWtvrwAr3IsaLaLnRQTV73Q9lZbU1IgRPk7ked+vbg60Pf/vTglz5rG9w qh8A== MIME-Version: 1.0 X-Received: by 10.112.134.71 with SMTP id pi7mr210688lbb.44.1384638422429; Sat, 16 Nov 2013 13:47:02 -0800 (PST) Received: by 10.112.46.98 with HTTP; Sat, 16 Nov 2013 13:47:02 -0800 (PST) Date: Sat, 16 Nov 2013 16:47:02 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=047d7b3a8ca44fb5bb04eb524111 Subject: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 21:47:15 -0000 --047d7b3a8ca44fb5bb04eb524111 Content-Type: text/plain; charset=ISO-8859-1 I have been looking at the minimal requirements for pervasive crypto. I like TLS everywhere with strong authentication. The idea of weakening the authentication requirements further and calling the result TLS worries me a lot. The other problem with TLS everywhere is that it changes the communication model of HTTP. Proxies no longer work for a start. Data can't be cached. Which has me thinking about extending my session continuation proposal to add in an ephemeral DH exchange and content encryption options to provide a very lightweight message layer security scheme. The idea is that MLS could be used with or without authentication and this would be understood from the start. High security applications would eventually use TLS+MLS as a matter of course and authenticate at both levels. MLS is a better place to put in client authentication. In a scaled system I almost always want to terminate my TLS tunnel before the actual Web Service. Stephen F. suggests that I should look to WebCrypto as a basis. Which seems OK, though I might have a different approach to key packaging. Crypto libraries seem to expect keys to be packaged up in BASE64 encoded ASN.1. Is anyone interested in reading/reviewing drafts? Looking to shoot for an experimental at this stage. The objective would be to get to a point where all Web content can be encrypted including very large chunks of static data like video. This would essentially recapitulate the work done on SHTTP and Shen back in the early 90s so there is little IPR risk. -- Website: http://hallambaker.com/ --047d7b3a8ca44fb5bb04eb524111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been looking at the minimal requirements for pervas= ive crypto.

I like TLS everywhere with= strong authentication. The idea of weakening the authentication requiremen= ts further and calling the result TLS worries me a lot.

The other problem with TLS everywhere is that it change= s the communication model of HTTP. Proxies no longer work for a start. Data= can't be cached.


Which has me = thinking about extending my session continuation proposal to add in an ephe= meral DH exchange and content encryption options to provide a very lightwei= ght message layer security scheme.

The idea is that MLS could be used with or without auth= entication and this would be understood from the start. High security appli= cations would eventually use TLS+MLS as a matter of course and authenticate= at both levels.

MLS is a better place to put in client authentication. = In a scaled system I almost always want to terminate my TLS tunnel before t= he actual Web Service.=A0

Stephen F. suggests that= I should look to WebCrypto as a basis. Which seems OK, though I might have= a different approach to key packaging. Crypto libraries seem to expect key= s to be packaged up in BASE64 encoded ASN.1.

Is anyone interested in reading/reviewing drafts? Looki= ng to shoot for an experimental at this stage.

The objective would be to get to a point where all Web content = can be encrypted including very large chunks of static data like video. Thi= s would essentially recapitulate the work done on SHTTP and Shen back in th= e early 90s so there is little IPR risk.


--
Website: http://hallambaker.com/
--047d7b3a8ca44fb5bb04eb524111-- From brian.e.carpenter@gmail.com Sat Nov 16 15:04:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA8511E80EC for ; Sat, 16 Nov 2013 15:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxSKKWRckxKo for ; Sat, 16 Nov 2013 15:04:45 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4240411E80D9 for ; Sat, 16 Nov 2013 15:04:45 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id x10so4959458pdj.18 for ; Sat, 16 Nov 2013 15:04:45 -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=3p+loABYPSpuDU/aqoljkBu3XwKbDDPqmfDaZ7yWlzs=; b=fZOmx2sV1aYDtYIhKxV3OourZB3CQNwZN5TpAEsmTBURIulLghqkQco3sS3cib01dz +D78PXQpFjoSpw9xSOI/brf+iMHKAkSYn++NOdiwcEqNjV5vjjTxmOlmE0VTOR3VORQV vxOXIqjRjfOChNqviSd3cYRQlqxRmaAMjedfMPpKopAPo0ZRVz+iUoXOcb6LfroJL6aj qT7HFm33NUfWhyIYGxIvCSGitAHiBFpTKj9Mneej6bGwxsEfH/Q+uPkDIzYnaNgIjLrX SlYB8JYN9h90NaBJQ0WkNO7yQwuUkVh5aTqypuijul/24ySFNrLM+Da/uegfFpbrUrI5 cU1Q== X-Received: by 10.66.226.46 with SMTP id rp14mr13715866pac.133.1384643085087; Sat, 16 Nov 2013 15:04:45 -0800 (PST) Received: from [192.168.178.20] (151.199.69.111.dynamic.snap.net.nz. [111.69.199.151]) by mx.google.com with ESMTPSA id gh3sm13443087pbb.2.2013.11.16.15.04.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 15:04:44 -0800 (PST) Message-ID: <5287FA09.3060100@gmail.com> Date: Sun, 17 Nov 2013 12:04:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 23:04:45 -0000 On 17/11/2013 10:47, Phillip Hallam-Baker wrote: ... > The other problem with TLS everywhere is that it changes the communication > model of HTTP. Proxies no longer work for a start. Data can't be cached. Indeed. A "solution" in which caches, proxies, content filtering and possibly CDNs don't work is not going to be deployed on any Internet on this planet. Brian From mellon@fugue.com Sat Nov 16 15:51:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A3A11E8120 for ; Sat, 16 Nov 2013 15:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HpyXccX8quY for ; Sat, 16 Nov 2013 15:51:44 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3D11E8105 for ; Sat, 16 Nov 2013 15:51:44 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id AA26323824DE; Sat, 16 Nov 2013 18:51:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <5287FA09.3060100@gmail.com> Date: Sat, 16 Nov 2013 18:51:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5287FA09.3060100@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1822) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 23:51:51 -0000 On Nov 16, 2013, at 6:04 PM, Brian E Carpenter = wrote: > Indeed. A "solution" in which caches, proxies, content filtering > and possibly CDNs don't work is not going to be deployed on any = Internet > on this planet. Er, be careful here. It's certainly true that a solution that prevents = CDNs, caches, proxies and content filtering from working won't see rapid = uptake among providers that depend on these capabilities. However, = there is a rather substantial long tail of web sites that do not depend = on these capabilities and never will, and it is these very web sites for = which the ability to do various kinds of passive tracking will be most = useful, because they say the most about you. Also, to completely contradict that point, facebook with https enabled = still uses a CDN, so the theory that https prevents CDNs from working is = apparently wrong anyway.= From ned+perpass@mrochek.com Sat Nov 16 19:09:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044611E814D for ; Sat, 16 Nov 2013 19:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIuO+2k6Q65X for ; Sat, 16 Nov 2013 19:08:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 45FCB11E8140 for ; Sat, 16 Nov 2013 19:08:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0V5Q5RYJK000SVQ@mauve.mrochek.com> for perpass@ietf.org; Sat, 16 Nov 2013 19:03:32 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Sat, 16 Nov 2013 19:03:24 -0800 (PST) From: ned+perpass@mrochek.com Message-id: <01P0V5Q1Y3KK00004G@mauve.mrochek.com> Date: Sat, 16 Nov 2013 18:44:09 -0800 (PST) In-reply-to: "Your message dated Sat, 16 Nov 2013 13:25:42 -0500" References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> To: Ted Lemon Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 03:09:11 -0000 > I understand why you want to stuff this in at the TLS layer, but > realistically you have to change the IMAP, POP, FTP and other implementations > to use client certs anyway, so again, why not do it right? I don't see any > point in designing something that isn't a complete solution to account for > existing implementations that don't exist! :) You may be underestimating the amount of support for client certificates and AUTH EXTERNAL here, in the case of IMAP at least. I believe Dovecot, Cyrus, Courier, and Openwave all support them. Oracle's IMAP server definitely does. On the client side, I believe both Thunderbird and Outlook support client certificates. The state of play in the mobile space appears to be more problematic - Apple's client reportedly doesn't support client certificates. Dunno about Android clients. FWIW. Ned From mellon@fugue.com Sat Nov 16 19:20:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E5F11E83C2 for ; Sat, 16 Nov 2013 19:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 461jNCylxHFm for ; Sat, 16 Nov 2013 19:20:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5308911E810B for ; Sat, 16 Nov 2013 19:20:05 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id BFA0323824DE; Sat, 16 Nov 2013 22:20:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <01P0V5Q1Y3KK00004G@mauve.mrochek.com> Date: Sat, 16 Nov 2013 22:20:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> To: ned+perpass@mrochek.com X-Mailer: Apple Mail (2.1822) Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 03:20:14 -0000 On Nov 16, 2013, at 9:44 PM, ned+perpass@mrochek.com wrote: > On the client side, I believe both Thunderbird and Outlook support = client > certificates. The state of play in the mobile space appears to be more > problematic - Apple's client reportedly doesn't support client = certificates. > Dunno about Android clients. Interesting. It looks like the Mavericks client might. However, that = doesn't get us non-trackable client cert revocation. From brian.e.carpenter@gmail.com Sat Nov 16 19:27:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2851F11E821A for ; Sat, 16 Nov 2013 19:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAqdP+Eo9M1N for ; Sat, 16 Nov 2013 19:27:53 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 11AFD11E821B for ; Sat, 16 Nov 2013 19:27:52 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id p10so5099972pdj.37 for ; Sat, 16 Nov 2013 19:27:51 -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=7R59v0HkZMtVgJdvrD68rj4g3t2nWexU4Ug6rex5RDc=; b=T8MHUSy7P2n+9o5oMnALoT0mJZTqCsAC/DBcGNEsDysy/3mf7d5MCdc3gdA1qpC8w6 mgp3bimNQZ7UFCQl/dKpEvrhRHo7Myi+u64xEAT1ocZBzGeJve/JGA/HsD8Wu97aU8FV vnyYwLK2YTaA8cL2Jdi05/Y4yz8+yPt9fXVku2JDxxwgrpAc5WKuXpen32y71qCR7Ntf IRtKWqY23kHDozcbtl0aCnQ+Gb+1zlClQ71vSl1ROgeIre4/PxzKCwHioLBTkx1i0tpt HFfw58t1H+CszkoeYuVHCbuLef/feRexEVDcONt02Glq5MhflubbNmeSXSfcWYeIAimz 7p3A== X-Received: by 10.66.142.170 with SMTP id rx10mr14542774pab.117.1384658871785; Sat, 16 Nov 2013 19:27:51 -0800 (PST) Received: from [192.168.178.20] (151.199.69.111.dynamic.snap.net.nz. [111.69.199.151]) by mx.google.com with ESMTPSA id ka3sm14249513pbc.32.2013.11.16.19.27.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 19:27:50 -0800 (PST) Message-ID: <528837B4.7000601@gmail.com> Date: Sun, 17 Nov 2013 16:27:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <5287FA09.3060100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 03:27:54 -0000 On 17/11/2013 12:51, Ted Lemon wrote: > On Nov 16, 2013, at 6:04 PM, Brian E Carpenter wrote: >> Indeed. A "solution" in which caches, proxies, content filtering >> and possibly CDNs don't work is not going to be deployed on any Internet >> on this planet. > > Er, be careful here. It's certainly true that a solution that prevents CDNs, caches, proxies and content filtering from working won't see rapid uptake among providers that depend on these capabilities. However, there is a rather substantial long tail of web sites that do not depend on these capabilities and never will, and it is these very web sites for which the ability to do various kinds of passive tracking will be most useful, because they say the most about you. Well yes, but the hypothesis seemed to be TLS on *every* HTTP connection. That doesn't seem to fly, is my point (and, I think, Phill's). > Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway. I said "possibly" because I wasn't sure. Maybe somebody can explain how it works and how the associated trust model works? Brian From mellon@fugue.com Sat Nov 16 19:54:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6BB11E8454 for ; Sat, 16 Nov 2013 19:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLDIr16pB8Ru for ; Sat, 16 Nov 2013 19:54:43 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80A11E8453 for ; Sat, 16 Nov 2013 19:54:09 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 7716023824DE; Sat, 16 Nov 2013 22:54:07 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <528837B4.7000601@gmail.com> Date: Sat, 16 Nov 2013 22:54:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5287FA09.3060100@gmail.com> <528837B4.7000601@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1822) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 03:54:49 -0000 On Nov 16, 2013, at 10:27 PM, Brian E Carpenter = wrote: > Well yes, but the hypothesis seemed to be TLS on *every* HTTP = connection. > That doesn't seem to fly, is my point (and, I think, Phill's). I don't see it. Sure, for transparent caching it won't work, but are = people still using transparent caching for CDN? Clearly facebook = isn't, nor Google. I think this ship has already flown the coop. > I said "possibly" because I wasn't sure. Maybe somebody can explain > how it works and how the associated trust model works? The web page you download using https from facebook lists content on cdn = URLs. The browser connects to the cdn server and fetches each such = URL. The URLs on the facebook page I looked at are all https. Why = wouldn't this just work? Transparent caching would break, but that's = not what's going on here=97this is not at all transparent. From prvs=002648b89a=johnl@iecc.com Sat Nov 16 20:00:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0A11E8478 for ; Sat, 16 Nov 2013 20:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZJ8StW3bBaM for ; Sat, 16 Nov 2013 20:00:21 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 742F411E846A for ; Sat, 16 Nov 2013 20:00:20 -0800 (PST) Received: (qmail 41251 invoked from network); 17 Nov 2013 04:00:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Nov 2013 04:00:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52883f53.xn--i8sz2z.k1310; i=johnl@user.iecc.com; bh=5D2F780466rrO+WcYFp8U0N2OVI9lX1oexw+/2G9UPI=; b=pTsuo4KZm8Ts3tDPcW0bxr1/0ptsTAoCZXN2MjxPFI9Fu7VUxpJCHQZYS5SilMUk6WpvZA8UsfaQHx8zhm56Tc2wA2x0y+WCL6Sb6lLauWBpV5FC3xXVOqA/m3jb9D21jqqmjQvLyNpN0/uBSFMQRP09MzE8aBLIKq4ZLVK5rSgDy/+zO3QeFeGWtljJlUyIpK/UNiEe3aNjyApgAKyJOqnRE4TwOFs4U9Mz7+A2m1RVyqmhskhyXVSYjXfrXzcl DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52883f53.xn--i8sz2z.k1310; olt=johnl@user.iecc.com; bh=5D2F780466rrO+WcYFp8U0N2OVI9lX1oexw+/2G9UPI=; b=BryAW5N+OVZkyFf8vpy1D4SwAsG/cYt4QbkOvf9s0+rQhy733c9QXpVfmWlJu14a7B3ZLAlA4k7+zmC/XdmEKnYUWVkJLDPjy1/5OhH20wxcv816EY7EdwTWaffTh7yKf77M2jbN9XOcfarqmz+QbDxJ7r4NIpPZkJR6qyFKHpfn7JjgQdlQOBSbioKdv96Qrcn5Wfa66W+1qUB7dALPvRiTDKztppy9AYDAWwEaWteE423sXHQGQJ+cnWgSCfL5 Date: 17 Nov 2013 03:59:56 -0000 Message-ID: <20131117035956.72756.qmail@joyce.lan> From: "John Levine" To: perpass@ietf.org In-Reply-To: <01P0V5Q1Y3KK00004G@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned+perpass@mrochek.com Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 04:00:35 -0000 >problematic - Apple's client reportedly doesn't support client certificates. >Dunno about Android clients. I poked around on my Android Nexus 7, don't see any way to install client certs. From huitema@huitema.net Sat Nov 16 20:17:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FC711E84CA for ; Sat, 16 Nov 2013 20:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhRiD1fQaE3K for ; Sat, 16 Nov 2013 20:17:04 -0800 (PST) Received: from xsmtp05.mail2web.com (xsmtp25.mail2web.com [168.144.250.191]) by ietfa.amsl.com (Postfix) with ESMTP id E49E811E84CB for ; Sat, 16 Nov 2013 20:17:03 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VhtnB-0008Vv-Rv for perpass@ietf.org; Sat, 16 Nov 2013 23:17:03 -0500 Received: (qmail 18711 invoked from network); 17 Nov 2013 04:16:45 -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 Nov 2013 04:16:45 -0000 From: "Christian Huitema" To: "'perpass'" References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> In-Reply-To: Date: Sat, 16 Nov 2013 20:16:43 -0800 Message-ID: <007a01cee34b$d3baf360$7b30da20$@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: AQGEAzMkbmNgbUKAZxrIQIBob08FRgJsd6KwAge/Ch8CZ8VzOwLO5dMBAqJgTCMB9AK7BwHfah51ASd6bIkBWVKwR5ophD1w Content-Language: en-us Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 04:17:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Many site seem happy to manage a password for each user. The state of = the art seems to be, let the user select a password, and use an e-mail = exchange to verify that the user is who they say they are. It seems that = it would not be much more complicated to let the user present the = signature of a public key, and use an e-mail exchange to verify that = this is indeed the user's public key. Has that been tried already? - -- Christian Huitema -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSiEMqAAoJELba05IUOHVQQCQH/3vrYzHLmB6Vm+8bng70BVvj WIW+NWkGyFwKKODOz2vmNCsxk7Kta8gigbomT0MRZfVxQ4RTENSNnVbmssC7l0xZ uH/839PT67wFSIjLPi5dZ+YoztRLBb8rTCwJNNt0gGOL4Df6+y6if1ephVxGD5sj bsI/ZgO1t04KVdE2FfIhinsRsjLWbzyJtw2nhcG1aKetfmUbiLb6dL8VmaE6PB32 PmNP68TaxFRC/Xrn/RL06cAbzUWd+3ZSeaVK2Q8LCb5k6vuPgqneRauKpWDP+cvw tRs24P/yIpIvrYyMLFyPwvUi9+sWOB/YWcRkVQgXNyHbksTv03IRAc0Yx+TxWGU=3D =3DyxGA -----END PGP SIGNATURE----- From mellon@fugue.com Sat Nov 16 20:23:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCB411E84FD for ; Sat, 16 Nov 2013 20:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWrpUgRnvcra for ; Sat, 16 Nov 2013 20:23:18 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D17611E84F6 for ; Sat, 16 Nov 2013 20:23:18 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 289E623824DE; Sat, 16 Nov 2013 23:23:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <007a01cee34b$d3baf360$7b30da20$@huitema.net> Date: Sat, 16 Nov 2013 23:23:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> <007a01cee34b$d3baf360$7b30da20$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 04:23:24 -0000 On Nov 16, 2013, at 11:16 PM, Christian Huitema = wrote: > Many site seem happy to manage a password for each user. The state of = the art seems to be, let the user select a password, and use an e-mail = exchange to verify that the user is who they say they are. It seems that = it would not be much more complicated to let the user present the = signature of a public key, and use an e-mail exchange to verify that = this is indeed the user's public key. Has that been tried already? Maybe so. This works fine, but doesn't allow for per-device = repudiation. From huitema@huitema.net Sat Nov 16 21:24:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB811E85A4 for ; Sat, 16 Nov 2013 21:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe2neKsIqDvO for ; Sat, 16 Nov 2013 21:24:22 -0800 (PST) Received: from xsmtp06.mail2web.com (xsmtp26.mail2web.com [168.144.250.193]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADD11E85A3 for ; Sat, 16 Nov 2013 21:24:22 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VhuqK-0007m2-D1 for perpass@ietf.org; Sun, 17 Nov 2013 00:24:21 -0500 Received: (qmail 16270 invoked from network); 17 Nov 2013 05:24:19 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Nov 2013 05:24:19 -0000 From: "Christian Huitema" To: "'Ted Lemon'" References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> <007a01cee34b$d3baf360$7b30da20$@huitema.net> In-Reply-To: Date: Sat, 16 Nov 2013 21:24:18 -0800 Message-ID: <008501cee355$441c6540$cc552fc0$@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: AQGEAzMkbmNgbUKAZxrIQIBob08FRgJsd6KwAge/Ch8CZ8VzOwLO5dMBAqJgTCMB9AK7BwHfah51ASd6bIkBWVKwRwHrfcRzAMgokWSaE/nykA== Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 05:24:27 -0000 >> Many site seem happy to manage a password for each user. The state of the art seems to be, let the user select a password, >> and use an e-mail exchange to verify that the user is who they say they are. It seems that it would not be much more complicated >> to let the user present the signature of a public key, and use an e-mail exchange to verify that this is indeed the user's public key. >> Has that been tried already? > > Maybe so. This works fine, but doesn't allow for per-device repudiation. Sure. But passwords don't support repudiation either... It seems the biggest hurdle would be getting a JavaScript API that connects with a local store of the PGP or GPG key. -- Christian Huitema From mellon@fugue.com Sat Nov 16 21:31:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2682F11E85AE for ; Sat, 16 Nov 2013 21:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DP2g0Z5GJP7 for ; Sat, 16 Nov 2013 21:31:48 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0933C11E8120 for ; Sat, 16 Nov 2013 21:31:48 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 81653238153C; Sun, 17 Nov 2013 00:31:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <008501cee355$441c6540$cc552fc0$@huitema.net> Date: Sun, 17 Nov 2013 00:31:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> <007a01cee34b$d3baf360$7b30da20$@huitema.net> <008501cee355$441c6540$cc552fc0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 05:31:56 -0000 On Nov 17, 2013, at 12:24 AM, Christian Huitema = wrote: > Sure. But passwords don't support repudiation either... It seems the = biggest > hurdle would be getting a JavaScript API that connects with a local = store of > the PGP or GPG key.=20 We've dipped deeply into solutions in this discussion and I wouldn't = blame the moderators for asking us to go elsewhere, but having said = that, I think we are talking about two different things. You are = talking about a fairly minor enhancement that makes things a little = nicer, and what some other folks have talked about is a redesign that = might add a lot more value, at the cost of being less easy to adopt. I would appreciate it if some of the security folks would point out = obvious flaws in what we've been discussing=97I still don't have the = privacy model clear in my head, for example. But if we are going to do = something new, IMHO we should get it right, and not do a bandaid that is = just a little bit better. From mellon@fugue.com Sat Nov 16 21:49:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAADE11E85F2 for ; Sat, 16 Nov 2013 21:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDnxY7lxucjf for ; Sat, 16 Nov 2013 21:49:48 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 74A2321F9C8B for ; Sat, 16 Nov 2013 21:49:05 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 14BDB238153C; Sun, 17 Nov 2013 00:49:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <01P0V5Q1Y3KK00004G@mauve.mrochek.com> Date: Sun, 17 Nov 2013 00:49:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <931D23AD-471D-48CA-9FA3-36DB3FFF6A55@fugue.com> References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> To: ned+perpass@mrochek.com X-Mailer: Apple Mail (2.1822) Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 05:49:53 -0000 On Nov 16, 2013, at 9:44 PM, ned+perpass@mrochek.com wrote: > On the client side, I believe both Thunderbird and Outlook support = client > certificates. The state of play in the mobile space appears to be more > problematic - Apple's client reportedly doesn't support client = certificates. > Dunno about Android clients. Android KitKat mail is pretty broken, unfortunately, but I didn't find a = setting for this, nor in some of the popular replacements. From huitema@huitema.net Sat Nov 16 22:18:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6DB11E8666 for ; Sat, 16 Nov 2013 22:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehrxuSxQpVda for ; Sat, 16 Nov 2013 22:18:28 -0800 (PST) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5A42B11E866B for ; Sat, 16 Nov 2013 22:18:28 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Vhvgg-0006jQ-BQ for perpass@ietf.org; Sun, 17 Nov 2013 01:18:27 -0500 Received: (qmail 13133 invoked from network); 17 Nov 2013 06:18:15 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Nov 2013 06:18:15 -0000 From: "Christian Huitema" To: "'Ted Lemon'" References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> <007a01cee34b$d3baf360$7b30da20$@huitema.net> <008501cee355$441c6540$cc552fc0$@huitema.net> In-Reply-To: Date: Sat, 16 Nov 2013 22:18:14 -0800 Message-ID: <008701cee35c$cd3804e0$67a80ea0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGEAzMkbmNgbUKAZxrIQIBob08FRgJsd6KwAge/Ch8CZ8VzOwLO5dMBAqJgTCMB9AK7BwHfah51ASd6bIkBWVKwRwHrfcRzAMgokWQBzwaAtgEB2+AVmf2A66A= Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 06:18:33 -0000 > We've dipped deeply into solutions in this discussion and I wouldn't = blame the moderators for asking us to=20 > go elsewhere, but having said that, I think we are talking about two different things. You are talking about > a fairly minor enhancement that makes things a little nicer, and what some other folks have talked about=20 > is a redesign that might add a lot more value, at the cost of being = less easy to adopt. You are right, this is going a bit far from defense against passive monitoring. The tangential relation Is the protection against active attacks. We may have reasons to believe that if we manage to "encrypt everything," the attackers will move from passive to active, using = various MITM attacks. In that case, client authentication has value, especially = if we can somehow tie client authentication to a validation of the TLS = session key. > I would appreciate it if some of the security folks would point out obvious flaws in what we've been discussing >=97I still don't have the privacy model clear in my head, for example. = But if we are going to do something new,=20 > IMHO we should get it right, and not do a bandaid that is just a = little bit better. Actually, allowing PGP-style authentication of clients could be much = more than a band aid, and would have the advantage of not involving third = parties in the relation between server and client. Intuitively, that seems = easier than requiring all clients to get a PKI style certificate. -- Christian Huitema _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From iain.learmonth.09@aberdeen.ac.uk Sun Nov 17 01:27:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8611E89CA for ; Sun, 17 Nov 2013 01:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGMJ2DnASAYo for ; Sun, 17 Nov 2013 01:27:22 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id E405D11E88DA for ; Sun, 17 Nov 2013 01:25:08 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB155.eurprd01.prod.exchangelabs.com (10.141.2.154) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 17 Nov 2013 09:25:06 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Sun, 17 Nov 2013 09:25:06 +0000 From: "Learmonth, Iain Ross" To: Brian E Carpenter , Ted Lemon Thread-Topic: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS Thread-Index: AQHO40UEGUYnXogIFkmzLFZI27dxtJopJduu Date: Sun, 17 Nov 2013 09:25:06 +0000 Message-ID: References: <5287FA09.3060100@gmail.com> , <528837B4.7000601@gmail.com> In-Reply-To: <528837B4.7000601@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.92.41.201] x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(81816001)(76482001)(47736001)(87936001)(54316002)(49866001)(83322001)(4396001)(74706001)(81686001)(59766001)(79102001)(77982001)(47976001)(54356001)(63696002)(50986001)(56776001)(85306002)(74876001)(87266001)(66066001)(80022001)(80976001)(53806001)(46102001)(51856001)(65816001)(2656002)(81342001)(69226001)(83072001)(81542001)(74366001)(77096001)(76786001)(76796001)(56816003)(74316001)(33646001)(47446002)(74482001)(74502001)(31966008)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB155; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:84.92.41.201; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 09:27:29 -0000 >> Also, to completely contradict that point, facebook with https enabled s= till uses a CDN, so the theory that https prevents CDNs from working is app= arently wrong anyway.=0A= =0A= > I said "possibly" because I wasn't sure. Maybe somebody can explain=0A= how it works and how the associated trust model works?=0A= =0A= The CDN has one TLS connection from the client to the CDN and another from = the CDN to the server, it sees everything in plaintext. A CA signs the CDNs= TLS server certificate so that it can still be accepted by browsers. Depen= ding on the CA, different verifications of ownership may be made.=0A= =0A= This does raise the issue that these CDNs, which may be managing many large= services, would be a great place to tap the wires. Maybe we should be disc= ouraging them?=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= From randy@psg.com Sun Nov 17 01:33:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B611E8209 for ; Sun, 17 Nov 2013 01:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XskJFp+zlyka for ; Sun, 17 Nov 2013 01:33:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id F232011E8962 for ; Sun, 17 Nov 2013 01:33:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VhyjK-0004EL-Te; Sun, 17 Nov 2013 09:33:23 +0000 Date: Sun, 17 Nov 2013 18:33:21 +0900 Message-ID: From: Randy Bush To: DataPacRat In-Reply-To: References: <52668970.4080500@bbn.com> <5266ECF2.5020901@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass , Stephen Kent Subject: Re: [perpass] Web-of-trust CAs X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 09:33:56 -0000 > I'm not familiar with many of the details of DANE and RPKI. Do either > of them provide any protection against a subpoena attack? dane does, rpki does not and this is a major issue randy From stephen.farrell@cs.tcd.ie Sun Nov 17 03:05:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93A11E8103 for ; Sun, 17 Nov 2013 03:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIlN8U5KDbya for ; Sun, 17 Nov 2013 03:05: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 669D311E8226 for ; Sun, 17 Nov 2013 03:05:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00E59BE3F; Sun, 17 Nov 2013 11:05:05 +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 GCzxNJVO1j2W; Sun, 17 Nov 2013 11:05:01 +0000 (GMT) Received: from [10.2.3.4] (unknown [86.42.30.223]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56759BE39; Sun, 17 Nov 2013 11:05:01 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <007a01cee34b$d3baf360$7b30da20$@huitema.net> References: <13111509083098_AF3B@oregon.uoregon.edu> <52865997.3050406@mykolab.com> <86056a79c93a4c40914eda9b4504a0a3@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <3c8b00786cc44bd6b4e8304f9470a6c9@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <01P0V5Q1Y3KK00004G@mauve.mrochek.com> <007a01cee34b$d3baf360$7b30da20$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Stephen Farrell Date: Sun, 17 Nov 2013 11:04:57 +0000 To: Christian Huitema ,'perpass' Message-ID: <14f39367-dca0-4ccb-bac4-f5abfb0b3c0e@email.android.com> Subject: Re: [perpass] Stopping password sniffing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 11:05:13 -0000 Christian Huitema wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Many site seem happy to manage a password for each user. The state of >the art seems to be, let the user select a password, and use an e-mail >exchange to verify that the user is who they say they are. It seems >that it would not be much more complicated to let the user present the >signature of a public key, and use an e-mail exchange to verify that >this is indeed the user's public key. Has that been tried already? Being tried (again;-) [1] for httpauth which is a minority sport. No good reason IMO the same pattern couldn't be followed in loads of protocols S [1] http://tools.ietf.org/html/draft-ietf-httpauth-hoba > >- -- Christian Huitema >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.20 (MingW32) >Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ >Charset: utf-8 > >iQEcBAEBAgAGBQJSiEMqAAoJELba05IUOHVQQCQH/3vrYzHLmB6Vm+8bng70BVvj >WIW+NWkGyFwKKODOz2vmNCsxk7Kta8gigbomT0MRZfVxQ4RTENSNnVbmssC7l0xZ >uH/839PT67wFSIjLPi5dZ+YoztRLBb8rTCwJNNt0gGOL4Df6+y6if1ephVxGD5sj >bsI/ZgO1t04KVdE2FfIhinsRsjLWbzyJtw2nhcG1aKetfmUbiLb6dL8VmaE6PB32 >PmNP68TaxFRC/Xrn/RL06cAbzUWd+3ZSeaVK2Q8LCb5k6vuPgqneRauKpWDP+cvw >tRs24P/yIpIvrYyMLFyPwvUi9+sWOB/YWcRkVQgXNyHbksTv03IRAc0Yx+TxWGU= >=yxGA >-----END PGP SIGNATURE----- > >_______________________________________________ >perpass mailing list >perpass@ietf.org >https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Sun Nov 17 07:40:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC411E8E4E for ; Sun, 17 Nov 2013 07:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFm7Ok63RxB5 for ; Sun, 17 Nov 2013 07:39: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 5AB5711E8E45 for ; Sun, 17 Nov 2013 07:39:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0AC81BE3F; Sun, 17 Nov 2013 15:39:50 +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 M+LOc5QkIiTN; Sun, 17 Nov 2013 15:39:48 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.30.223]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 85E30BE33; Sun, 17 Nov 2013 15:39:48 +0000 (GMT) Message-ID: <5288E344.1020008@cs.tcd.ie> Date: Sun, 17 Nov 2013 15:39:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , perpass References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 15:40:03 -0000 Folks, On 11/16/2013 09:47 PM, Phillip Hallam-Baker wrote: > I like TLS everywhere with strong authentication. The idea of weakening the > authentication requirements further and calling the result TLS worries me a > lot. TLS has include anon-DH from the get go. Self-signed certificate deployments with TLS amount to 10% of all web sites (says [1]). Only about 3 times that number use certs that chain up to a browser-trusted CA of one sort or another. So a premise that all TLS deployments have strong server authentication today is wrong. And I've objected to PHB saying "weakening" elsewhere, [2] so I won't repeat that here. And to the extent this discussion is about http/tls, that belongs on the httpbis wg list, where there's been a firestorm of discussion on exactly that topic. So, please let's not start another http/tls thread here, which is what this seems to be turning in to, even though Phill asked something else. Other foo/tls protocols will also soon have a separate venue [3] and we have a TLS working group. So I see little left to discuss about TLS on this list to be honest. Finally, I note the subject line here said "without TLS" and not "debate TLS on yet another list" :-) S. [1] http://w3techs.com/technologies/overview/ssl_certificate/all [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0928.html [3] https://datatracker.ietf.org/doc/charter-ietf-uta/ From brian.e.carpenter@gmail.com Sun Nov 17 11:01:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D311E90D4 for ; Sun, 17 Nov 2013 11:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGolUHFUda3M for ; Sun, 17 Nov 2013 11:01:42 -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 700B311E90CD for ; Sun, 17 Nov 2013 11:01:00 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id g10so1277857pdj.1 for ; Sun, 17 Nov 2013 11:00:55 -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=f3tgxOh5yN+gxnn5B9tEHj/mXG1UTz6tMZEigaEnpV0=; b=EQYqjfbDh7wIoIs0rKTFyMmg4zhS/Oh/AkEi3Z+JOoGStw8VsVTmcyySL/4+XaENz9 kHIx29UlrSti1iJGe3eNcgrZBtX2UrPgFncaq6pnnUU6UGp9LSL5BcxqrjkOUpTUSRmP OYGg/6MpTBVd2t74GJFFxFN8kKkYi4QllpbEdR4BVCRGcKuks4q2okzgNd+IfK9mI5// 3hdzHckHySQIBCZGWSoZl9F2Q8xyc9qzagP03yg/C2VYLVAVtkQ3bl4sNOjPCpx79d23 G+Az2rpJtH/ZE6HBAwl+rjhs2SFX+iXKTWZzUOLyDsV+q28wUwooPWWBAvR8bGyx7bja VjsA== X-Received: by 10.66.2.234 with SMTP id 10mr17565572pax.39.1384714855078; Sun, 17 Nov 2013 11:00:55 -0800 (PST) Received: from [192.168.178.20] (24.199.69.111.dynamic.snap.net.nz. [111.69.199.24]) by mx.google.com with ESMTPSA id ka3sm18325335pbc.32.2013.11.17.11.00.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 11:00:54 -0800 (PST) Message-ID: <5289125D.6020100@gmail.com> Date: Mon, 18 Nov 2013 08:00:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Learmonth, Iain Ross" References: <5287FA09.3060100@gmail.com> , <528837B4.7000601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , perpass , Ted Lemon Subject: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2013 19:01:43 -0000 On 17/11/2013 22:25, Learmonth, Iain Ross wrote: >>> Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway. > >> I said "possibly" because I wasn't sure. Maybe somebody can explain > how it works and how the associated trust model works? > > The CDN has one TLS connection from the client to the CDN and another from the CDN to the server, it sees everything in plaintext. A CA signs the CDNs TLS server certificate so that it can still be accepted by browsers. Depending on the CA, different verifications of ownership may be made. > > This does raise the issue that these CDNs, which may be managing many large services, would be a great place to tap the wires. Maybe we should be discouraging them? Yep, that's my concern about the trust model (also after redaing Ted Lemon's response). All I know is that some site I have decided to trust has redirected me to content on a third-party site, which presents an apparently valid cert. I don't understand why I should trust that third-party site. Brian From iain.learmonth.09@aberdeen.ac.uk Mon Nov 18 01:14:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD811E8126 for ; Mon, 18 Nov 2013 01:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGfmnQKskyhx for ; Mon, 18 Nov 2013 01:13:57 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EF11E81D7 for ; Mon, 18 Nov 2013 01:13:12 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB156.eurprd01.prod.exchangelabs.com (10.141.2.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 09:13:06 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 09:13:05 +0000 From: "Learmonth, Iain Ross" To: Stephen Farrell , Phillip Hallam-Baker Thread-Topic: [perpass] TLS discussion Thread-Index: AQHO5D05NIqt6GZwAU2CtRejr61+HA== Date: Mon, 18 Nov 2013 09:13:05 +0000 Message-ID: <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: , <5288E344.1020008@cs.tcd.ie> In-Reply-To: <5288E344.1020008@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:630:241:204:bd5a:ff16:2b2c:8c50] x-forefront-prvs: 00342DD5BC x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51444003)(77096001)(56816003)(81342001)(69226001)(47736001)(49866001)(83072001)(50986001)(47976001)(4396001)(74316001)(74662001)(47446002)(74502001)(74482001)(31966008)(74366001)(76796001)(76786001)(33646001)(46102001)(74876001)(15975445006)(81816001)(81686001)(77982001)(59766001)(56776001)(54316002)(76482001)(85306002)(80976001)(83322001)(19580395003)(74706001)(54356001)(65816001)(80022001)(53806001)(87936001)(2656002)(81542001)(51856001)(79102001)(87266001)(63696002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB156; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:bd5a:ff16:2b2c:8c50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] TLS discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 09:14:15 -0000 =0A= > Other foo/tls protocols will also soon have a separate venue [3]=0A= > and we have a TLS working group. So I see little left to discuss=0A= > about TLS on this list to be honest.=0A= =0A= > [3] https://datatracker.ietf.org/doc/charter-ietf-uta/=0A= =0A= I agree that the HTTP/TLS discussion should be moved to the uta (Using TLS = in Applications) mailing list, when one exists, with regard to authenticati= on. It protects far more against active attacks and this list is about prev= enting passive mass monitoring being useful.=0A= =0A= I think that the discussion relating to the use of TLS for encryption, its = effect on proxies and CDNs, and the fact that CDNs are a privacy issue stil= l need discussion here and are relevant to this list.=0A= =0A= The main question: are there times when we would ever want HTTP traffic to = not be encrypted?=0A= The secondary question is: how does the trust model for CDNs be improved? I= don't believe that third-party CDNs that do caching and have access to pri= vate information are a good idea. Maybe we can come up with some best pract= ices like only proxy static content but directly contact for dynamic conten= t that could contain private information and declaring in the cert that you= 're contacting a CDN instead of the actual site? But then there are no guar= antees that people are following them.=0A= =0A= Iain.=0A= =0A= From stephen.farrell@cs.tcd.ie Mon Nov 18 03:47:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0511E8180 for ; Mon, 18 Nov 2013 03:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.574 X-Spam-Level: X-Spam-Status: No, score=-104.574 tagged_above=-999 required=5 tests=[AWL=-1.975, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNxXDN-US2wk for ; Mon, 18 Nov 2013 03:47: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 2BBDF11E820D for ; Mon, 18 Nov 2013 03:46:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5042CBE4C; Mon, 18 Nov 2013 11:46:51 +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 kQ-Gx3tAcpNT; Mon, 18 Nov 2013 11:46:49 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.27.157]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0546BE29; Mon, 18 Nov 2013 11:46:49 +0000 (GMT) Message-ID: <5289FE29.2040804@cs.tcd.ie> Date: Mon, 18 Nov 2013 11:46:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Learmonth, Iain Ross" , Phillip Hallam-Baker References: , <5288E344.1020008@cs.tcd.ie> <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com> In-Reply-To: <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] TLS discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 11:47:08 -0000 On 11/18/2013 09:13 AM, Learmonth, Iain Ross wrote: > >> Other foo/tls protocols will also soon have a separate venue [3] >> and we have a TLS working group. So I see little left to discuss >> about TLS on this list to be honest. > >> [3] https://datatracker.ietf.org/doc/charter-ietf-uta/ > > I agree that the HTTP/TLS discussion should be moved to the uta (Using TLS in Applications) mailing list, when one exists, with regard to authentication. It protects far more against active attacks and this list is about preventing passive mass monitoring being useful. > > I think that the discussion relating to the use of TLS for encryption, its effect on proxies and CDNs, and the fact that CDNs are a privacy issue still need discussion here and are relevant to this list. Well, please bear in mind that httpbis are have a HUGE discussion (~100 mails/day) on exactly this for HTTP/2.0 which is raging now, so let's at least punt the discussion here for a few weeks until the immediate work in httpbis settles down. Or dive in there [1], seems like everyone else is doing that already;-) Pretty please? S. [1] http://tools.ietf.org/wg/httpbis/ > The main question: are there times when we would ever want HTTP traffic to not be encrypted? > The secondary question is: how does the trust model for CDNs be improved? I don't believe that third-party CDNs that do caching and have access to private information are a good idea. Maybe we can come up with some best practices like only proxy static content but directly contact for dynamic content that could contain private information and declaring in the cert that you're contacting a CDN instead of the actual site? But then there are no guarantees that people are following them. > > Iain. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From hallam@gmail.com Mon Nov 18 04:51:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE011E8580 for ; Mon, 18 Nov 2013 04:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1mtgj4Vy2S4 for ; Mon, 18 Nov 2013 04:51:44 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E519D11E83E2 for ; Mon, 18 Nov 2013 04:49:51 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ev20so4675105lab.25 for ; Mon, 18 Nov 2013 04:49:50 -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=ndiFgp3qg0Sr6sjDlsrz10/pxb/caBJ7ad05mZtTpKU=; b=y3IMTUnsWzOUb98a75TzoNwHCahFb64uvfDu+ufkGkw5j6WqQMIBs1t0CS5T1eOV0X F/81JmTmnJtRJmm2BIVBrEeUwZXrDOCGKPTP0QCcA3U01iY9d5c+2AehMtt/m4vi0Nem PTIyWGT0kd36BfR0vi8cF3KaFTMXx7xzNw3kACVFMxKhkqG76EuEbFcfxJims2eJl7Dt o1oX+vQk71H3U8u3mKPiOFC5UWPCYFkrU+3ynFocDSjbauL9hksYna3bWHIMXHW5WM9i MjqhTW1109gNh/vBuZkBPyBoT0l7INVOMm/yh+hGRssrkeT/QJrN1t4Zi+asFTVB4nSf WGdQ== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr14335611lab.11.1384778990833; Mon, 18 Nov 2013 04:49:50 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 18 Nov 2013 04:49:50 -0800 (PST) In-Reply-To: <5289FE29.2040804@cs.tcd.ie> References: <5288E344.1020008@cs.tcd.ie> <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <5289FE29.2040804@cs.tcd.ie> Date: Mon, 18 Nov 2013 07:49:50 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2672ad755f504eb72fba8 Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] TLS discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 12:51:45 -0000 --001a11c2672ad755f504eb72fba8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 6:46 AM, Stephen Farrell wrote: > > > On 11/18/2013 09:13 AM, Learmonth, Iain Ross wrote: > > > >> Other foo/tls protocols will also soon have a separate venue [3] > >> and we have a TLS working group. So I see little left to discuss > >> about TLS on this list to be honest. > > > >> [3] https://datatracker.ietf.org/doc/charter-ietf-uta/ > > > > I agree that the HTTP/TLS discussion should be moved to the uta (Using > TLS in Applications) mailing list, when one exists, with regard to > authentication. It protects far more against active attacks and this list > is about preventing passive mass monitoring being useful. > > > > I think that the discussion relating to the use of TLS for encryption, > its effect on proxies and CDNs, and the fact that CDNs are a privacy issue > still need discussion here and are relevant to this list. > > Well, please bear in mind that httpbis are have a HUGE discussion > (~100 mails/day) on exactly this for HTTP/2.0 which is raging now, > so let's at least punt the discussion here for a few weeks until > the immediate work in httpbis settles down. Or dive in there [1], > seems like everyone else is doing that already;-) > Its a lot more than 100 a day. There are close to 100 in a thread you started last night. And that is the weekend. All the chatter about confidentiality and nobody is interested in fixing the massive hole in the use of cookies for authentication. And they can't even see the connection between the two. -- Website: http://hallambaker.com/ --001a11c2672ad755f504eb72fba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 18, 2013 at 6:46 AM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:


On 11/18/2013 09:13 AM, Learmonth, Iain Ross wrote:
>
>> Other foo/tls protocols will also soon have a separate venue [3] >> and we have a TLS working group. So I see little left to discuss >> about TLS on this list to be honest.
>
>> [3] https://datatracker.ietf.org/doc/charter-ietf-uta/ >
> I agree that the HTTP/TLS discussion should be moved to the uta (Using= TLS in Applications) mailing list, when one exists, with regard to authent= ication. It protects far more against active attacks and this list is about= preventing passive mass monitoring being useful.
>
> I think that the discussion relating to the use of TLS for encryption,= its effect on proxies and CDNs, and the fact that CDNs are a privacy issue= still need discussion here and are relevant to this list.

Well, please bear in mind that httpbis are have a HUGE discussion
(~100 mails/day) on exactly this for HTTP/2.0 which is raging now,
so let's at least punt the discussion here for a few weeks until
the immediate work =A0in httpbis settles down. Or dive in there [1],
seems like everyone else is doing that already;-)

=

Its a lot more than 100 a day. There are close to= 100 in a thread you started last night. And that is the weekend.

All the chatter about confidentiality and nobody is int= erested in fixing the massive hole in the use of cookies for authentication= . And they can't even see the connection between the two.=A0

--
Website: http://h= allambaker.com/
--001a11c2672ad755f504eb72fba8-- From stephen.farrell@cs.tcd.ie Mon Nov 18 06:29:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101811E8231 for ; Mon, 18 Nov 2013 06:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpn1rKp4P69O for ; Mon, 18 Nov 2013 06:29:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3766E11E818D for ; Mon, 18 Nov 2013 06:26:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60EE3BE50; Mon, 18 Nov 2013 14:26:50 +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 oHg3sRYCMi2Z; Mon, 18 Nov 2013 14:26:50 +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 3D0FABE4C; Mon, 18 Nov 2013 14:26:50 +0000 (GMT) Message-ID: <528A23AA.6070806@cs.tcd.ie> Date: Mon, 18 Nov 2013 14:26:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <5288E344.1020008@cs.tcd.ie> <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <5289FE29.2040804@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , "Learmonth, Iain Ross" Subject: Re: [perpass] TLS discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 14:29:26 -0000 On 11/18/2013 12:49 PM, Phillip Hallam-Baker wrote: > > Its a lot more than 100 a day. There are close to 100 in a thread you > started last night. And that is the weekend. Yep. That's why I'd rather we not re-do all that here too. > > All the chatter about confidentiality and nobody is interested in fixing > the massive hole in the use of cookies for authentication. And they can't > even see the connection between the two. That is interesting yes. Yoav mentioned it too and invited folks to look at the work that's not (yet) gotten traction on that in websec. S. From hallam@gmail.com Mon Nov 18 09:58:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8011E8230 for ; Mon, 18 Nov 2013 09:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2gyCg0ynqF6 for ; Mon, 18 Nov 2013 09:58:10 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8D11E81BE for ; Mon, 18 Nov 2013 09:53:08 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id u14so1748220lbd.27 for ; Mon, 18 Nov 2013 09:53:04 -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=jjiKhxiSx9nB9v3/RiOS8JgIjlLT5isbznXLbKWuwhw=; b=0evTj3gRlIlBD9wgtX463j6YH2iPoV+drQMsWKNFZj4Y6L00IvbpjqKLiztIaihW8M Uz3ioPtIV4irL5KgSYjFiKLX3bIZF5BHMREGRVS2mwln3AJUbqJ+/sXr6Y0ocQ175Qm+ v7tXAwSduu+FNPBKe+LM/Fc840vDKwRhjFEsMA4n1N3OKKqLpLYbAiGtZuQoSOz/VCb7 4e2AVoM4XaZFBrZFMZ2LkP2khq8Fa9+QQBUqPBnD4mZodP4HhYOKwIekw9/Qik02BIPM nIYwVDSRcrFsBIEqgkjN1GmtKTF6MAL9uQDG5FNo9WoaEjWig6HhHM4uGesUu1JUfnxB XFlw== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr14445900lbb.0.1384797183902; Mon, 18 Nov 2013 09:53:03 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 18 Nov 2013 09:53:03 -0800 (PST) Date: Mon, 18 Nov 2013 12:53:03 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c23c883b8b4c04eb77383c Subject: [perpass] Traitor Keys and certified hardware X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:58:23 -0000 --001a11c23c883b8b4c04eb77383c Content-Type: text/plain; charset=ISO-8859-1 I have been thinking through the possible origins of the NIST/NSA elliptic curve random number generator with a backdoor. My first reaction was 'what were they thinking'. Followed by essentially the same conclusion as everyone else. But coming back to the problem I realized this morning that we might be missing something in Dual_EC_DRBG. There is actually an advantage to the scheme, provided that you generate your own curve and keep it safe. Let us suppose for the sake of argument that Dual_EC_DRBG was originally designed for the sole purpose of protecting US government secrets better and that there either was never an intention to exploit the backdoor or that was a change that occurred subsequently. What advantage would that give? If the generator is seeded from a simple static seed, the main effect of having a backdoor in the randomness prep is that it makes the process deterministic. An external auditor can use the backdoor to recover the seed and then run the device for an extended period to see if the behavior of the device is fully consistent with that seed choice. If there is a side channel in the purported DRNG, the party who knows the backdoor can check it very quickly. If the generator seeding is dynamic, acquiring >X bits of new seed before outputting X new bits of output, the backdoor doesn't help. But that would mean it wasn't a DRNG. Using such a scheme if the potential attacker knows the backdoor key is obviously bad. But within the narrow requirements of the NIST specification, the scheme does have clear advantages for the government. It means that they can buy commodity hardware and quickly check to see if it has been compromised during manufacture. So the real lesson here might be that people should use Dual_EC_DRBG but with hardware that allows end users to choose their own curves. Which is incidentally what NIST actually advised. So now lets turn to the idea of some sort of open source crypto hardware platform, how might we apply this scheme? Lets imagine for the sake of argument that we are using Raspberry Pi computers which are a commodity computer that is (1) cheap, (2) boots from an SD card (no BIOS), (3) supports a mouse, keyboard and HDMI display. Cheap matters here because several of these machines are going to be burners (literally). The device does not have tempest shielding etc. But I am assuming here that we are taking other precautions to prevent that sort of attack. It is easy enough to build a Faraday cage you can sit in. We start the process with a collection of commodity SD cards bought from a randomly chosen retail vendor and an ISO image of our favored stripped down O/S. We have two separate applications that we would run. 1) The key manager to audit. 2) The curve generation and audit code. We install the programs on separate ISO images on separate machines. Then we write the images out, fingerprint them and publish the full sources, etc. We then boot the curve generation machine and generate a curve, we give the curve to the key manager machine, run it through the full suite of tests and check that the outputs exactly match what they are supposed to using the backdoor to the curves. the key manager device is going to dump out a statement giving the curves used each time as part of its output. For example, pass the hash of the curve spec in the upper bits of the RSA modulus using Moti Young's technique. The whole process is precisely deterministic and therefore auditable. The program does not know if it is being run as a test or for real. So a device that defects only one in ten or one in a thousand times can be caught. This is the reason I don't want to switch from ASN.1 for certs despite it being such a pain, the distinguished encoding is good for exactly one thing and that is eliminating side channels. Before we can use the device we have to establish a trustworthy set of curves. Fortunately this is something that only needs to be done once, though if people doubt the trustworthiness of the curves used they could follow the script and repeat the process. To do this properly we need a ceremony. One of the functions of a ceremony is to ensure that things are done repeatably. Bronowski's Ascent of Man has an example of a Samurai sword being made which is a formal ceremony. The two requirements would be to ensure that the seeds used for generating the curve are completely random and that all physical hardware that has touched them is destroyed after use. The Raspberry Pi is low power enough to run on batteries. A steel box for a Faraday Cage is simple enough for blocking E-M radiation. Can add in a noise generator Turns out that thermite is not quite hot enough to melt silicon. But Oxy-Acetelyne is. The trickiest problem with disposal is likely going to be disposing of the battery safely. -- Website: http://hallambaker.com/ --001a11c23c883b8b4c04eb77383c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been thinking through the possible origins of = the NIST/NSA elliptic curve random number generator with a backdoor. My fir= st reaction was 'what were they thinking'. Followed by essentially = the same conclusion as everyone else.=A0

But coming back to the problem I realized this morning = that we might be missing something in=A0Dual_EC_DRBG= . There is actually an advantage to the scheme, provided that you generate = your own curve and keep it safe.

Let us suppose for the sake of argument that=A0Dual_EC_DRBG was originally designed for the sole purpose of= protecting US government secrets better and that there either was never an= intention to exploit the backdoor or that was a change that occurred subse= quently. What advantage would that give?

If= the generator is seeded from a simple static seed, the main effect of havi= ng a backdoor in the randomness prep is that it makes the process determini= stic. An external auditor can use the backdoor to recover the seed and then= run the device for an extended period to see if the behavior of the device= is fully consistent with that seed choice.

If there is a side channel in the purported DRNG,= the party who knows the backdoor can check it very quickly.

=
If the generator seeding is dynamic, acquiring >X bits of new seed= before outputting X new bits of output, the backdoor doesn't help. But= that would mean it wasn't a DRNG.


Using such a scheme if the potential attacker= knows the backdoor key is obviously bad. But within the narrow requirement= s of the NIST specification, the scheme does have clear advantages for the = government. It means that they can buy commodity hardware and quickly check= to see if it has been compromised during manufacture.

So the real lesson here might be that people shoul= d use=A0Dual_EC_DRBG but with hardware that allows e= nd users to choose their own curves. Which is incidentally what NIST actual= ly advised.=A0


So now lets turn to the idea of some sor= t of open source crypto hardware platform, how might we apply this scheme?<= /div>

Lets imagine for the sake of argument that we are = using Raspberry Pi computers which are a commodity computer that is (1) che= ap, (2) boots from an SD card (no BIOS), (3) supports a mouse, keyboard and= HDMI display. Cheap matters here because several of these machines are goi= ng to be burners (literally).

The device does not have tempest shielding etc. But I a= m assuming here that we are taking other precautions to prevent that sort o= f attack. It is easy enough to build a Faraday cage you can sit in.


We start the process with a collection o= f commodity SD cards bought from a randomly chosen retail vendor and an ISO= image of our favored stripped down O/S. We have two separate applications = that we would run.

1) The key manager to audit.
2) The curve gen= eration and audit code.

We install the programs on= separate ISO images on separate machines. Then we write the images out, fi= ngerprint them and publish the full sources, etc.

We then boot the curve generation machine and generate = a curve, we give the curve to the key manager machine, run it through the f= ull suite of tests and check that the outputs exactly match what they are s= upposed to using the backdoor to the curves. the key manager device is goin= g to dump out a statement giving the curves used each time as part of its o= utput. For example, pass the hash of the curve spec in the upper bits of th= e RSA modulus using Moti Young's technique.

The whole process is precisely deterministic and theref= ore auditable. The program does not know if it is being run as a test or fo= r real. So a device that defects only one in ten or one in a thousand times= can be caught.=A0

This is the reason I don't want to switch from ASN.= 1 for certs despite it being such a pain, the distinguished encoding is goo= d for exactly one thing and that is eliminating side channels.


Before we can use the device we have to establish a tru= stworthy set of curves. Fortunately this is something that only needs to be= done once, though if people doubt the trustworthiness of the curves used t= hey could follow the script and repeat the process.

To do this properly we need a ceremony.

<= /div>
One of the functions of a ceremony is to ensure that things are d= one repeatably. Bronowski's Ascent of Man has an example of a Samurai s= word being made which is a formal ceremony.

The two requirements would be to ensure that the seeds = used for generating the curve are completely random and that all physical h= ardware that has touched them is destroyed after use.

The Raspberry Pi is low power enough to run on batteries. A steel box = for a Faraday Cage is simple enough for blocking E-M radiation. Can add in = a noise generator=A0

Turns out that thermite is no= t quite hot enough to melt silicon. But Oxy-Acetelyne is.

The trickiest problem with disposal is likely going to = be disposing of the battery safely.

--
Website: http://hallambaker.com/
--001a11c23c883b8b4c04eb77383c-- From hallam@gmail.com Mon Nov 18 10:32:33 2013 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 E345A1A1F45 for ; Mon, 18 Nov 2013 10:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe9T66C4ZllN for ; Mon, 18 Nov 2013 10:32:30 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0431A1F42 for ; Mon, 18 Nov 2013 10:32:27 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id er20so5117148lab.22 for ; Mon, 18 Nov 2013 10:32:20 -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 :content-type; bh=2fdOvss/VZ8EqGSMxlsAGgi97/dnScvVm/sVLRMT7P8=; b=PpFI9cQ4D/j5yxWAJwZYn9yeZmZxdiCVF+RWueuYR4FggpmP4igxwkTtSVetKSuSmQ CCzNTr0ViRFy6EilUyK9N0BwstrFL4/4dySv72jdstFxjeor56V7QUwLEbK2rv8JSODz zOfygMk5D6wY6ZTmJWVG/5oCqUFXtSp8IJG/op8qWmeOszGDz+CA4IHARy6G1wNmi9Jq 8OCB2zCf44bWCw2M0B5B1bgexx+VkWWth4YAwwpj91TPNjK9z2+S2loSElunRenBoZ2h bQTER0tU1pvRGFoB2cSTEmPAyiC2TLL50NMzThoSWkcZCoK9Dt36uhjZaWO+H1RS6hIG UQ2g== MIME-Version: 1.0 X-Received: by 10.112.134.3 with SMTP id pg3mr14444610lbb.11.1384798182946; Mon, 18 Nov 2013 10:09:42 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 18 Nov 2013 10:09:42 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Nov 2013 13:09:42 -0500 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=047d7b343c08c7c17204eb777359 Subject: Re: [perpass] Traitor Keys and certified hardware 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, 18 Nov 2013 18:32:34 -0000 --047d7b343c08c7c17204eb777359 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 12:53 PM, Phillip Hallam-Baker wrote: > I have been thinking through the possible origins of the NIST/NSA elliptic > curve random number generator with a backdoor. My first reaction was 'what > were they thinking'. Followed by essentially the same conclusion as > everyone else. > > But coming back to the problem I realized this morning that we might be > missing something in Dual_EC_DRBG. There is actually an advantage to the > scheme, provided that you generate your own curve and keep it safe. > > Let us suppose for the sake of argument that Dual_EC_DRBG was originally > designed for the sole purpose of protecting US government secrets better > and that there either was never an intention to exploit the backdoor or > that was a change that occurred subsequently. What advantage would that > give? > > If the generator is seeded from a simple static seed, the main effect of > having a backdoor in the randomness prep is that it makes the process > deterministic. An external auditor can use the backdoor to recover the seed > and then run the device for an extended period to see if the behavior of > the device is fully consistent with that seed choice. > > If there is a side channel in the purported DRNG, the party who knows the > backdoor can check it very quickly. > > If the generator seeding is dynamic, acquiring >X bits of new seed before > outputting X new bits of output, the backdoor doesn't help. But that would > mean it wasn't a DRNG. > > > Using such a scheme if the potential attacker knows the backdoor key is > obviously bad. But within the narrow requirements of the NIST > specification, the scheme does have clear advantages for the government. It > means that they can buy commodity hardware and quickly check to see if it > has been compromised during manufacture. > > So the real lesson here might be that people should use Dual_EC_DRBG but > with hardware that allows end users to choose their own curves. Which is > incidentally what NIST actually advised. > > > So now lets turn to the idea of some sort of open source crypto hardware > platform, how might we apply this scheme? > > Lets imagine for the sake of argument that we are using Raspberry Pi > computers which are a commodity computer that is (1) cheap, (2) boots from > an SD card (no BIOS), (3) supports a mouse, keyboard and HDMI display. > Cheap matters here because several of these machines are going to be > burners (literally). > > The device does not have tempest shielding etc. But I am assuming here > that we are taking other precautions to prevent that sort of attack. It is > easy enough to build a Faraday cage you can sit in. > > > We start the process with a collection of commodity SD cards bought from a > randomly chosen retail vendor and an ISO image of our favored stripped down > O/S. We have two separate applications that we would run. > > 1) The key manager to audit. > 2) The curve generation and audit code. > > We install the programs on separate ISO images on separate machines. Then > we write the images out, fingerprint them and publish the full sources, etc. > > We then boot the curve generation machine and generate a curve, we give > the curve to the key manager machine, run it through the full suite of > tests and check that the outputs exactly match what they are supposed to > using the backdoor to the curves. the key manager device is going to dump > out a statement giving the curves used each time as part of its output. For > example, pass the hash of the curve spec in the upper bits of the RSA > modulus using Moti Young's technique. > > The whole process is precisely deterministic and therefore auditable. The > program does not know if it is being run as a test or for real. So a device > that defects only one in ten or one in a thousand times can be caught. > > This is the reason I don't want to switch from ASN.1 for certs despite it > being such a pain, the distinguished encoding is good for exactly one thing > and that is eliminating side channels. > > > Before we can use the device we have to establish a trustworthy set of > curves. Fortunately this is something that only needs to be done once, > though if people doubt the trustworthiness of the curves used they could > follow the script and repeat the process. > > To do this properly we need a ceremony. > > One of the functions of a ceremony is to ensure that things are done > repeatably. Bronowski's Ascent of Man has an example of a Samurai sword > being made which is a formal ceremony. > > The two requirements would be to ensure that the seeds used for generating > the curve are completely random and that all physical hardware that has > touched them is destroyed after use. > > The Raspberry Pi is low power enough to run on batteries. A steel box for > a Faraday Cage is simple enough for blocking E-M radiation. Can add in a > noise generator > > Turns out that thermite is not quite hot enough to melt silicon. But > Oxy-Acetelyne is. > > The trickiest problem with disposal is likely going to be disposing of the > battery safely. > > It just occurred to me that a party can obtain even greater security by using multiple random generators with different initial seeds. We could even generate new curves annually. We can still use the RSA modulus side channel to specify which curves were used, it just becomes a list of hashes or the hash of a list. The important thing is that if we ever were to suspect a set of curves had been jiggered we can identify the RSA keys that it was used to generate and revoke the certs. It would be a good idea to put the hash of the ISO build in the modulus as well. -- Website: http://hallambaker.com/ --047d7b343c08c7c17204eb777359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 18, 2013 at 12:53 PM, Phillip Hallam-Baker <hallam@gmai= l.com> wrote:
I have been thinking t= hrough the possible origins of the NIST/NSA elliptic curve random number ge= nerator with a backdoor. My first reaction was 'what were they thinking= '. Followed by essentially the same conclusion as everyone else.=A0

But coming back to the problem I realized this morning = that we might be missing something in=A0Dual_EC_DRBG= . There is actually an advantage to the scheme, provided that you generate = your own curve and keep it safe.

Let us suppose for the sake of argument that=A0Dual_EC_DRBG was originally designed for the sole purpose of= protecting US government secrets better and that there either was never an= intention to exploit the backdoor or that was a change that occurred subse= quently. What advantage would that give?

If= the generator is seeded from a simple static seed, the main effect of havi= ng a backdoor in the randomness prep is that it makes the process determini= stic. An external auditor can use the backdoor to recover the seed and then= run the device for an extended period to see if the behavior of the device= is fully consistent with that seed choice.

If there is a side channel in the purported DRNG,= the party who knows the backdoor can check it very quickly.

=
If the generator seeding is dynamic, acquiring >X bits of new seed= before outputting X new bits of output, the backdoor doesn't help. But= that would mean it wasn't a DRNG.


Using such a scheme if the potential attacker= knows the backdoor key is obviously bad. But within the narrow requirement= s of the NIST specification, the scheme does have clear advantages for the = government. It means that they can buy commodity hardware and quickly check= to see if it has been compromised during manufacture.

So the real lesson here might be that people shoul= d use=A0Dual_EC_DRBG but with hardware that allows e= nd users to choose their own curves. Which is incidentally what NIST actual= ly advised.=A0


So now lets turn to the idea of some sor= t of open source crypto hardware platform, how might we apply this scheme?<= /div>

Lets imagine for the sake of argument that we are = using Raspberry Pi computers which are a commodity computer that is (1) che= ap, (2) boots from an SD card (no BIOS), (3) supports a mouse, keyboard and= HDMI display. Cheap matters here because several of these machines are goi= ng to be burners (literally).

The device does not have tempest shielding etc. But I a= m assuming here that we are taking other precautions to prevent that sort o= f attack. It is easy enough to build a Faraday cage you can sit in.


We start the process with a collection o= f commodity SD cards bought from a randomly chosen retail vendor and an ISO= image of our favored stripped down O/S. We have two separate applications = that we would run.

1) The key manager to audit.
2) The curve gen= eration and audit code.

We install the programs on= separate ISO images on separate machines. Then we write the images out, fi= ngerprint them and publish the full sources, etc.

We then boot the curve generation machine and generate = a curve, we give the curve to the key manager machine, run it through the f= ull suite of tests and check that the outputs exactly match what they are s= upposed to using the backdoor to the curves. the key manager device is goin= g to dump out a statement giving the curves used each time as part of its o= utput. For example, pass the hash of the curve spec in the upper bits of th= e RSA modulus using Moti Young's technique.

The whole process is precisely deterministic and theref= ore auditable. The program does not know if it is being run as a test or fo= r real. So a device that defects only one in ten or one in a thousand times= can be caught.=A0

This is the reason I don't want to switch from ASN.= 1 for certs despite it being such a pain, the distinguished encoding is goo= d for exactly one thing and that is eliminating side channels.


Before we can use the device we have to establish a tru= stworthy set of curves. Fortunately this is something that only needs to be= done once, though if people doubt the trustworthiness of the curves used t= hey could follow the script and repeat the process.

To do this properly we need a ceremony.

<= /div>
One of the functions of a ceremony is to ensure that things are d= one repeatably. Bronowski's Ascent of Man has an example of a Samurai s= word being made which is a formal ceremony.

The two requirements would be to ensure that the seeds = used for generating the curve are completely random and that all physical h= ardware that has touched them is destroyed after use.

The Raspberry Pi is low power enough to run on batteries. A steel box = for a Faraday Cage is simple enough for blocking E-M radiation. Can add in = a noise generator=A0

Turns out that thermite is no= t quite hot enough to melt silicon. But Oxy-Acetelyne is.

The trickiest problem with disposal is likely going to = be disposing of the battery safely.

It just occurred to me that a party can obtain even greater secu= rity by using multiple random generators with different initial seeds.

We could even generate new curves annually.

We can still use the RSA modulus side channel to specify whi= ch curves were used, it just becomes a list of hashes or the hash of a list= . The important thing is that if we ever were to suspect a set of curves ha= d been jiggered we can identify the RSA keys that it was used to generate a= nd revoke the certs.

It would be a good idea to put the hash of the IS= O build in the modulus as well.

--
Website: http://hallambaker.com/
--047d7b343c08c7c17204eb777359-- From bortzmeyer@nic.fr Tue Nov 19 01:59:24 2013 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 8F28B1AD8F6 for ; Tue, 19 Nov 2013 01:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXPzvEfhA0gs for ; Tue, 19 Nov 2013 01:59:22 -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 5E3831AD8F0 for ; Tue, 19 Nov 2013 01:59:22 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0970B28019F; Tue, 19 Nov 2013 10:59:15 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 02B87280129; Tue, 19 Nov 2013 10:59:15 +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 01517B3800C; Tue, 19 Nov 2013 10:58:45 +0100 (CET) Date: Tue, 19 Nov 2013 10:58:44 +0100 From: Stephane Bortzmeyer To: SM Message-ID: <20131119095844.GA12744@nic.fr> References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> X-Operating-System: Debian GNU/Linux 7.2 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: Christian Grothoff , "Hellekin O. Wolf" , perpass@ietf.org, Matthias Wachs , Jacob Appelbaum Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 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, 19 Nov 2013 09:59:24 -0000 On Thu, Nov 14, 2013 at 04:48:26AM -0800, SM wrote a message of 18 lines which said: > The intended status is "IESG Approval". I read the usual IETF > documentation. I could not find any mention of an IESG Approval > document specification. RFC 5226 IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice during the period RFC 2434 was in effect. Rather, it is intended to be available in conjunction with other policies as a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed in a timely fashion or for some other compelling reason. IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment. IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus). From bortzmeyer@nic.fr Tue Nov 19 02:03:17 2013 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 779B41AD947 for ; Tue, 19 Nov 2013 02:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os1fWuT9d_AJ for ; Tue, 19 Nov 2013 02:03:16 -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 0B8D01AD8F6 for ; Tue, 19 Nov 2013 02:03:16 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D4EF228019F; Tue, 19 Nov 2013 11:03:09 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id CE86A280129; Tue, 19 Nov 2013 11:03:09 +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 CCD1CB38038; Tue, 19 Nov 2013 11:02:39 +0100 (CET) Date: Tue, 19 Nov 2013 11:02:39 +0100 From: Stephane Bortzmeyer To: Christian Grothoff Message-ID: <20131119100239.GB12744@nic.fr> References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> <5284C802.8070403@grothoff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5284C802.8070403@grothoff.org> X-Operating-System: Debian GNU/Linux 7.2 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: "Hellekin O. Wolf" , SM , perpass@ietf.org, Matthias Wachs , Jacob Appelbaum Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 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, 19 Nov 2013 10:03:17 -0000 On Thu, Nov 14, 2013 at 01:54:26PM +0100, Christian Grothoff wrote a message of 64 lines which said: > Well, RFC 6761 being controversial hopefully doesn't mean that one > cannot _use_ it. As far as I know, draft-grothoff-iesg-special-use-p2p-names is the first attempt to actually use RFC 6761 and exercice its procedures. But Apple already registered .local in the special registry For the record, I've reviewed draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written and clear and I fully support it. Registering these names would be a very good idea. From scott.brim@gmail.com Tue Nov 19 04:47:37 2013 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 78D271ADF98 for ; Tue, 19 Nov 2013 04:47:37 -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 NxVAu3mFOej3 for ; Tue, 19 Nov 2013 04:47:36 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 040961ADF7A for ; Tue, 19 Nov 2013 04:47:35 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so617717oag.3 for ; Tue, 19 Nov 2013 04:47:30 -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=pfjX5NapyT+mKYBjfp+do03tAetCJpuJFN6Kg1v1MNY=; b=oZAfNbiHu3NguiSRFHuYKRRI3skXC4hnIYJiq8d7dAuLHjp4Oh+7V1tYvVB4yu46eW dLOBR2LCNvuKqrSKTUh2DPmOciDV1o526op2N6S1gG0cJhUME71DG+yey/asQZDE65yc 80YlbCeR7krzb2Yk61JVzA1IIgfmACyAlZ2+I9VBSGRgHk9pbii/4wJDfoSWwIsqman9 sBOWTbQktft5qDWkx4fcgwfjyBE6TpStYY7P/8bsKM+VLIEtMyW+SX6qHTE3mGMAhLxK m7MngQXr8k+7xZIXYdm9uC3/69EDtLn9KhJxKIUk31j5jllsf0bayYb/i63mgUm12vZJ l69Q== MIME-Version: 1.0 X-Received: by 10.60.179.113 with SMTP id df17mr25346900oec.16.1384865249939; Tue, 19 Nov 2013 04:47:29 -0800 (PST) Received: by 10.182.48.9 with HTTP; Tue, 19 Nov 2013 04:47:29 -0800 (PST) Received: by 10.182.48.9 with HTTP; Tue, 19 Nov 2013 04:47:29 -0800 (PST) In-Reply-To: <20131119100239.GB12744@nic.fr> References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> <5284C802.8070403@grothoff.org> <20131119100239.GB12744@nic.fr> Date: Tue, 19 Nov 2013 07:47:29 -0500 Message-ID: From: Scott Brim To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=089e011609bc48dbdb04eb8711fa Cc: Christian Grothoff , perpass , "Hellekin O. Wolf" , Matthias Wachs , Jacob Appelbaum , SM Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 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, 19 Nov 2013 12:47:37 -0000 --089e011609bc48dbdb04eb8711fa Content-Type: text/plain; charset=ISO-8859-1 IESG Approval isn't a document status, it's a policy definition for namespace value assignment. It looks to me like RFC 6761 could have been better phrased. It describes the registry and says that to add to it, an RFC must be published that specifies new entries and the entries must be categorized either IESG Approval or Standards Action... for how they are approved as registry entries. It does not (mean to) say that the RFC itself should have status of IESG Approval. Scott --089e011609bc48dbdb04eb8711fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

IESG Approval isn't a document status, it's a policy= definition for namespace value assignment.=A0

It looks to me like RFC 6761 could have been better phrased.= It describes the registry and says that to add to it, an RFC must be publi= shed that specifies new entries and the entries must be categorized either = IESG Approval or Standards Action... for how they are approved as registry = entries. It does not (mean to) say that the RFC itself should have status o= f IESG Approval.

Scott

--089e011609bc48dbdb04eb8711fa-- From sm@resistor.net Tue Nov 19 06:04:23 2013 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 157EA1ADFE8 for ; Tue, 19 Nov 2013 06:04: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv8hJMD2ZLmV for ; Tue, 19 Nov 2013 06:04:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBD51ADFE6 for ; Tue, 19 Nov 2013 06:04:22 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAJE498D006469; Tue, 19 Nov 2013 06:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384869854; bh=S7BA5HBdIl6O/6nmgytUY7tW+bLvVjLZ4xp2Gv/Ji2g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XvtybyJaOF+EkvCVvWIaGbgOaOu+gJlo8rgo3BIuHyjZIv3plWKL3SROGUexczrdQ f90gLG5smI69kw8/MAjZtemHlYVsxHHBpM2lBa1XQwi7imBPBviPrR9qtb0dXNu4ES yXuaq+4aKqxQKGI0QIRYHcQ5I47Z5Ww2KjIrxZY4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384869854; i=@resistor.net; bh=S7BA5HBdIl6O/6nmgytUY7tW+bLvVjLZ4xp2Gv/Ji2g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=op1fRqjBiU1iy+mw3vnd0t7NDHgKiYYHs8OHSFa9gDVqCLS8I7XTgREL+agbj8MRm FeUN+JQW9gqEqLrj16qs9p3H4C+qgcFUJSqJwT5Eb6oJPp1dlP3qDCYbNbbSVG1N9x gRn2iIVq0ygo5kxoNkhHxyUTNj9BYASglc/9OSxU= Message-Id: <6.2.5.6.2.20131119034817.0d2f8468@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Nov 2013 03:58:41 -0800 To: Stephane Bortzmeyer From: SM In-Reply-To: <20131119095844.GA12744@nic.fr> References: <6.2.5.6.2.20131114043212.0cb4b710@elandnews.com> <20131119095844.GA12744@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] draft-grothoff-iesg-special-use-p2p-names-00 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, 19 Nov 2013 14:04:23 -0000 Hi Stephane, At 01:58 19-11-2013, Stephane Bortzmeyer wrote: >RFC 5226 > >IESG Approval - New assignments may be approved by the IESG. > Although there is no requirement that the request be > documented in an RFC, the IESG has discretion to request > documents or other supporting materials on a case-by-case > basis. That text is about assignments within the purview of the IETF. It is better to avoid turf wars unless there is a good reason. Saving the Internet is usually not considered as a good reason. :-) Regards, -sm From kent@bbn.com Tue Nov 19 13:26:39 2013 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 655F51AE1A0 for ; Tue, 19 Nov 2013 13:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.726 X-Spam-Level: X-Spam-Status: No, score=-6.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 5BHyx7nGAL5A for ; Tue, 19 Nov 2013 13:26:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 205BC1AE168 for ; Tue, 19 Nov 2013 13:26:38 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56565 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VisoZ-000FBI-J7 for perpass@ietf.org; Tue, 19 Nov 2013 16:26:31 -0500 Message-ID: <528BD786.5010702@bbn.com> Date: Tue, 19 Nov 2013 16:26:30 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5284E20D.8000402@cs.tcd.ie> In-Reply-To: <5284E20D.8000402@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] my synopsis of the BoF session outcome 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, 19 Nov 2013 21:26:39 -0000 Stephen, Nice job of collecting the vast number of comments during the session. Some thoughts on a few of the notes: > - IPv6 + IPsec + RFC 6092 => IKE, ESP get in, could make > things better? do we have any info on whether many CPE devices conform to most (all?) of the recommendations in 6092? > Research topics, maybe for IAB w/s or IRTF?: > > - problems handling security protocol failures (e.g. cert > expiry) I don't see handling cert expiry as a research problem. it seems that vendors have decided that too many CAs are too sloppy re cert expiration and thus products are lenient wrt expiration, which, of course, disrupts a possible feedback loop ... > Actionable maybe, nothing done yet: > > - maybe get servers (web) and CA people together to try > develop some usable certification protocols what protocols do you think we are missing? > - IETF should go beyond legislative definitions of personal > data e.g. meta-data, define PII as privacy impacting > information I disagree with this suggestion. PII is defined by law in several jurisdictions. If we want to define privacy-related info, create a new term, but don't start a fight over an existing, defined term > - (plenary) we should set the GAAP equivalent for > security and privacy GAAP are defined by the IASB. Even though the IESG share several acronym letters and length, there are way too many differences to believe that they can be the source of an analogous set of principles. Also, many of the issues that affect security and privacy in the Internet are host/server issues that are outside of the protocol purview of the IETF. Steve From housley@vigilsec.com Wed Nov 20 07:50:28 2013 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 D139A1AE012 for ; Wed, 20 Nov 2013 07:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2-CKVhYUO8tx for ; Wed, 20 Nov 2013 07:50:27 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 402D91ADF8E for ; Wed, 20 Nov 2013 07:50:27 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9D0BCF24094 for ; Wed, 20 Nov 2013 10:50:11 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id gWddG2wy025J for ; Wed, 20 Nov 2013 10:50:10 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9DB56F24092 for ; Wed, 20 Nov 2013 10:50:10 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Nov 2013 10:49:56 -0500 Message-Id: To: perpass Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [perpass] RSA-OAEP 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, 20 Nov 2013 15:50:29 -0000 We have known for a ver long time that PKCS #1 Version 1.5 (see RFC = 2313) is vulnerable to adaptive chosen ciphertext attacks when applied = for encryption purposes. Exploitation reveals the result of a = particular RSA decryption, requires access to an oracle which will = respond to a hundreds of thousands of ciphertexts), which are = constructed adaptively in response to previously-received replies = providing information on the successes or failures of attempted = decryption operations. As a result, the attack appears significantly = less feasible to perpetrate in store-and-forward environments than for = interactive ones. PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to = address this situation, but we have seen very little movement toward = RSA-OAEP. While we are reviewing algorithm choices in light of the = pervasive surveillance situation, I think we should take the time to = address known vulnerabilities like this one. If we don't, then we are = leaving an partially open door for a well funded attacker. Russ= From wilton@isoc.org Wed Nov 20 08:03:33 2013 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 7F44A1AE47B for ; Wed, 20 Nov 2013 08:03:33 -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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaclXFql3GhA for ; Wed, 20 Nov 2013 08:03:31 -0800 (PST) Received: from smtp110.iad3a.emailsrvr.com (smtp110.iad3a.emailsrvr.com [173.203.187.110]) by ietfa.amsl.com (Postfix) with ESMTP id 173AD1AE473 for ; Wed, 20 Nov 2013 08:03:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B0FEF2B8343; Wed, 20 Nov 2013 11:03:24 -0500 (EST) X-Virus-Scanned: OK Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 3C6052B8345; Wed, 20 Nov 2013 11:03:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_CE530BE6-CFF9-44B6-8AC2-BD859D702D96"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Wed, 20 Nov 2013 16:03:15 +0000 Message-Id: <25A31A3E-1BB2-4FA6-ADEC-42B0E511F5DE@isoc.org> References: To: Russ Housley X-Mailer: Apple Mail (2.1283) Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 16:03:33 -0000 --Apple-Mail=_CE530BE6-CFF9-44B6-8AC2-BD859D702D96 Content-Type: multipart/alternative; boundary="Apple-Mail=_2F896BC2-3607-4E63-B19D-5BF08D09FC01" --Apple-Mail=_2F896BC2-3607-4E63-B19D-5BF08D09FC01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 A vulnerability is a vulnerability. Currently foreseeable attacks may = seem unwieldy/impractical, but assuming that someone hasn't found/won't = find a viable exploitation is optimistic. R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 20 Nov 2013, at 15:49, Russ Housley wrote: > We have known for a ver long time that PKCS #1 Version 1.5 (see RFC = 2313) is vulnerable to adaptive chosen ciphertext attacks when applied = for encryption purposes. Exploitation reveals the result of a = particular RSA decryption, requires access to an oracle which will = respond to a hundreds of thousands of ciphertexts), which are = constructed adaptively in response to previously-received replies = providing information on the successes or failures of attempted = decryption operations. As a result, the attack appears significantly = less feasible to perpetrate in store-and-forward environments than for = interactive ones. >=20 > PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to = address this situation, but we have seen very little movement toward = RSA-OAEP. While we are reviewing algorithm choices in light of the = pervasive surveillance situation, I think we should take the time to = address known vulnerabilities like this one. If we don't, then we are = leaving an partially open door for a well funded attacker. >=20 > Russ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_2F896BC2-3607-4E63-B19D-5BF08D09FC01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 20 Nov 2013, at 15:49, Russ Housley wrote:

We = have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) = is vulnerable to adaptive chosen ciphertext attacks when applied for = encryption purposes.  Exploitation reveals the result of a = particular RSA decryption, requires access to an oracle which will = respond to a hundreds of thousands of ciphertexts), which are = constructed adaptively in response to previously-received replies = providing information on the successes or failures of attempted = decryption operations.  As a result, the attack appears = significantly less feasible to perpetrate in store-and-forward = environments than for interactive ones.

PKCS #1 Version 2.0 and = Version 2.1 (see RFC 3447) include RSA-OAEP to address this situation, = but we have seen very little movement toward RSA-OAEP.  While we = are reviewing algorithm choices in light of the pervasive surveillance = situation, I think we should take the time to address known = vulnerabilities like this one.  If we don't, then we are leaving an = partially open door for a well funded = attacker.

Russ
_______________________________________________perpass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_2F896BC2-3607-4E63-B19D-5BF08D09FC01-- --Apple-Mail=_CE530BE6-CFF9-44B6-8AC2-BD859D702D96 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTIwMTYwMzE2WjAjBgkqhkiG9w0BCQQxFgQUfrD81wir0SQybazQEldn Zz2rfAEwdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBABpZasgt0qKBq/1TsjEGX6is Wdn7q5ZfE6MN1yqgvYpAD2VCJCGx0i36EZUh4MtbrPXydmu3HtIkhDHnmHJ80HKzbHmu6VV3GtKa x+Rm9hwjxg4guYljDm5H6EIph2QgiGgUcFdE7QMEXvjKPFXNPF9umb/t/TV7ME3BDXlT6sqrI1EA s/H+jTpiGKVQIEhIl0hcZ0uuvPXngNQaRVgZ5fjeWiZW/523KOWG4H+PeiC9fxsZll+UpSlBCZjr aUJk2Ia7zft8OJsfVJpBqkMvsjjwlf9432wSXkhmsH+Ghl2P465ny5so549SUwOOgwrszAmnQwRv VrNirEU0+0ufo8wAAAAAAAA= --Apple-Mail=_CE530BE6-CFF9-44B6-8AC2-BD859D702D96-- From rlb@ipv.sx Wed Nov 20 08:09:45 2013 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 405811AE3FC for ; Wed, 20 Nov 2013 08:09:45 -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 ordkWgkSzh_d for ; Wed, 20 Nov 2013 08:09:43 -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 D6F141AE01B for ; Wed, 20 Nov 2013 08:09:42 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so5132030oah.15 for ; Wed, 20 Nov 2013 08:09:36 -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=53O5nc+GGwAjzGDqRmmr9K0KDG5jAqHTn/QF227dT/A=; b=LpgLt3X+K9AanLycOUG87Dr7evDgTnTNd9JLOj/fIN0rZlxxYU2A1Nwl+Uwe2aU3W8 UVOM52BSrH/d8rQOWFLyHiIN+tfA9mmrzgA4Jx3IWCqbFF84WxTyO/6MUnheNAOAcPkd 3IhWNEpApssMIMz+eedAztSJhcx+r4yqDbsbZoZSMsCD5s2LkW/BrqGiRNHxE/QlU9qU x7GZCivNER/paRbgvhYzwxJac5C72PDwA2c2Jtq4xOCmt7l4wZfBd4LX1qQ6Lmw5wpyA 8mFQmaTb35x2XzJ0g44YXxxr0PwooQJVcj9zDJUqKzScIyxl4eytgOWRuxpLIEaGdZMx 3Y7w== X-Gm-Message-State: ALoCoQkNBorW0VUDREMCQ5GbnYPSb3Ou+jrac6iUE3VtEC3BUnx7RgogS4V5Xq+0HK5jvM9DPsHI MIME-Version: 1.0 X-Received: by 10.60.63.141 with SMTP id g13mr1120812oes.60.1384963776408; Wed, 20 Nov 2013 08:09:36 -0800 (PST) Received: by 10.60.31.74 with HTTP; Wed, 20 Nov 2013 08:09:36 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 11:09:36 -0500 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=001a11c1db34eb7ed104eb9e0196 Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 16:09:45 -0000 --001a11c1db34eb7ed104eb9e0196 Content-Type: text/plain; charset=ISO-8859-1 What are you proposing be done, besides supporting OAEP in new specs or back-porting it to old ones? In order to make people use OAEP, we would need to call in the protocol police. On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley wrote: > We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) > is vulnerable to adaptive chosen ciphertext attacks when applied for > encryption purposes. Exploitation reveals the result of a particular RSA > decryption, requires access to an oracle which will respond to a hundreds > of thousands of ciphertexts), which are constructed adaptively in response > to previously-received replies providing information on the successes or > failures of attempted decryption operations. As a result, the attack > appears significantly less feasible to perpetrate in store-and-forward > environments than for interactive ones. > > PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to > address this situation, but we have seen very little movement toward > RSA-OAEP. While we are reviewing algorithm choices in light of the > pervasive surveillance situation, I think we should take the time to > address known vulnerabilities like this one. If we don't, then we are > leaving an partially open door for a well funded attacker. > > Russ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --001a11c1db34eb7ed104eb9e0196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What are you proposing be done, besides supporting OAEP in= new specs or back-porting it to old ones?=A0 In order to make people use O= AEP, we would need to call in the protocol police.


On Wed, Nov 20, 2013 at 10:49 AM, Russ H= ousley <housley@vigilsec.com> wrote:
We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) i= s vulnerable to adaptive chosen ciphertext attacks when applied for encrypt= ion purposes. =A0Exploitation reveals the result of a particular RSA decryp= tion, requires access to an oracle which will respond to a hundreds of thou= sands of ciphertexts), which are constructed adaptively in response to prev= iously-received replies providing information on the successes or failures = of attempted decryption operations. =A0As a result, the attack appears sign= ificantly less feasible to perpetrate in store-and-forward environments tha= n for interactive ones.

PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to addr= ess this situation, but we have seen very little movement toward RSA-OAEP. = =A0While we are reviewing algorithm choices in light of the pervasive surve= illance situation, I think we should take the time to address known vulnera= bilities like this one. =A0If we don't, then we are leaving an partiall= y open door for a well funded attacker.

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

--001a11c1db34eb7ed104eb9e0196-- From housley@vigilsec.com Wed Nov 20 09:08:49 2013 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 906131ADF47 for ; Wed, 20 Nov 2013 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-TxQnNk_QLO for ; Wed, 20 Nov 2013 09:08:47 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id DCFC51AE0D0 for ; Wed, 20 Nov 2013 09:08:46 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 26F7DF2408E; Wed, 20 Nov 2013 12:08:31 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id vGGg4F7k08Qb; Wed, 20 Nov 2013 12:08:08 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E5C69F24094; Wed, 20 Nov 2013 12:08:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-39-785665506 From: Russ Housley In-Reply-To: Date: Wed, 20 Nov 2013 12:07:54 -0500 Message-Id: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.1085) Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 17:08:49 -0000 --Apple-Mail-39-785665506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I do not know of any place where RSA-OAEP has been called out as the = mandatory to implement algorithm, but there are many places where PKCS#1 = v1.5 still enjoys this status. I suggest we make RSA-OAEP the mandatory = to implement algorithm in our specifications. Russ On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: > What are you proposing be done, besides supporting OAEP in new specs = or back-porting it to old ones? In order to make people use OAEP, we = would need to call in the protocol police. >=20 >=20 > On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley = wrote: > We have known for a ver long time that PKCS #1 Version 1.5 (see RFC = 2313) is vulnerable to adaptive chosen ciphertext attacks when applied = for encryption purposes. Exploitation reveals the result of a = particular RSA decryption, requires access to an oracle which will = respond to a hundreds of thousands of ciphertexts), which are = constructed adaptively in response to previously-received replies = providing information on the successes or failures of attempted = decryption operations. As a result, the attack appears significantly = less feasible to perpetrate in store-and-forward environments than for = interactive ones. >=20 > PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to = address this situation, but we have seen very little movement toward = RSA-OAEP. While we are reviewing algorithm choices in light of the = pervasive surveillance situation, I think we should take the time to = address known vulnerabilities like this one. If we don't, then we are = leaving an partially open door for a well funded attacker. >=20 > Russ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-39-785665506 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I do not know of any place where RSA-OAEP has been called out as the mandatory to implement algorithm, but there are many places where PKCS#1 v1.5 still enjoys this status.  I suggest we make RSA-OAEP the mandatory to implement algorithm in our specifications.

Russ


On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote:

What are you proposing be done, besides supporting OAEP in new specs or back-porting it to old ones?  In order to make people use OAEP, we would need to call in the protocol police.


On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley <housley@vigilsec.com> wrote:
We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) is vulnerable to adaptive chosen ciphertext attacks when applied for encryption purposes.  Exploitation reveals the result of a particular RSA decryption, requires access to an oracle which will respond to a hundreds of thousands of ciphertexts), which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations.  As a result, the attack appears significantly less feasible to perpetrate in store-and-forward environments than for interactive ones.

PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to address this situation, but we have seen very little movement toward RSA-OAEP.  While we are reviewing algorithm choices in light of the pervasive surveillance situation, I think we should take the time to address known vulnerabilities like this one.  If we don't, then we are leaving an partially open door for a well funded attacker.

Russ
_______________________________________________
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

--Apple-Mail-39-785665506-- From rlb@ipv.sx Wed Nov 20 09:18:31 2013 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 DCA2B1AE0BC for ; Wed, 20 Nov 2013 09:18:31 -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 dqG0OmWdJEkv for ; Wed, 20 Nov 2013 09:18:30 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E69521AE0B1 for ; Wed, 20 Nov 2013 09:18:29 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so5489648obb.17 for ; Wed, 20 Nov 2013 09:18:23 -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=O13E4RksHGatAgQn1F2t4yMEF2RdVwMLNcdk933+NvA=; b=jzbKVzjGYmId74YYqJDzjyNoxnN9dWtcQJTEjttLDSnLBRuk7SJs1LsPnKvI897fZB M09VfFnSzi40i9NJeq51o/jQg/HflgiyhINNMNpSwUgzQBXCS1K8VSk4DdojxjpCQIp5 RPcevP2fRCDP5wc9h4IhuyKd+sXOu+2gRNzGiywz7JAFe8LhCcLgwboGcUklK0qahGdQ H77KOec6pqvztYV5lnAQ5FS3bNdicF9hDUwu5VZP8VGU492OgkLZmWvgCucfratdctYw 4LV5OvHJbFBA13wdiGiNdE77pAUGlwKfF4vQAux9+LGc/+aUQXK31zxfsIIs6/mw8gX7 ZCIg== X-Gm-Message-State: ALoCoQnkyu2nemImFgbe2D2Slyv1atpMFtEM+9HgMf2YxBZ+hN3lnWarqG6krqGRLlOw3/6IA/lO MIME-Version: 1.0 X-Received: by 10.182.153.41 with SMTP id vd9mr260871obb.87.1384967903357; Wed, 20 Nov 2013 09:18:23 -0800 (PST) Received: by 10.60.31.74 with HTTP; Wed, 20 Nov 2013 09:18:23 -0800 (PST) In-Reply-To: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> References: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> Date: Wed, 20 Nov 2013 12:18:23 -0500 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=089e013a1046e7c74904eb9ef731 Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 17:18:32 -0000 --089e013a1046e7c74904eb9ef731 Content-Type: text/plain; charset=ISO-8859-1 That makes sense. Would you say the same in the signature domain, i.e., PKCS#1 v1.5 -> PSS? On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley wrote: > I do not know of any place where RSA-OAEP has been called out as the > mandatory to implement algorithm, but there are many places where PKCS#1 > v1.5 still enjoys this status. I suggest we make RSA-OAEP the mandatory to > implement algorithm in our specifications. > > Russ > > > On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: > > What are you proposing be done, besides supporting OAEP in new specs or > back-porting it to old ones? In order to make people use OAEP, we would > need to call in the protocol police. > > > On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley wrote: > >> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) >> is vulnerable to adaptive chosen ciphertext attacks when applied for >> encryption purposes. Exploitation reveals the result of a particular RSA >> decryption, requires access to an oracle which will respond to a hundreds >> of thousands of ciphertexts), which are constructed adaptively in response >> to previously-received replies providing information on the successes or >> failures of attempted decryption operations. As a result, the attack >> appears significantly less feasible to perpetrate in store-and-forward >> environments than for interactive ones. >> >> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to >> address this situation, but we have seen very little movement toward >> RSA-OAEP. While we are reviewing algorithm choices in light of the >> pervasive surveillance situation, I think we should take the time to >> address known vulnerabilities like this one. If we don't, then we are >> leaving an partially open door for a well funded attacker. >> >> Russ >> _______________________________________________ >> 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 > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --089e013a1046e7c74904eb9ef731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That makes sense.=A0 Would you say the same in the signatu= re domain, i.e., PKCS#1 v1.5 -> PSS?


On Wed, Nov 20, 2013 at 12:07 PM, Russ = Housley <housley@vigilsec.com> wrote:
I do not= know of any place where RSA-OAEP has been called out as the mandatory to i= mplement algorithm, but there are many places where PKCS#1 v1.5 still enjoy= s this status. =A0I suggest we make RSA-OAEP the mandatory to implement alg= orithm in our specifications.

Russ


On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote:
What are you proposing be= done, besides supporting OAEP in new specs or back-porting it to old ones?= =A0 In order to make people use OAEP, we would need to call in the protocol= police.


On Wed, Nov 20, 2013 at 10:49 AM, Russ H= ousley <housley@vigilsec.com> wrote:
We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) i= s vulnerable to adaptive chosen ciphertext attacks when applied for encrypt= ion purposes. =A0Exploitation reveals the result of a particular RSA decryp= tion, requires access to an oracle which will respond to a hundreds of thou= sands of ciphertexts), which are constructed adaptively in response to prev= iously-received replies providing information on the successes or failures = of attempted decryption operations. =A0As a result, the attack appears sign= ificantly less feasible to perpetrate in store-and-forward environments tha= n for interactive ones.

PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to addr= ess this situation, but we have seen very little movement toward RSA-OAEP. = =A0While we are reviewing algorithm choices in light of the pervasive surve= illance situation, I think we should take the time to address known vulnera= bilities like this one. =A0If we don't, then we are leaving an partiall= y open door for a well funded attacker.

Russ
_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
= perpass@ietf.org<= br>https://www.ietf.org/mailman/listinfo/perpass


________________________= _______________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--089e013a1046e7c74904eb9ef731-- From stephen.farrell@cs.tcd.ie Wed Nov 20 09:25:41 2013 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 B0CDE1AE4D0 for ; Wed, 20 Nov 2013 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAVFdEQdUST2 for ; Wed, 20 Nov 2013 09:25:39 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2B01AE4CE for ; Wed, 20 Nov 2013 09:25:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC834BE63; Wed, 20 Nov 2013 17:25:32 +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 g0iUTTHPZZzJ; Wed, 20 Nov 2013 17:25:32 +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 C7AA7BE60; Wed, 20 Nov 2013 17:25:32 +0000 (GMT) Message-ID: <528CF08D.7070400@cs.tcd.ie> Date: Wed, 20 Nov 2013 17:25:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Richard Barnes , Russ Housley References: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 17:25:41 -0000 I agree that OAEP is better and would be a better MTI. But that's been tried, and each time, current deployment considerations trumped it and specs choose pkcs#1v1.5. I may well be wrong but I suspect someone putting in a bit of concerted work on coding will be needed before OAEP will get accepted, esp since the attacks are all million-message attacks so far. Or am I out of date in terms of which libraries now have OAEP in 'em? Lastly, while that is a worthwhile and good security thing to do, I think the linkage to pervasive monitoring isn't that strong, so maybe this'd be a better topic for the saag list? S On 11/20/2013 05:18 PM, Richard Barnes wrote: > That makes sense. Would you say the same in the signature domain, i.e., > PKCS#1 v1.5 -> PSS? > > > On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley wrote: > >> I do not know of any place where RSA-OAEP has been called out as the >> mandatory to implement algorithm, but there are many places where PKCS#1 >> v1.5 still enjoys this status. I suggest we make RSA-OAEP the mandatory to >> implement algorithm in our specifications. >> >> Russ >> >> >> On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: >> >> What are you proposing be done, besides supporting OAEP in new specs or >> back-porting it to old ones? In order to make people use OAEP, we would >> need to call in the protocol police. >> >> >> On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley wrote: >> >>> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) >>> is vulnerable to adaptive chosen ciphertext attacks when applied for >>> encryption purposes. Exploitation reveals the result of a particular RSA >>> decryption, requires access to an oracle which will respond to a hundreds >>> of thousands of ciphertexts), which are constructed adaptively in response >>> to previously-received replies providing information on the successes or >>> failures of attempted decryption operations. As a result, the attack >>> appears significantly less feasible to perpetrate in store-and-forward >>> environments than for interactive ones. >>> >>> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to >>> address this situation, but we have seen very little movement toward >>> RSA-OAEP. While we are reviewing algorithm choices in light of the >>> pervasive surveillance situation, I think we should take the time to >>> address known vulnerabilities like this one. If we don't, then we are >>> leaving an partially open door for a well funded attacker. >>> >>> Russ >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > From housley@vigilsec.com Wed Nov 20 11:01:56 2013 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 8053D1AE120 for ; Wed, 20 Nov 2013 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lZnZsIcOyme0 for ; Wed, 20 Nov 2013 11:01:54 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B51AE014 for ; Wed, 20 Nov 2013 11:01:53 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6CDC8F24091; Wed, 20 Nov 2013 14:01:40 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Tvq7DCDm8PFb; Wed, 20 Nov 2013 14:01:15 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3C1F2F2408E; Wed, 20 Nov 2013 14:01:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 20 Nov 2013 14:00:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43170B9E-3DBB-4C90-A0E6-8802BB879EB6@vigilsec.com> References: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> To: Richard Barnes X-Mailer: Apple Mail (2.1085) Cc: perpass Subject: Re: [perpass] RSA-OAEP 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, 20 Nov 2013 19:01:56 -0000 OpenSSL supports RSA-OAEP and RSA-PSS. See the latest documentation for = the 'cms' command for details. At present, PSS-only and OAEP-only keys = in certificates are not supported. Russ On 11/20/2013 05:18 PM, Richard Barnes wrote: > That makes sense. Would you say the same in the signature domain, = i.e., > PKCS#1 v1.5 -> PSS? >=20 >=20 > On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley = wrote: >=20 >> I do not know of any place where RSA-OAEP has been called out as the >> mandatory to implement algorithm, but there are many places where = PKCS#1 >> v1.5 still enjoys this status. I suggest we make RSA-OAEP the = mandatory to >> implement algorithm in our specifications. >>=20 >> Russ >>=20 >>=20 >> On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: >>=20 >> What are you proposing be done, besides supporting OAEP in new specs = or >> back-porting it to old ones? In order to make people use OAEP, we = would >> need to call in the protocol police. >>=20 >>=20 >> On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley = wrote: >>=20 >>> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC = 2313) >>> is vulnerable to adaptive chosen ciphertext attacks when applied for >>> encryption purposes. Exploitation reveals the result of a = particular RSA >>> decryption, requires access to an oracle which will respond to a = hundreds >>> of thousands of ciphertexts), which are constructed adaptively in = response >>> to previously-received replies providing information on the = successes or >>> failures of attempted decryption operations. As a result, the = attack >>> appears significantly less feasible to perpetrate in = store-and-forward >>> environments than for interactive ones. >>>=20 >>> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP = to >>> address this situation, but we have seen very little movement toward >>> RSA-OAEP. While we are reviewing algorithm choices in light of the >>> pervasive surveillance situation, I think we should take the time to >>> address known vulnerabilities like this one. If we don't, then we = are >>> leaving an partially open door for a well funded attacker. >>>=20 >>> Russ >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 From nweaver@icsi.berkeley.edu Wed Nov 20 12:43:01 2013 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 6A8F91AE25D for ; Wed, 20 Nov 2013 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.525, 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 6AY1qOCp__TP for ; Wed, 20 Nov 2013 12:43:00 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9E41AE253 for ; Wed, 20 Nov 2013 12:43:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DABE72C4044 for ; Wed, 20 Nov 2013 12:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dUJmB7-SWFaV; Wed, 20 Nov 2013 12:42:53 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 77C362C4042; Wed, 20 Nov 2013 12:42:53 -0800 (PST) From: Nicholas Weaver Content-Type: multipart/signed; boundary="Apple-Mail=_976987D6-37C1-47EA-A2C7-4B8A65DD75F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 20 Nov 2013 12:42:53 -0800 Message-Id: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> To: perpass Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Nicholas Weaver Subject: [perpass] A reminder, the Network is the Enemy... 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, 20 Nov 2013 20:43:01 -0000 --Apple-Mail=_976987D6-37C1-47EA-A2C7-4B8A65DD75F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As a reminder, the network is the enemy. = http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has= -been-turned-into-a-weapon/ We need to consider the network transporting our data as an active = attacker, not just one which can observer/wiretap, but one that is both = outside our control and willing to serve as a vehicle for attacking the = end systems. Its always been this way, but the recent behavior of the = NSA/GCHQ has ensured that the pleasant fiction of the network's lack of = hostility is no longer acceptable. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_976987D6-37C1-47EA-A2C7-4B8A65DD75F3 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 iQIcBAEBCgAGBQJSjR7NAAoJEG2B1w+SDi/ufKgP/ihfhAGQCXG1W2HbwsGOax5B ANYvD8WeBWbuB3JryWSe3mXExouqLxCV4m6zTt16VylaV3REHr8XIEC063T7FsOJ eBvbItA7cmqZBsIm5mgFvIjn0rXVOV5XJlomnWFwI7CQ31NSjGxcaqLQnWenCjsi bF5PtDlW3keMQ/JGYe1VRZ6LGxO1jU99z+q5dhH/yPXT8pRXLsY3dygFHyzAhNCy ZOfxmeGld7DOxWlr1bIZxinTXTPl/rGPhReDe8r3E9/UNx3og0FyYaVuStBGw242 Cs5g1f3oCEhwk4R25lU0h/Rt+Tq0f/BXupem4Lkopvnd06uk+ZjavOnfE91B4Vdq mYZsuWPvCDxZ/Q9XDoFePnvXJrnwP1oPABedbN65dRv61yTdt5al5bR2qfSXqxt7 eg88iczoItCxOly1012z4b5h74i3IRJ8Ga8Nw3ADgDBlLgxONQCY3Ah2u67fRMm7 oYDAzkr5IJFT2r7Y/abmE5OiC4q6GiPPh7ubu/BsZ4TA0NqAEO/IP/g5bLNVBEQO wkTZ2xyeA9rI2fHFRpPFzJ0XPwxy3aWhsA830j8oFNrfjGMTRsz0rIy2UkN65gZH mgGLOaVoc7bevL5XuehzvaihsXjVMnXwzOxaUPIevntr8DjYGTA5FDopwm+wrNlB NmF769Jp4V2LMDhvaOUP =t/3v -----END PGP SIGNATURE----- --Apple-Mail=_976987D6-37C1-47EA-A2C7-4B8A65DD75F3-- From mellon@fugue.com Wed Nov 20 12:57:55 2013 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 003F11AE13E for ; Wed, 20 Nov 2013 12:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 2IF_V2JuRaUI for ; Wed, 20 Nov 2013 12:57:52 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CF3311AE159 for ; Wed, 20 Nov 2013 12:57:52 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 378462380CB4; Wed, 20 Nov 2013 15:57:44 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> Date: Wed, 20 Nov 2013 15:57:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1822) Cc: perpass Subject: Re: [perpass] A reminder, the Network is the Enemy... 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, 20 Nov 2013 20:57:55 -0000 On Nov 20, 2013, at 3:42 PM, Nicholas Weaver = wrote: > We need to consider the network transporting our data as an active = attacker, not just one which can observer/wiretap, but one that is both = outside our control and willing to serve as a vehicle for attacking the = end systems. Its always been this way, but the recent behavior of the = NSA/GCHQ has ensured that the pleasant fiction of the network's lack of = hostility is no longer acceptable. The thing that hit me from this article that I really just hadn't fully = understood previously is that any web site that displays personalized = information per user that can be easily parsed now serves as a way to do = a targeted attack on an individual or on individuals who work for an = organization. So if you read slashdot or tumblr, for example, both of which display = personally identifying information on their home pages if you are logged = in, then an MiTM attacker can listen on the link the server is connected = to and trigger on HTTP responses to you, and then attack you = specifically, without revealing the attack to anyone else. So this starts as a pervasive passive attack, essentially, and then = turns into an active attack only for the targeted user or users. This can be mitigated in several ways=97obviously https-everywhere will = address the problem, but also if the web site simply doesn't display = personally identifying information in their outgoing traffic, then the = passive attack isn't possible. Of course, if the attacker knows your IP address, then they don't need = to scrape the HTTP response, but attackers don't necessarily have that = information, particularly if what they are doing is illegal in the = country you live in. So there's real value in being aware of this = threat model and trying to mitigate it. Specifically, maybe the IETF (or someone) should be recommending that = web sites not display personally identifying information about logged-in = users except over TLS connections. Certainly we should document this = threat model and try to raise awareness about it. From kathleen.moriarty@emc.com Wed Nov 20 14:08:57 2013 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 9F2E81AE028 for ; Wed, 20 Nov 2013 14:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 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.525, 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 FRuRuFk96h3H for ; Wed, 20 Nov 2013 14:08:55 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id D42FC1AE066 for ; Wed, 20 Nov 2013 14:08:54 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAKM8gCx024189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Nov 2013 17:08:42 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAKM8gCx024189 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1384985322; bh=5ucHVbpzZ+wCAh6a0KLAtvyjrlY=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; b=YUpFrzKKKkP6mzYWaelSGSIHf2x9AlCiqmFEtR9t8NYl5O0krGCYd1EZWQCUe+Siv bg9QNBKxqy+hPEWGRqybTlBflu21+EB+7FkORLQi4sGjOnrLftdpkk0BbNSNsmnkyb D0+ewPe//p5ElTn0r18AWIiQ/SAGoiw7I6ejX+ac= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAKM8gCx024189 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Wed, 20 Nov 2013 17:08:27 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAKM8Rii002305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Nov 2013 17:08:27 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Wed, 20 Nov 2013 17:07:20 -0500 From: "Moriarty, Kathleen" To: "perpass@ietf.org" Date: Wed, 20 Nov 2013 17:08:25 -0500 Thread-Topic: Crypto scorecard released by EFF Thread-Index: Ac7mPKeZoH9zdXnTSC+oXv+WWA5U2g== Message-ID: 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_F5063677821E3B4F81ACFB7905573F2406540952D1MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Subject: [perpass] Crypto scorecard released by EFF 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, 20 Nov 2013 22:08:57 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406540952D1MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable EFF released a 'report card' for encryption capabilities of 18 companies an= d may be of interest to many of you. It is meant as a positive encourageme= nt to other companies to expand crypto capabilities per the web link. http://threatpost.com/eff-scorecard-shows-crypto-leaders-and-laggards/10298= 7 Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F2406540952D1MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

EFF released a &= #8216;report card’ for encryption capabilities of 18 companies and ma= y be of interest to many of you.  It is meant as a positive encouragem= ent to other companies to expand crypto capabilities per the web link.=

 

http://threatpost.com/eff-scorecard-shows-crypto-leaders-and-la= ggards/102987

 

<= p class=3DMsoNormal>Best regards,

Kathle= en

 

= --_000_F5063677821E3B4F81ACFB7905573F2406540952D1MX15Acorpemcc_-- From stephen.farrell@cs.tcd.ie Wed Nov 20 14:17:07 2013 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 5990B1AE150 for ; Wed, 20 Nov 2013 14:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCZR1MHq-pBT for ; Wed, 20 Nov 2013 14:17:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC981AE01C for ; Wed, 20 Nov 2013 14:17:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 95E30BE68 for ; Wed, 20 Nov 2013 22:16:57 +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 tdhEesfdzhGi for ; Wed, 20 Nov 2013 22:16:56 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.78.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E132EBE63 for ; Wed, 20 Nov 2013 22:16:55 +0000 (GMT) Message-ID: <528D34D7.1010303@cs.tcd.ie> Date: Wed, 20 Nov 2013 22:16:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] "Its an attack" BCP draft 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, 20 Nov 2013 22:17:07 -0000 Hi all, Following up on item 3a from the status/plan mail [1] I sent last week, Hannes and myself have written up an I-D [2] that tries to capture the consensus in the room from the Vancouver tech plenary and we're proposing as a BCP. We're deliberately trying to keep this short and sweet and to not (yet) go beyond what was the gist of the hums - we think progressing e.g. the threat model or the privacy BCP or other bits of related work is liable to take longer and there's value in documenting that the IETF as a whole has consensus on the most significant bit first so those and other bits of work don't all have to re-establish that as they are processed. Hopefully we can all easily agree that that's a useful target and focus comments on whether on not we've expressed that consensus well or not. We've been bouncing versions of this around amongst the IESG and IAB for the last week, and process-wise, that has been fun already. As you'll see from section 3 of the draft, we can no longer just shoot out an RFC agreed by the IESG and IAB so the plan for this is that when Hannes and I figure this looks ready, based on your comments, then we'll ask Jari to start a 4-week IETF LC for it. When he thinks that's ok he'll start it and then we'll see how that goes. Assuming that goes well, then sometime during IESG evaluation the IAB will decide if they like the final text (or not, which'd be "interesting") and if they do then an IAB note saying "yep, we like it" will be added sometime during/after IESG evaluation before this goes to the RFC editor. In an ideal world, you'll all love the -00 already and tell us that and we'll be done with all of the above super duper process stuff by the end of the year. (Haven't we built ourselves a lovely crazy process? ;-) I really hope we don't end up with a process debate over this, since the above, silly and all as it is, should achieve the desirable outcome which is a simple BCP, approved by the IESG after an IETF LC and also supported by the IAB. The value in that is that it seems to be as close as we can get to the same setup as RFCs 1984 and 2804 which is the right kind of heritage for this one. So there is a reasonably good reason for the process-crap. Anyway, ignoring process, comments on this are welcome, so please take a read of the two pages of content and let us know what you think. If you do think its already good enough for starting an IETF last call, then saying that is useful as well. And since the IETF LC will happen on the ietf@ietf.org list, using this list for initial processing should be fine. Cheers, S. [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html [2] http://tools.ietf.org/html/draft-farrell-perpass-attack From fred@cisco.com Wed Nov 20 14:20:22 2013 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 27A4E1AE1F8 for ; Wed, 20 Nov 2013 14:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.025 X-Spam-Level: X-Spam-Status: No, score=-115.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 GBhqObQk8XOU for ; Wed, 20 Nov 2013 14:20:20 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3151AE1F4 for ; Wed, 20 Nov 2013 14:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7605; q=dns/txt; s=iport; t=1384986014; x=1386195614; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h3PnvO1zSEyHP9Ft6kjMZWlVjQbHXv+EATzD58HDF0M=; b=gW17l0ODTLymt0QAPaQLb+bkCymZIWK43fqd5hUYIaYOKUTW3P+faGsw v00YFgC5eRYtoqbhcpz8/y92c4hnbulgza2WhVW3FiTsH5eH65s3QG5Ws 0kv4xm26iPKh7aOVxRIeNycN0e9xloFE1QQbIoaa0TeFlFgb0HXM2/+cM 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAJ80jVKtJV2b/2dsb2JhbABZgkNEOFOrS5FhToEaFnSCJQEBAQMBAQEBagELBQsCAQhGJwslAQEEDgUOh20GDcBoF49nBAeDIIESA5AwgTGGMYEvkF6DKIIq X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="asc'?scan'208,217";a="283466370" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 20 Nov 2013 22:20:14 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAKMKDfA006628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 22:20:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 16:20:13 -0600 From: "Fred Baker (fred)" To: "Moriarty, Kathleen" Thread-Topic: [perpass] Crypto scorecard released by EFF Thread-Index: Ac7mPKeZoH9zdXnTSC+oXv+WWA5U2gANFF+A Date: Wed, 20 Nov 2013 22:20:13 +0000 Message-ID: References: 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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_623E79BC-9449-4DBE-8B84-5C8B6983D930"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] Crypto scorecard released by EFF 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, 20 Nov 2013 22:20:22 -0000 --Apple-Mail=_623E79BC-9449-4DBE-8B84-5C8B6983D930 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB6BBAB-DFA2-4144-94F1-497E05E78FEC" --Apple-Mail=_BFB6BBAB-DFA2-4144-94F1-497E05E78FEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2013, at 2:08 PM, "Moriarty, Kathleen" = wrote: > EFF released a =91report card=92 for encryption capabilities of 18 = companies and may be of interest to many of you. It is meant as a = positive encouragement to other companies to expand crypto capabilities = per the web link. > =20 > = http://threatpost.com/eff-scorecard-shows-crypto-leaders-and-laggards/1029= 87 =20 Hmm. A chart with rows and columns. The rows have logos on them. The = columns are unidentified... > Best regards, > Kathleen > =20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --Apple-Mail=_BFB6BBAB-DFA2-4144-94F1-497E05E78FEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 20, 2013, = at 2:08 PM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>= ; wrote:

EFF released a =91report card=92 for encryption = capabilities of 18 companies and may be of interest to many of = you.  It is meant as a positive encouragement to other companies to = expand crypto capabilities per the web link.
 
 
Best regards,
"We are learning to do a great many = clever things...The next great task
will be to learn not to do = them."

- G. K. Chesterton = (1874-1936)




= --Apple-Mail=_BFB6BBAB-DFA2-4144-94F1-497E05E78FEC-- --Apple-Mail=_623E79BC-9449-4DBE-8B84-5C8B6983D930 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 iD8DBQFSjTWdbjEdbHIsm0MRAsgFAJ0S04yUBRNtq5uKu3jZFrhovgPA1ACg7BvB HrcZOLQeOckOFJqYSVbJMO0= =NxTA -----END PGP SIGNATURE----- --Apple-Mail=_623E79BC-9449-4DBE-8B84-5C8B6983D930-- From kathleen.moriarty@emc.com Wed Nov 20 14:24:16 2013 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 8FF1A1AE178 for ; Wed, 20 Nov 2013 14:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 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.525, 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 xZkqKkrBeYCD for ; Wed, 20 Nov 2013 14:24:14 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1804B1AE084 for ; Wed, 20 Nov 2013 14:24:13 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAKMNw2r028491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 17:23:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAKMNw2r028491 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1384986239; bh=8VrKkE0nyVmCcBD1RQZtS0G00CU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=bjd6DLR+JxFmF2tF9kOz3pQgk4/p3H+/tBvhPN/xkE262KkF8FF993HA3G/PijFtp V7mzTlLJN1uqVVlkpLkGd071WB0ftoGOgRT2ngPwg6IjaeszsPfmqxVQ03secEBjc+ K5lDX6SG2HLnjR5Sj+V2KQlHA5DbcH3nvxweef/I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAKMNw2r028491 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 20 Nov 2013 17:23:41 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAKMNepQ001123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 17:23:41 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Wed, 20 Nov 2013 17:23:40 -0500 From: "Moriarty, Kathleen" To: "Fred Baker (fred)" Date: Wed, 20 Nov 2013 17:23:39 -0500 Thread-Topic: [perpass] Crypto scorecard released by EFF Thread-Index: Ac7mPKeZoH9zdXnTSC+oXv+WWA5U2gANFF+AAAyJV4A= Message-ID: References: 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_F5063677821E3B4F81ACFB7905573F2406540952D6MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Cc: "perpass@ietf.org" Subject: Re: [perpass] Crypto scorecard released by EFF 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, 20 Nov 2013 22:24:16 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406540952D6MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had the same problem and had to let the page load. The survey is trackin= g the following in the columns: Encrypts data center links Supports HTTPS HTTPS Strict (HSTS) Forward Secrecy STARTTLS Best regards, Kathleen From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: Wednesday, November 20, 2013 5:20 PM To: Moriarty, Kathleen Cc: perpass@ietf.org Subject: Re: [perpass] Crypto scorecard released by EFF On Nov 20, 2013, at 2:08 PM, "Moriarty, Kathleen" > wrote: EFF released a 'report card' for encryption capabilities of 18 companies an= d may be of interest to many of you. It is meant as a positive encourageme= nt to other companies to expand crypto capabilities per the web link. http://threatpost.com/eff-scorecard-shows-crypto-leaders-and-laggards/10298= 7 Hmm. A chart with rows and columns. The rows have logos on them. The column= s are unidentified... Best regards, Kathleen _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --_000_F5063677821E3B4F81ACFB7905573F2406540952D6MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I had the= same problem and had to let the page load.  The survey is tracking th= e following in the columns:

Encrypts data center links

Supports HTTPS

HTTPS St= rict (HSTS)

Forward Secrec= y

STARTTLS

 

Best regards,

Kathleen

 

From: Fred Baker (fred) [mai= lto:fred@cisco.com]
Sent: Wednesday, November 20, 2013 5:20 PMTo: Moriarty, Kathleen
Cc: perpass@ietf.org
Subjec= t: Re: [perpass] Crypto scorecard released by EFF

=

 

=  



 =

Hmm. A chart with rows and column= s. The rows have logos on them. The columns are unidentified...<= /span>



Best regards,

Kathl= een

 <= /p>

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

 

-----------------------------------
"We are learning to do a grea= t many clever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

 <= /span>



<= /div>

 

= --_000_F5063677821E3B4F81ACFB7905573F2406540952D6MX15Acorpemcc_-- From mellon@fugue.com Wed Nov 20 14:35:58 2013 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 238851AE078 for ; Wed, 20 Nov 2013 14:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 R59E6MoMciGA for ; Wed, 20 Nov 2013 14:35:57 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EDA1E1AE145 for ; Wed, 20 Nov 2013 14:35:56 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 09AB22380CB4; Wed, 20 Nov 2013 17:35:48 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Wed, 20 Nov 2013 17:35:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1822) Cc: "perpass@ietf.org" , "Moriarty, Kathleen" Subject: Re: [perpass] Crypto scorecard released by EFF 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, 20 Nov 2013 22:35:58 -0000 On Nov 20, 2013, at 5:20 PM, Fred Baker (fred) wrote: > Hmm. A chart with rows and columns. The rows have logos on them. The = columns are unidentified... You have to go to the EFF article. Thanks for the link, Kathleen. I = discovered a couple of examples of this problem last night; it's good to = have a more complete reckoning. From brian.e.carpenter@gmail.com Wed Nov 20 14:41:13 2013 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 2AFF91AE512 for ; Wed, 20 Nov 2013 14:41:13 -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 hRuJFZA1Qe3c for ; Wed, 20 Nov 2013 14:41:11 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 29D631ADF98 for ; Wed, 20 Nov 2013 14:41:11 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id z10so8682444pdj.16 for ; Wed, 20 Nov 2013 14:41:04 -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=4+L9AUaJnncvpnM4uSA9Imjwd2erDJ9yRMnJ/oyIZ9M=; b=mib+GZt1aTSL28rfIU04JHLDAZExBBK0sGesjatzwHG2CQArUPDL6YsOdo86/6e915 6Qux5wkl4s1eqSZB7vkN/dV5BSnQViF4YNWvYJnZt70MJvRSoXrOGL/O5eyZ6ufgENg4 aGddh3Jk560n3nJPZXCtOHrlxzGceFzErJwUcHM6vyfsb2VHDbqAtRWo3h+fuM2o1FIH SkB2CI889tMQC/vhCWx+MtZoBT4rlMD80CNLt7fh1AIklrORd1IaUyM+6HfuiUcqSIKk sKcylvUjzKKBPmkWZkNR7BHZpNkgUw3HwGqNCXeNSLkE9hMB5cyfLDgHxrEihJfrw70e U+CQ== X-Received: by 10.68.190.136 with SMTP id gq8mr3097473pbc.68.1384987264810; Wed, 20 Nov 2013 14:41:04 -0800 (PST) Received: from [192.168.178.20] (118.199.69.111.dynamic.snap.net.nz. [111.69.199.118]) by mx.google.com with ESMTPSA id rv9sm9857491pbc.4.2013.11.20.14.41.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 14:41:04 -0800 (PST) Message-ID: <528D3A85.5090003@gmail.com> Date: Thu, 21 Nov 2013 11:41:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Farrell References: <528D34D7.1010303@cs.tcd.ie> In-Reply-To: <528D34D7.1010303@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 22:41:13 -0000 Just do it. However, I am concerned by the 'bad actor' phrase. The problem is that it's fine as explained in the draft, but it's highly likely to be quoted out of context and thereby cause confusion. It would be safer to use a neutral term ('observer'? 'surveyor'?). Regards Brian On 21/11/2013 11:16, Stephen Farrell wrote: > Hi all, > > Following up on item 3a from the status/plan mail [1] I sent > last week, Hannes and myself have written up an I-D [2] that > tries to capture the consensus in the room from the Vancouver > tech plenary and we're proposing as a BCP. > > We're deliberately trying to keep this short and sweet and to > not (yet) go beyond what was the gist of the hums - we think > progressing e.g. the threat model or the privacy BCP or other > bits of related work is liable to take longer and there's value > in documenting that the IETF as a whole has consensus on the > most significant bit first so those and other bits of work > don't all have to re-establish that as they are processed. > Hopefully we can all easily agree that that's a useful target > and focus comments on whether on not we've expressed that > consensus well or not. > > > We've been bouncing versions of this around amongst the IESG > and IAB for the last week, and process-wise, that has been > fun already. As you'll see from section 3 of the draft, we can > no longer just shoot out an RFC agreed by the IESG and IAB so > the plan for this is that when Hannes and I figure this looks > ready, based on your comments, then we'll ask Jari to start a > 4-week IETF LC for it. When he thinks that's ok he'll start it > and then we'll see how that goes. Assuming that goes well, then > sometime during IESG evaluation the IAB will decide if they > like the final text (or not, which'd be "interesting") and if > they do then an IAB note saying "yep, we like it" will be added > sometime during/after IESG evaluation before this goes to the > RFC editor. In an ideal world, you'll all love the -00 already > and tell us that and we'll be done with all of the above super > duper process stuff by the end of the year. (Haven't we built > ourselves a lovely crazy process? ;-) > > I really hope we don't end up with a process debate over this, > since the above, silly and all as it is, should achieve the > desirable outcome which is a simple BCP, approved by the IESG > after an IETF LC and also supported by the IAB. The value in > that is that it seems to be as close as we can get to the same > setup as RFCs 1984 and 2804 which is the right kind of heritage > for this one. So there is a reasonably good reason for the > process-crap. > > > Anyway, ignoring process, comments on this are welcome, so > please take a read of the two pages of content and let us know > what you think. If you do think its already good enough for > starting an IETF last call, then saying that is useful as well. > > And since the IETF LC will happen on the ietf@ietf.org list, > using this list for initial processing should be fine. > > Cheers, > S. > > [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html > [2] http://tools.ietf.org/html/draft-farrell-perpass-attack > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From derhoermi@gmx.net Wed Nov 20 14:44:03 2013 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 66D611AE078 for ; Wed, 20 Nov 2013 14:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, 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 e_Zm3SQ_aPYZ for ; Wed, 20 Nov 2013 14:44:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E99A71AE4C6 for ; Wed, 20 Nov 2013 14:44:00 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.13.37]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MCL6r-1VrkoC1mE5-009B3q for ; Wed, 20 Nov 2013 23:43:53 +0100 From: Bjoern Hoehrmann To: Ted Lemon Date: Wed, 20 Nov 2013 23:43:36 +0100 Message-ID: References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:jNtuAeVjDCzxdj1KcDt26rgP4LuLuQmfFwAyFyPXEFtoLOjb3hv rfLE3fbab0riAi/In+bSD734mvsVkYUoPFNycPDlC8OScRnSCqnkkwW19ekDPIgGx9JmIZX FtQWFb2xz3f0ANudHMQqRsHnxiT6Mvkn+l0NUC/s9d4x6v6v583+KUg4jnTGHHrKM4dTj8i +j2ft7IGQOg89hHUGjzCQ== Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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, 20 Nov 2013 22:44:03 -0000 * Ted Lemon wrote: >The thing that hit me from this article that I really just hadn't fully >understood previously is that any web site that displays personalized >information per user that can be easily parsed now serves as a way to do >a targeted attack on an individual or on individuals who work for an >organization. > >So if you read slashdot or tumblr, for example, both of which display >personally identifying information on their home pages if you are logged >in, then an MiTM attacker can listen on the link the server is connected >to and trigger on HTTP responses to you, and then attack you >specifically, without revealing the attack to anyone else. >This can be mitigated in several ways—obviously https-everywhere will >address the problem, but also if the web site simply doesn't display >personally identifying information in their outgoing traffic, then the >passive attack isn't possible. Online advertisers are happy to help you identify your targets and put code on their computers, . -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 DagebĂ¼ll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From stephen.farrell@cs.tcd.ie Wed Nov 20 14:44:05 2013 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 0DFC01AE1EE for ; Wed, 20 Nov 2013 14:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjIaVfXKzRNf for ; Wed, 20 Nov 2013 14:44:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 573E61AE4DB for ; Wed, 20 Nov 2013 14:44:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81E9EBE6E; Wed, 20 Nov 2013 22:43:54 +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 U+3rDFVPMpeK; Wed, 20 Nov 2013 22:43:52 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.78.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8FE8BE68; Wed, 20 Nov 2013 22:43:52 +0000 (GMT) Message-ID: <528D3B28.8020406@cs.tcd.ie> Date: Wed, 20 Nov 2013 22:43:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Brian E Carpenter References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> In-Reply-To: <528D3A85.5090003@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 22:44:05 -0000 On 11/20/2013 10:41 PM, Brian E Carpenter wrote: > Just do it. I wish:-) > However, I am concerned by the 'bad actor' phrase. The problem is > that it's fine as explained in the draft, but it's highly likely to > be quoted out of context and thereby cause confusion. It would be > safer to use a neutral term ('observer'? 'surveyor'?). Fair point, and "bad-actor" doesn't fit that well anyway. Will find a better term or gladly take suggestions. S. > > Regards > Brian > > On 21/11/2013 11:16, Stephen Farrell wrote: >> Hi all, >> >> Following up on item 3a from the status/plan mail [1] I sent >> last week, Hannes and myself have written up an I-D [2] that >> tries to capture the consensus in the room from the Vancouver >> tech plenary and we're proposing as a BCP. >> >> We're deliberately trying to keep this short and sweet and to >> not (yet) go beyond what was the gist of the hums - we think >> progressing e.g. the threat model or the privacy BCP or other >> bits of related work is liable to take longer and there's value >> in documenting that the IETF as a whole has consensus on the >> most significant bit first so those and other bits of work >> don't all have to re-establish that as they are processed. >> Hopefully we can all easily agree that that's a useful target >> and focus comments on whether on not we've expressed that >> consensus well or not. >> >> >> We've been bouncing versions of this around amongst the IESG >> and IAB for the last week, and process-wise, that has been >> fun already. As you'll see from section 3 of the draft, we can >> no longer just shoot out an RFC agreed by the IESG and IAB so >> the plan for this is that when Hannes and I figure this looks >> ready, based on your comments, then we'll ask Jari to start a >> 4-week IETF LC for it. When he thinks that's ok he'll start it >> and then we'll see how that goes. Assuming that goes well, then >> sometime during IESG evaluation the IAB will decide if they >> like the final text (or not, which'd be "interesting") and if >> they do then an IAB note saying "yep, we like it" will be added >> sometime during/after IESG evaluation before this goes to the >> RFC editor. In an ideal world, you'll all love the -00 already >> and tell us that and we'll be done with all of the above super >> duper process stuff by the end of the year. (Haven't we built >> ourselves a lovely crazy process? ;-) >> >> I really hope we don't end up with a process debate over this, >> since the above, silly and all as it is, should achieve the >> desirable outcome which is a simple BCP, approved by the IESG >> after an IETF LC and also supported by the IAB. The value in >> that is that it seems to be as close as we can get to the same >> setup as RFCs 1984 and 2804 which is the right kind of heritage >> for this one. So there is a reasonably good reason for the >> process-crap. >> >> >> Anyway, ignoring process, comments on this are welcome, so >> please take a read of the two pages of content and let us know >> what you think. If you do think its already good enough for >> starting an IETF last call, then saying that is useful as well. >> >> And since the IETF LC will happen on the ietf@ietf.org list, >> using this list for initial processing should be fine. >> >> Cheers, >> S. >> >> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html >> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack >> _______________________________________________ >> 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 > > From joelja@bogus.com Wed Nov 20 14:55:10 2013 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 30C041AE17F for ; Wed, 20 Nov 2013 14:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjkajtOQB8-s for ; Wed, 20 Nov 2013 14:55:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 207DE1AE133 for ; Wed, 20 Nov 2013 14:55:08 -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 rAKMsZ8t093727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 22:54:36 GMT (envelope-from joelja@bogus.com) Message-ID: <528D3DA6.1030505@bogus.com> Date: Wed, 20 Nov 2013 14:54:30 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Stephen Farrell , Brian E Carpenter References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> In-Reply-To: <528D3B28.8020406@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oitGdqfhOPLCmaKLnSWqlRlFdEjDATBCB" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 20 Nov 2013 22:54:38 +0000 (UTC) Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 22:55:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oitGdqfhOPLCmaKLnSWqlRlFdEjDATBCB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/20/13, 2:43 PM, Stephen Farrell wrote: >=20 >=20 > On 11/20/2013 10:41 PM, Brian E Carpenter wrote: >> Just do it. >=20 > I wish:-) >=20 >> However, I am concerned by the 'bad actor' phrase. The problem is >> that it's fine as explained in the draft, but it's highly likely to >> be quoted out of context and thereby cause confusion. It would be >> safer to use a neutral term ('observer'? 'surveyor'?). >=20 > Fair point, and "bad-actor" doesn't fit that well anyway. Will > find a better term or gladly take suggestions. a surveillor and a surveyor are rather different things. >=20 > S. >=20 >> >> Regards >> Brian >> >> On 21/11/2013 11:16, Stephen Farrell wrote: >>> Hi all, >>> >>> Following up on item 3a from the status/plan mail [1] I sent >>> last week, Hannes and myself have written up an I-D [2] that >>> tries to capture the consensus in the room from the Vancouver >>> tech plenary and we're proposing as a BCP. >>> >>> We're deliberately trying to keep this short and sweet and to >>> not (yet) go beyond what was the gist of the hums - we think >>> progressing e.g. the threat model or the privacy BCP or other >>> bits of related work is liable to take longer and there's value >>> in documenting that the IETF as a whole has consensus on the >>> most significant bit first so those and other bits of work >>> don't all have to re-establish that as they are processed. >>> Hopefully we can all easily agree that that's a useful target >>> and focus comments on whether on not we've expressed that >>> consensus well or not. >>> >>> >>> We've been bouncing versions of this around amongst the IESG >>> and IAB for the last week, and process-wise, that has been >>> fun already. As you'll see from section 3 of the draft, we can >>> no longer just shoot out an RFC agreed by the IESG and IAB so >>> the plan for this is that when Hannes and I figure this looks >>> ready, based on your comments, then we'll ask Jari to start a >>> 4-week IETF LC for it. When he thinks that's ok he'll start it >>> and then we'll see how that goes. Assuming that goes well, then >>> sometime during IESG evaluation the IAB will decide if they >>> like the final text (or not, which'd be "interesting") and if >>> they do then an IAB note saying "yep, we like it" will be added >>> sometime during/after IESG evaluation before this goes to the >>> RFC editor. In an ideal world, you'll all love the -00 already >>> and tell us that and we'll be done with all of the above super >>> duper process stuff by the end of the year. (Haven't we built >>> ourselves a lovely crazy process? ;-) >>> >>> I really hope we don't end up with a process debate over this, >>> since the above, silly and all as it is, should achieve the >>> desirable outcome which is a simple BCP, approved by the IESG >>> after an IETF LC and also supported by the IAB. The value in >>> that is that it seems to be as close as we can get to the same >>> setup as RFCs 1984 and 2804 which is the right kind of heritage >>> for this one. So there is a reasonably good reason for the >>> process-crap. >>> >>> >>> Anyway, ignoring process, comments on this are welcome, so >>> please take a read of the two pages of content and let us know >>> what you think. If you do think its already good enough for >>> starting an IETF last call, then saying that is useful as well. >>> >>> And since the IETF LC will happen on the ietf@ietf.org list, >>> using this list for initial processing should be fine. >>> >>> Cheers, >>> S. >>> >>> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.htm= l >>> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 --oitGdqfhOPLCmaKLnSWqlRlFdEjDATBCB 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/ iEYEARECAAYFAlKNPaYACgkQ8AA1q7Z/VrLqzgCghsOiKO+4x8anA98W5c3wy4DN 9+cAniOmrERoUaTW4JMSIV1BYNrzSeo0 =XbN3 -----END PGP SIGNATURE----- --oitGdqfhOPLCmaKLnSWqlRlFdEjDATBCB-- From rob.stradling@comodo.com Wed Nov 20 15:05:33 2013 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 E14D21AE16D for ; Wed, 20 Nov 2013 15:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9DQvGsjhQnHb for ; Wed, 20 Nov 2013 15:05:29 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mmmail.mcr.colo.comodoca.net [91.209.196.71]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B71AE165 for ; Wed, 20 Nov 2013 15:05:28 -0800 (PST) Received: (qmail 26901 invoked from network); 20 Nov 2013 23:05:20 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 20 Nov 2013 23:05:20 -0000 Received: (qmail 29700 invoked by uid 1000); 20 Nov 2013 23:05:20 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 20 Nov 2013 23:05:20 +0000 Message-ID: <528D402F.9040407@comodo.com> Date: Wed, 20 Nov 2013 23:05:19 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: joel jaeggli , Stephen Farrell , Brian E Carpenter References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> In-Reply-To: <528D3DA6.1030505@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Nov 2013 15:07:13 -0800 Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:05:34 -0000 On 20/11/13 22:54, joel jaeggli wrote: > a surveillor and a surveyor are rather different things. s/surveillor/surveillant/ ? >> S. >> >>> >>> Regards >>> Brian >>> >>> On 21/11/2013 11:16, Stephen Farrell wrote: >>>> Hi all, >>>> >>>> Following up on item 3a from the status/plan mail [1] I sent >>>> last week, Hannes and myself have written up an I-D [2] that >>>> tries to capture the consensus in the room from the Vancouver >>>> tech plenary and we're proposing as a BCP. >>>> >>>> We're deliberately trying to keep this short and sweet and to >>>> not (yet) go beyond what was the gist of the hums - we think >>>> progressing e.g. the threat model or the privacy BCP or other >>>> bits of related work is liable to take longer and there's value >>>> in documenting that the IETF as a whole has consensus on the >>>> most significant bit first so those and other bits of work >>>> don't all have to re-establish that as they are processed. >>>> Hopefully we can all easily agree that that's a useful target >>>> and focus comments on whether on not we've expressed that >>>> consensus well or not. >>>> >>>> >>>> We've been bouncing versions of this around amongst the IESG >>>> and IAB for the last week, and process-wise, that has been >>>> fun already. As you'll see from section 3 of the draft, we can >>>> no longer just shoot out an RFC agreed by the IESG and IAB so >>>> the plan for this is that when Hannes and I figure this looks >>>> ready, based on your comments, then we'll ask Jari to start a >>>> 4-week IETF LC for it. When he thinks that's ok he'll start it >>>> and then we'll see how that goes. Assuming that goes well, then >>>> sometime during IESG evaluation the IAB will decide if they >>>> like the final text (or not, which'd be "interesting") and if >>>> they do then an IAB note saying "yep, we like it" will be added >>>> sometime during/after IESG evaluation before this goes to the >>>> RFC editor. In an ideal world, you'll all love the -00 already >>>> and tell us that and we'll be done with all of the above super >>>> duper process stuff by the end of the year. (Haven't we built >>>> ourselves a lovely crazy process? ;-) >>>> >>>> I really hope we don't end up with a process debate over this, >>>> since the above, silly and all as it is, should achieve the >>>> desirable outcome which is a simple BCP, approved by the IESG >>>> after an IETF LC and also supported by the IAB. The value in >>>> that is that it seems to be as close as we can get to the same >>>> setup as RFCs 1984 and 2804 which is the right kind of heritage >>>> for this one. So there is a reasonably good reason for the >>>> process-crap. >>>> >>>> >>>> Anyway, ignoring process, comments on this are welcome, so >>>> please take a read of the two pages of content and let us know >>>> what you think. If you do think its already good enough for >>>> starting an IETF last call, then saying that is useful as well. >>>> >>>> And since the IETF LC will happen on the ietf@ietf.org list, >>>> using this list for initial processing should be fine. >>>> >>>> Cheers, >>>> S. >>>> >>>> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html >>>> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack >>>> _______________________________________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From mellon@fugue.com Wed Nov 20 15:13:58 2013 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 B59171AE155 for ; Wed, 20 Nov 2013 15:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 7uOLO8SStfkr for ; Wed, 20 Nov 2013 15:13:57 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EEEFD1AE557 for ; Wed, 20 Nov 2013 15:13:55 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 42E1C238248B; Wed, 20 Nov 2013 18:13:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Wed, 20 Nov 2013 18:13:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <55D41CD1-7D56-4DF5-98A5-8EFFBF86C42A@fugue.com> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1822) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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, 20 Nov 2013 23:13:58 -0000 On Nov 20, 2013, at 5:43 PM, Bjoern Hoehrmann wrote: > Online advertisers are happy to help you identify your targets and put > code on their computers, . Malvertising is a scattershot approach, not a targeted approach. If = you have access to a lot of demographic data, you may with some = difficulty be able to target an attack to an individual, but scraping = the HTTP at the server is a _lot_ easier. Making that impossible = increases the cost of this type of attack significantly. From mellon@fugue.com Wed Nov 20 15:14:49 2013 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 F32C81AE17F for ; Wed, 20 Nov 2013 15:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 9MbtKUFkQs2t for ; Wed, 20 Nov 2013 15:14:48 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 149D51AE071 for ; Wed, 20 Nov 2013 15:14:48 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 497A5238248B; Wed, 20 Nov 2013 18:14:40 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <528D402F.9040407@comodo.com> Date: Wed, 20 Nov 2013 18:14:39 -0500 Content-Transfer-Encoding: 7bit Message-Id: <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1822) Cc: Joel Jaeggli , perpass , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:14:49 -0000 On Nov 20, 2013, at 6:05 PM, Rob Stradling wrote: > s/surveillor/surveillant/ ? Eavesdropper? Has negative connotations, but only mildly so. From joelja@bogus.com Wed Nov 20 15:20:23 2013 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 BEB161AE56E for ; Wed, 20 Nov 2013 15:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygF02U7Zupkq for ; Wed, 20 Nov 2013 15:20:22 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C2AAD1AE17F for ; Wed, 20 Nov 2013 15:20:22 -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 rAKNJoFh094059 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 23:19:50 GMT (envelope-from joelja@bogus.com) Message-ID: <528D4390.3000806@bogus.com> Date: Wed, 20 Nov 2013 15:19:44 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Ted Lemon , Rob Stradling References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> In-Reply-To: <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i3eDlf72Kgp6qnqKow0SjDooqdurUbwSD" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 20 Nov 2013 23:19:51 +0000 (UTC) Cc: perpass , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3eDlf72Kgp6qnqKow0SjDooqdurUbwSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/20/13, 3:14 PM, Ted Lemon wrote: > On Nov 20, 2013, at 6:05 PM, Rob Stradling w= rote: >> s/surveillor/surveillant/ ? >=20 > Eavesdropper? Has negative connotations, but only mildly so. bad actor is a value judgement. have no doubt that the intent of surveillance is hostile with respect to the assumputions of the privacy of one's communications. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 --i3eDlf72Kgp6qnqKow0SjDooqdurUbwSD 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/ iEYEARECAAYFAlKNQ5EACgkQ8AA1q7Z/VrI8zwCbBn5BDCXsv1T8ertoagPpLGOA nMEAn1H/lvffM/ba5GcrYdsMXObgNOOb =tK33 -----END PGP SIGNATURE----- --i3eDlf72Kgp6qnqKow0SjDooqdurUbwSD-- From stephen.farrell@cs.tcd.ie Wed Nov 20 15:24:26 2013 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 441DF1AE56E for ; Wed, 20 Nov 2013 15:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8W2UQOQheqD for ; Wed, 20 Nov 2013 15:24: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 8D5911AE17F for ; Wed, 20 Nov 2013 15:24:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81F51BE6E; Wed, 20 Nov 2013 23:24: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 8yMNFiEaVP4m; Wed, 20 Nov 2013 23:24:14 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.78.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81647BE68; Wed, 20 Nov 2013 23:24:14 +0000 (GMT) Message-ID: <528D449E.5080401@cs.tcd.ie> Date: Wed, 20 Nov 2013 23:24:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: joel jaeggli , Ted Lemon , Rob Stradling References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> <528D4390.3000806@bogus.com> In-Reply-To: <528D4390.3000806@bogus.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:24:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Its great how we can all focus in on one word:-) I infer that means you're all ok with all the rest of 'em, but even better if you said that. Meanwhile I got an offlist suggestion: OLD In particular, the term, when used technically, implies nothing about the motivation of the bad-actor mounting the attack, who is still called a bad-actor no matter what one really thinks about their motivation. NEW In particular, the term, when used technically, implies nothing about the motivation of the actor mounting the attack. Which I think is just fine so I've done that in the working version. S. On 11/20/2013 11:19 PM, joel jaeggli wrote: > On 11/20/13, 3:14 PM, Ted Lemon wrote: >> On Nov 20, 2013, at 6:05 PM, Rob Stradling >> wrote: >>> s/surveillor/surveillant/ ? >> >> Eavesdropper? Has negative connotations, but only mildly so. > > bad actor is a value judgement. have no doubt that the intent of > surveillance is hostile with respect to the assumputions of the > privacy of one's communications. > >> _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSjUSeAAoJEC88hzaAX42ihT8H/2/McAgInrCQUj+pGfGASH7x KvouBHynEJI1ajV6TXod91K1cKUOawwi467fznLVKcLIhHtvHYMH+S0R+sC0iCHS aqBez7DzLoW3MhPp1MIF0M6BSB9x11+y/QnZKFIWftMSP+oUcwEceBNHPGHbXMYU ZRRNIos3Tg/9CmPDSYa+lRTxcnEsJoRli/Nxv7mLLPhcH9zzuUX/hIor4F0gc+8D Qre2kLepo9WyvaOmPkmuLK9kZXzwB5ROrkAlnRRx2beX9y17nrh+YG2ogrCZ6a3Y irhHLuzkMVzf6sRWMHgUMFAz4kEgQBwL/Pcw+6OexqG3sCDcuQp3o79zINymTJQ= =9M9H -----END PGP SIGNATURE----- From mellon@fugue.com Wed Nov 20 15:24:57 2013 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 ADC741AE164 for ; Wed, 20 Nov 2013 15:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 roNzdS5ygldY for ; Wed, 20 Nov 2013 15:24:56 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A0F3A1AE17F for ; Wed, 20 Nov 2013 15:24:56 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id B367A238248B; Wed, 20 Nov 2013 18:24:48 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <528D4390.3000806@bogus.com> Date: Wed, 20 Nov 2013 18:24:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> <528D4390.3000806@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1822) Cc: perpass , Rob Stradling , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:24:57 -0000 On Nov 20, 2013, at 6:19 PM, joel jaeggli wrote: > bad actor is a value judgement. have no doubt that the intent of > surveillance is hostile with respect to the assumputions of the = privacy > of one's communications. It's a lot softer to say "we have to treat passive surveillance as an = attack because there is no way to distinguish between cases where it is = and is not an attack" than it is to say "passive surveillance is an = attack." The document goes to some lengths not to examine the motivation of the = eavesdropper, so finding a better term than "bad actor" makes sense to = me. From fergdawgster@mykolab.com Wed Nov 20 15:26:52 2013 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 B85601AE58A for ; Wed, 20 Nov 2013 15:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.525, 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 ezWyEJnRG-Ty for ; Wed, 20 Nov 2013 15:26:50 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28401AE17F for ; Wed, 20 Nov 2013 15:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <528D4525.6070408@mykolab.com> Date: Wed, 20 Nov 2013 15:26:29 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Ted Lemon References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> <528D4390.3000806@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , perpass , Rob Stradling , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com 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, 20 Nov 2013 23:26:53 -0000 On 11/20/2013 3:24 PM, Ted Lemon wrote: > It's a lot softer to say "we have to treat passive surveillance as an attack because there is no way to distinguish between cases where it is and is not an attack" than it is to say "passive surveillance is an attack." Strongly concur. - ferg -- Paul Ferguson PGP Public Key ID: 0x63546533 From fred@cisco.com Wed Nov 20 15:31:31 2013 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 B100B1AE161 for ; Wed, 20 Nov 2013 15:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.026 X-Spam-Level: X-Spam-Status: No, score=-115.026 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.525, 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 vwIV0nkVuk4E for ; Wed, 20 Nov 2013 15:31:29 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 377931AE0E9 for ; Wed, 20 Nov 2013 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1384990283; x=1386199883; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2stmT4Kg8S84zy/La8FP0JKgOl0cnfyF0maey7AQSj0=; b=c5wDP5qDKEYuljDxvcZB0C14TLTHq+s3rS9DGqDfIMh+NuluaDQOiJ2r 6VFzjwEzp1I9x7Z/Ftvmo5qiTPgH3t6Z8UWdMMAEM+ompPBUUX3skPSKe MFLfa+3wlwqok1ECTCV6cCDx9AYk5p8nemhuDfvbqMbwZvaohqgotnT5j E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAMhFjVKtJXG//2dsb2JhbABZgwc4U71pgRsWdIImAQEEeRACAQhGMiUCBA4Th3MNwFIXj2sHgyCBEgOQMIExhjGSDYMogio X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="asc'?scan'208";a="286493271" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 20 Nov 2013 23:31:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAKNVMFh009945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 23:31:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 17:31:21 -0600 From: "Fred Baker (fred)" To: Stephen Farrell Thread-Topic: [perpass] "Its an attack" BCP draft Thread-Index: AQHO5j5Bphed+FewiEyOvLfP47uGBpovKVQA Date: Wed, 20 Nov 2013 23:31:21 +0000 Message-ID: References: <528D34D7.1010303@cs.tcd.ie> In-Reply-To: <528D34D7.1010303@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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_9700F404-9A7A-4325-A3C3-408F3C848BCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:31:31 -0000 --Apple-Mail=_9700F404-9A7A-4325-A3C3-408F3C848BCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just read your ID. I think the sense of the ID is pretty much correct. You half-define two = words, "attack" and "mitigate", in saying something about what they are = not (an attack, you say, has a "bad-actor", but implies nothing about = the motivations of the attacker, and a "mitigation" doesn't make the = attack go away, it merely makes it more expensive). I think you would do = well to actually define the terms. BTW, I think "bad actor" is a bad choice of words if you want to remove = value judgements and motivations from the discussion. I'd suggest a more = neutral term. My definitions probably need work, but I think I'm looking for something = like: Glossary: "Attack": In common English usage, an "attack" is an aggressive action = perpetrated by an opponent, intended to enforce the opponent's will on = the attacked party. In the Internet, the term is used to refer to a = behavior that subverts the intent of a communicator without the = knowledge of the parties to the communication. It may be active or = passive. It may change the content of the communication, record the = content of the communication, or through correlation with other = communication events or attempts, reveal information the communicator = did not intend to be revealed. It may also prevent communication or = delay a time-sensitive communication more than its sensitivity permits. = It may also have other effects that similarly subvert the intent of a = communicator. "Mitigation": As in common english usage, the term is used in the = Internet in the sense of "make less severe, serious, or painful." = (http://www.oxforddictionaries.com/us/definition/american_english/mitigate= ). Colloquially, the term is also used in the sense of making something = of no effect, but this usage is not implied in the Internet context. If = a person is cold, common english usage would consider the act of putting = on a coat or the act of entering a warm building as mitigations. While = the latter (making the matter of no effect) is desirable, for many = purposes the former is cost-effective and sufficient for the purpose. You might also walk through the document looking for run-on sentences = and verbal lists. Search for the word "and", and ask yourself in each = usage whether it could be usefully replaced with a period followed by = the start of a new sentence. Search also for the word "or"; a list is = "A, B, or C", not "A or B or C". In general, try to use simple sentences = in active voice ("A does B to C"), as opposed to more complex sentences = or passive voice ("B is done to C by A"). --Apple-Mail=_9700F404-9A7A-4325-A3C3-408F3C848BCE 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 iD8DBQFSjUZIbjEdbHIsm0MRAkdWAKDqM6RvbMlBBRoNhVJ5eLHlCw/lMgCffWKS ihUeMf21y8nFBcXRA/NvtvY= =2LXi -----END PGP SIGNATURE----- --Apple-Mail=_9700F404-9A7A-4325-A3C3-408F3C848BCE-- From fred@cisco.com Wed Nov 20 15:35:37 2013 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 BCD131AE175 for ; Wed, 20 Nov 2013 15:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.026 X-Spam-Level: X-Spam-Status: No, score=-110.026 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.525, 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 7zxg8LKbR44V for ; Wed, 20 Nov 2013 15:35:36 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id D03F61AE0E9 for ; Wed, 20 Nov 2013 15:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3584; q=dns/txt; s=iport; t=1384990529; x=1386200129; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s4VEk4Cw05Q+6HxTXwrpKXHyubSZuFy/0edF35Utgc4=; b=Cgc1YggePjqncUvfnGw38y1ANbRAPIyTlmDF7A8ExQZDp9MUMCP7miTS Y+kvxgWY1fiEjA8EHwqfVU3x8NZE8lPBE7Ci4xqOQrCOrNJQVG7oHjx8P v5MoZZXAFTmxqQbEPnx8OYQ1VRVAtXbyItprNIwSnkhjqi+5kZcaO4N2R I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAEBGjVKtJXG9/2dsb2JhbABZgwc4U71pgRsWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDodtBg3AbI9rB4MggRIDkDCBMYYxkg2DKIIq X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="asc'?scan'208";a="1073452" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 20 Nov 2013 23:35:29 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAKNZSOS029972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 23:35:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 17:35:28 -0600 From: "Fred Baker (fred)" To: Stephen Farrell Thread-Topic: [perpass] "Its an attack" BCP draft Thread-Index: AQHO5j5Bphed+FewiEyOvLfP47uGBpovKVQAgAABJIA= Date: Wed, 20 Nov 2013 23:35:27 +0000 Message-ID: References: <528D34D7.1010303@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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_B8515632-EA5E-4858-B2B8-BB3B52044655"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:35:38 -0000 --Apple-Mail=_B8515632-EA5E-4858-B2B8-BB3B52044655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 20, 2013, at 3:31 PM, Fred Baker wrote: > I just read your ID. >=20 > I think the sense of the ID is pretty much correct. You half-define = two words, "attack" and "mitigate", in saying something about what they = are not (an attack, you say, has a "bad-actor", but implies nothing = about the motivations of the attacker, and a "mitigation" doesn't make = the attack go away, it merely makes it more expensive). I think you = would do well to actually define the terms. >=20 > BTW, I think "bad actor" is a bad choice of words if you want to = remove value judgements and motivations from the discussion. I'd suggest = a more neutral term. >=20 > My definitions probably need work, but I think I'm looking for = something like: >=20 >=20 > Glossary: >=20 > "Attack": In common English usage, an "attack" is an aggressive action = perpetrated by an opponent, intended to enforce the opponent's will on = the attacked party. In the Internet, the term is used to refer to a = behavior that subverts the intent of a communicator without the = knowledge of the parties to the communication. It may be active or = passive. It may change the content of the communication, record the = content of the communication, or through correlation with other = communication events or attempts, reveal information the communicator = did not intend to be revealed. It may also prevent communication or = delay a time-sensitive communication more than its sensitivity permits. It may force the communicator to spend money to mitigate attacks rather = than pursue his personal or business interest. > It may also have other effects that similarly subvert the intent of a = communicator. >=20 > "Mitigation": As in common english usage, the term is used in the = Internet in the sense of "make less severe, serious, or painful." = (http://www.oxforddictionaries.com/us/definition/american_english/mitigate= ). Colloquially, the term is also used in the sense of making something = of no effect, but this usage is not implied in the Internet context. If = a person is cold, common english usage would consider the act of putting = on a coat or the act of entering a warm building as mitigations. While = the latter (making the matter of no effect) is desirable, for many = purposes the former is cost-effective and sufficient for the purpose. >=20 >=20 >=20 > You might also walk through the document looking for run-on sentences = and verbal lists. Search for the word "and", and ask yourself in each = usage whether it could be usefully replaced with a period followed by = the start of a new sentence. Search also for the word "or"; a list is = "A, B, or C", not "A or B or C". In general, try to use simple sentences = in active voice ("A does B to C"), as opposed to more complex sentences = or passive voice ("B is done to C by A"). --Apple-Mail=_B8515632-EA5E-4858-B2B8-BB3B52044655 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 iD8DBQFSjUc9bjEdbHIsm0MRAhPCAKCZRnJfchiowO2/8gob5fzJiRhr1wCeKd6d gyWoD5PZos7TIsIgLm9mYto= =9iqR -----END PGP SIGNATURE----- --Apple-Mail=_B8515632-EA5E-4858-B2B8-BB3B52044655-- From stephen.farrell@cs.tcd.ie Wed Nov 20 15:42:32 2013 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 B3BED1AE5B3 for ; Wed, 20 Nov 2013 15:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cIRd0_XSeBy for ; Wed, 20 Nov 2013 15:42:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D49A91AE5B1 for ; Wed, 20 Nov 2013 15:42:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EFD06BE6E; Wed, 20 Nov 2013 23:42:21 +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 Y2WdzibzfAhP; Wed, 20 Nov 2013 23:42:20 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.78.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4819DBE68; Wed, 20 Nov 2013 23:42:20 +0000 (GMT) Message-ID: <528D48DC.6020907@cs.tcd.ie> Date: Wed, 20 Nov 2013 23:42:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <528D34D7.1010303@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 20 Nov 2013 23:42:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Fred. Interestingly RFC 4949 does define attack but not mitigation (it does define countermeasure). I think its a fair point that these need good definitions and in this document. Pete Resnick btw, was the one who suggested being specific about these terms. I had just assumed them as obvious, but now see he (and you) are right about that. I'll go over what 4949 says and your suggestions below and come back with something tomorrow/Friday. Cheers, S. On 11/20/2013 11:35 PM, Fred Baker (fred) wrote: > > On Nov 20, 2013, at 3:31 PM, Fred Baker wrote: > >> I just read your ID. >> >> I think the sense of the ID is pretty much correct. You >> half-define two words, "attack" and "mitigate", in saying >> something about what they are not (an attack, you say, has a >> "bad-actor", but implies nothing about the motivations of the >> attacker, and a "mitigation" doesn't make the attack go away, it >> merely makes it more expensive). I think you would do well to >> actually define the terms. >> >> BTW, I think "bad actor" is a bad choice of words if you want to >> remove value judgements and motivations from the discussion. I'd >> suggest a more neutral term. >> >> My definitions probably need work, but I think I'm looking for >> something like: >> >> >> Glossary: >> >> "Attack": In common English usage, an "attack" is an aggressive >> action perpetrated by an opponent, intended to enforce the >> opponent's will on the attacked party. In the Internet, the term >> is used to refer to a behavior that subverts the intent of a >> communicator without the knowledge of the parties to the >> communication. It may be active or passive. It may change the >> content of the communication, record the content of the >> communication, or through correlation with other communication >> events or attempts, reveal information the communicator did not >> intend to be revealed. It may also prevent communication or delay >> a time-sensitive communication more than its sensitivity >> permits. > > It may force the communicator to spend money to mitigate attacks > rather than pursue his personal or business interest. > >> It may also have other effects that similarly subvert the intent >> of a communicator. >> >> "Mitigation": As in common english usage, the term is used in the >> Internet in the sense of "make less severe, serious, or painful." >> (http://www.oxforddictionaries.com/us/definition/american_english/mitigate). >> Colloquially, the term is also used in the sense of making >> something of no effect, but this usage is not implied in the >> Internet context. If a person is cold, common english usage would >> consider the act of putting on a coat or the act of entering a >> warm building as mitigations. While the latter (making the matter >> of no effect) is desirable, for many purposes the former is >> cost-effective and sufficient for the purpose. >> >> >> >> You might also walk through the document looking for run-on >> sentences and verbal lists. Search for the word "and", and ask >> yourself in each usage whether it could be usefully replaced with >> a period followed by the start of a new sentence. Search also for >> the word "or"; a list is "A, B, or C", not "A or B or C". In >> general, try to use simple sentences in active voice ("A does B >> to C"), as opposed to more complex sentences or passive voice ("B >> is done to C by A"). > > > > _______________________________________________ perpass mailing > list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSjUjbAAoJEC88hzaAX42iKAUIALD1Y3OtD3fGGvWEZeWT+74h mzNOFGlWM7Pu2CTvZ/7YZnn1pEoPpnspIsehi3Jx0UQ6fTUjNL9ABpMCAetZrV4M 6VJrp8N8gNc0skKXolGBcHf1vNnAj1rU6GsJ8T3kZIwd8KD7dEwynTu8wfw3Sokr A/o2mbMdPQiq0ev1N5bvs+qtuMOPdFaQAbgkiDZB38SKdGr/297PxctlYf+n0T3K twcA1hBPyC1IODFybKXdHb9ohBLkb+5/WI9FwVf55iSkc5AFovCy5l7dVcjvncy/ DxcZ1LkDnI1Os5o+pBtdk0yizjL4idopWJLAJD3PnbuiE313GMk6fGdwPVgU7yY= =PNpg -----END PGP SIGNATURE----- From paul.hoffman@gmail.com Wed Nov 20 19:33:52 2013 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 114381AE036 for ; Wed, 20 Nov 2013 19:33:52 -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 MQa7L5iMOH0n for ; Wed, 20 Nov 2013 19:33:50 -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 4BA911AE068 for ; Wed, 20 Nov 2013 19:33:50 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id o19so7319952vbm.8 for ; Wed, 20 Nov 2013 19:33:43 -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=TfPsbOZZ9NxzOrR9z0D/j+uXoylCOWEFrrs6VgD2HuU=; b=w1v6tbJuTy7ylQVA0EyTZcMDAfTqDgNhdXHGsY05f7GLp4Im/Ft4TMyzLQ2cpoWaF2 CYGEVHk+sjV43x4anY0a48t7gPlyxnBjJBCCwyoweJlrRbZ6Vw+R2O5pp+DuzsMLoAGl mzEXjv5v5evtPjyBzG3bKqyf8qBleuOxywE81h33/kOe+jbHLx8lYUFmmmjLy3MAVZSn o0hBsyNZ+H+q6xZh+B+BWSf2f7RfMqaw7ws8WwB9xLG9nm5QrHLzYk43Q3UGUBflf+Yf nXbDgQzss4sPPPYGwa8k7k7jkqHu5UDVppMl/xcyQGINzRf1a0cozOcwZ7NESm0FCGpa 0EQw== MIME-Version: 1.0 X-Received: by 10.58.168.205 with SMTP id zy13mr3656198veb.19.1385004823587; Wed, 20 Nov 2013 19:33:43 -0800 (PST) Received: by 10.220.150.208 with HTTP; Wed, 20 Nov 2013 19:33:43 -0800 (PST) In-Reply-To: <528CF08D.7070400@cs.tcd.ie> References: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> <528CF08D.7070400@cs.tcd.ie> Date: Wed, 20 Nov 2013 19:33:43 -0800 Message-ID: From: Paul Hoffman To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b6dc22485b2cc04eba790c5 Cc: Richard Barnes , perpass , Russ Housley Subject: Re: [perpass] RSA-OAEP 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, 21 Nov 2013 03:33:52 -0000 --047d7b6dc22485b2cc04eba790c5 Content-Type: text/plain; charset=UTF-8 +1 to this being a SAAG topic, not a perpass topic. And it would be great to fix it, if we can get buy-in. --047d7b6dc22485b2cc04eba790c5 Content-Type: text/html; charset=UTF-8
+1 to this being a SAAG topic, not a perpass topic. And it would be great to fix it, if we can get buy-in.

--047d7b6dc22485b2cc04eba790c5-- From derhoermi@gmx.net Wed Nov 20 20:00:40 2013 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 3B6AC1AE09B for ; Wed, 20 Nov 2013 20:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, 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 7SV49DL8UxZ6 for ; Wed, 20 Nov 2013 20:00:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B6D931ADBCC for ; Wed, 20 Nov 2013 20:00:37 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.13.37]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MHrk1-1Vfm0C3q5V-003f0U for ; Thu, 21 Nov 2013 05:00:26 +0100 From: Bjoern Hoehrmann To: Ted Lemon Date: Thu, 21 Nov 2013 05:00:12 +0100 Message-ID: <92lq89dapmn0u21t519plhamifqcdjfv80@hive.bjoern.hoehrmann.de> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> <55D41CD1-7D56-4DF5-98A5-8EFFBF86C42A@fugue.com> In-Reply-To: <55D41CD1-7D56-4DF5-98A5-8EFFBF86C42A@fugue.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ydozInnOj3d0E1Gs38Cjeox2pzCGoq3hrlhVBI9fg/NILZ68luS +s3SkJW/ifqvSlT4l7jkpwsyjAT1kUHqqbGxngDePPXK7KLa9mvnHNqmwtHmett8gpk/ShQ Q2TMN4ZEqTh6i6ZJtiMQeIE5K9/P/EvrZ1CESqoO8m0YhXTWrADycwPXloGvB5wAU1xW5/X A5Nb4G9V0wNa6CJGfJ+BA== Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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, 21 Nov 2013 04:00:40 -0000 * Ted Lemon wrote: >On Nov 20, 2013, at 5:43 PM, Bjoern Hoehrmann wrote: >> Online advertisers are happy to help you identify your targets and put >> code on their computers, . > >Malvertising is a scattershot approach, not a targeted approach. If >you have access to a lot of demographic data, you may with some >difficulty be able to target an attack to an individual, but scraping >the HTTP at the server is a _lot_ easier. Making that impossible >increases the cost of this type of attack significantly. Modern ads are complex computer programs running on your computer with access to information the ad network associates with "you", information associated with the page the ad is on, and the ability to probe your computer for more information. Instead of scanning through the network traffic the attacker would use these data sources to identify you and attack once identified. Silly example: let's say the ad can know which page it is loaded on and it can persist information that is available when the ad is loaded from the page by the user again. Now that page is https://example.com/~user and the ad is shown to all who visit that page. After some time the ad knows (perhaps through a synchronising server) which user has visited that page most frequently and can infer that's the actual user "user". If an attacker wanted to target someone attending the most recent IETF meeting they might start with booking ads for "People who normally reside in X but are on visit in Vancouver" during the first week of November 2013. Someone with an interest in internationalisation, Uni- code and all that stuff? Probe the system for unusual fonts. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mellon@fugue.com Wed Nov 20 20:10:57 2013 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 E4E381AE0A1 for ; Wed, 20 Nov 2013 20:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 z7XDeio6cVdz for ; Wed, 20 Nov 2013 20:10:55 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E00E31AE094 for ; Wed, 20 Nov 2013 20:10:55 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 1D95F2380CB4; Wed, 20 Nov 2013 23:10:46 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <92lq89dapmn0u21t519plhamifqcdjfv80@hive.bjoern.hoehrmann.de> Date: Wed, 20 Nov 2013 23:10:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E1999F9-01BF-42B8-834C-7A59D39F9017@fugue.com> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> <55D41CD1-7D56-4DF5-98A5-8EFFBF86C42A@fugue.com> <92lq89dapmn0u21t519plhamifqcdjfv80@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1822) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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, 21 Nov 2013 04:10:58 -0000 Bjoern, please don't take my reassertion of the problem I wanted to talk = about as an indication that I consider the problem you want to talk = about unimportant. I agree that online ads present an attack surface, = and that we should think about that. I'm quite aware that my computer = is running programs at the behest of ad networks (well, actually it's = not, because I don't allow Flash in my web browser, but I certainly = agree with you in principle). The point of what I said previously was to talk about another attack = surface with different characteristics. The problem you are describing = is one that's already on the radar of most of us tin-foil-hat wearers. = I just wanted to get an additional problem which is similar but really = meaningfully different on the radar as well. What's interesting about the http-with-identifying-info attack is that = it can be easily prevented by not including identifying info or by using = https. Unfortunately the targeted-ad attack can't be addressed in this = way, but that doesn't mean that the http-with-identifying-info attack = isn't worth addressing. From trammell@tik.ee.ethz.ch Thu Nov 21 03:43:40 2013 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 B389B1AD9B8 for ; Thu, 21 Nov 2013 03:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCSNeHIhFr3b for ; Thu, 21 Nov 2013 03:43:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 12A6B1AD943 for ; Thu, 21 Nov 2013 03:43:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CF264D9307 for ; Thu, 21 Nov 2013 12:43:26 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d5OTguuuWEIV for ; Thu, 21 Nov 2013 12:43:26 +0100 (MET) Received: from public-docking-pat-etx-2357.ethz.ch (public-docking-pat-etx-2357.ethz.ch [10.2.121.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 908CCD9300 for ; Thu, 21 Nov 2013 12:43:26 +0100 (MET) Message-ID: <528DF1DD.7010904@tik.ee.ethz.ch> Date: Thu, 21 Nov 2013 12:43:25 +0100 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: 'perpass' Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Of potential interest: MinimaLT 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, 21 Nov 2013 11:43:40 -0000 Greetings, all, MinimaLT, YA transport layer replacement with a focus on maximizing confidentiality, was presented at CCS last week in Berlin; see Petullo et al "MinimaLT: Minimal-latency Networking through Better Security" (available at http://cr.yp.to/tcpip/minimalt-20130522.pdf) -- this may provide at least some inspiration in considering a surveillance-resistant Internet. Cheers, Brian From skyper@thc.org Thu Nov 21 03:47:41 2013 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 6FB601AD943 for ; Thu, 21 Nov 2013 03:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 vf80eSx3czMP for ; Thu, 21 Nov 2013 03:47:39 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DA8311ACC89 for ; Thu, 21 Nov 2013 03:47:38 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id qd12so6737417ieb.15 for ; Thu, 21 Nov 2013 03:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=G+mIpjftHzW0EGbCXCC6ksU3okXXPqC7Ufy+8uJv0x8=; b=A7AUYxholtMDPgFIfls6ilFpJFnvejO20otCLm0M+flASZNBtdVFsIdKQCI0HpCxsb 1zmeliplEjO1ETkupAwdlDGuGXOFqT0qnhW0GhD1gVFXY5XxHgLj8y44RLPTDE86fN7V i1V6mzPGK15BTmlFzEadL9maKCTZZtmSALDio= 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=G+mIpjftHzW0EGbCXCC6ksU3okXXPqC7Ufy+8uJv0x8=; b=DRjaP/lO5JQ21a2JwTRBwwYl+JyrcutKxmhJ6FlKVzLZr6/2LI9m97q5nZ9SOLP1KH kXZ6zXPlsVMHdBtDnlNFIyc9LXtI8NPgxJjvb1JIazW4VplKz5P+aA4wEVGeumv2yNp9 SFEEfEwUI3N7vV2Q5E8lQKCVSbWHJdhr1fkuQ6uE8wzxORQu6uz+CtGCoyNYvdZto/hV r7sb6y0HDja5nAml5S24XIIrnBfDNAlBBhFrGDrQOKUNEcyhkz96RIII9CbSbOwi0U/k 1hiMJOJEdmio+jpx+cwOGppaWaEGy5riPhhvrn1WY3yjJuGAEEYlGQTKU55dgveQpeOe iudg== X-Gm-Message-State: ALoCoQmePsVqVhLrW3ei1w/UUR9I7QvBDOPVimfMryIu/aCxgBQZBm8YVFTF5hgEWBqbnoP3N2vH MIME-Version: 1.0 X-Received: by 10.50.73.130 with SMTP id l2mr20286751igv.36.1385034452117; Thu, 21 Nov 2013 03:47:32 -0800 (PST) Received: by 10.64.9.41 with HTTP; Thu, 21 Nov 2013 03:47:32 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: <528D34D7.1010303@cs.tcd.ie> References: <528D34D7.1010303@cs.tcd.ie> Date: Thu, 21 Nov 2013 11:47:32 +0000 Message-ID: From: Ralf Skyper Kaiser To: perpass Content-Type: multipart/alternative; boundary=089e01160edc8541e404ebae762f Subject: Re: [perpass] "Its an attack" BCP draft 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, 21 Nov 2013 11:47:41 -0000 --089e01160edc8541e404ebae762f Content-Type: text/plain; charset=ISO-8859-1 Hi, "...pervasive monitoring significantly more expensive or infeasible" Recommend to remove 'significantly'. (otherwise there will be an argument what 'significant' means. 1M USD? 10M USD? And how expensive is it anyway to send a RST to 240M users? 1 cent? 1 Dollar?). "...pervasive monitoring" means very widespread privacy-invasive gathering of protocol" Recommend to remove 'very' and 'privacy-invasive'. "Pervasive monitoring means widespread gathering of protocol ...". RFC1984 had more detail and these specifics in RFC1984 were helpful. Some specifics for this I-D: ENCRYPT EVERYTHING SECURITY BY DEFAULT ....please add?... I-D does not touch regulatory changes (liability of service providers towards its users and neglect when failing to support HTTPS for example). Wish it did. (One reason why the internet is not secure is because the manufactures get away shipping products that have all security features disabled by default...or with default 0000 pins). (RFC1984 did mention regulatory problems [export control] for example). Rest is awesome! regards, Ralf On Wed, Nov 20, 2013 at 10:16 PM, Stephen Farrell wrote: > > Hi all, > > Following up on item 3a from the status/plan mail [1] I sent > last week, Hannes and myself have written up an I-D [2] that > tries to capture the consensus in the room from the Vancouver > tech plenary and we're proposing as a BCP. > > We're deliberately trying to keep this short and sweet and to > not (yet) go beyond what was the gist of the hums - we think > progressing e.g. the threat model or the privacy BCP or other > bits of related work is liable to take longer and there's value > in documenting that the IETF as a whole has consensus on the > most significant bit first so those and other bits of work > don't all have to re-establish that as they are processed. > Hopefully we can all easily agree that that's a useful target > and focus comments on whether on not we've expressed that > consensus well or not. > > > We've been bouncing versions of this around amongst the IESG > and IAB for the last week, and process-wise, that has been > fun already. As you'll see from section 3 of the draft, we can > no longer just shoot out an RFC agreed by the IESG and IAB so > the plan for this is that when Hannes and I figure this looks > ready, based on your comments, then we'll ask Jari to start a > 4-week IETF LC for it. When he thinks that's ok he'll start it > and then we'll see how that goes. Assuming that goes well, then > sometime during IESG evaluation the IAB will decide if they > like the final text (or not, which'd be "interesting") and if > they do then an IAB note saying "yep, we like it" will be added > sometime during/after IESG evaluation before this goes to the > RFC editor. In an ideal world, you'll all love the -00 already > and tell us that and we'll be done with all of the above super > duper process stuff by the end of the year. (Haven't we built > ourselves a lovely crazy process? ;-) > > I really hope we don't end up with a process debate over this, > since the above, silly and all as it is, should achieve the > desirable outcome which is a simple BCP, approved by the IESG > after an IETF LC and also supported by the IAB. The value in > that is that it seems to be as close as we can get to the same > setup as RFCs 1984 and 2804 which is the right kind of heritage > for this one. So there is a reasonably good reason for the > process-crap. > > > Anyway, ignoring process, comments on this are welcome, so > please take a read of the two pages of content and let us know > what you think. If you do think its already good enough for > starting an IETF last call, then saying that is useful as well. > > And since the IETF LC will happen on the ietf@ietf.org list, > using this list for initial processing should be fine. > > Cheers, > S. > > [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html > [2] http://tools.ietf.org/html/draft-farrell-perpass-attack > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --089e01160edc8541e404ebae762f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

"...pervasive monitoring si= gnificantly more expensive or infeasible"

Recommend to remove 'sign= ificantly'. (otherwise there will be an argument what 'significant&= #39; means. 1M USD? 10M USD? And how expensive is it anyway to send a RST t= o 240M users? 1 cent? 1 Dollar?).

"...pervasive monitoring" means very widespread privacy-invasive gathering of protocol"

Rec= ommend to remove 'very' and 'privacy-invasive'. "Perva= sive monitoring means widespread gathering of protocol ...".

RFC1984 had more detail and these specifics in RFC1984 were help= ful.=A0 Some specifics for this I-D:
ENCRYPT EVERYTHING
SECURITY BY DEFAULT
....please add?...

I-D does not touch regulatory changes (liability of service providers = towards its users and neglect when failing to support HTTPS for example). W= ish it did. (One reason why the internet is not secure is because the manuf= actures get away shipping products that have all security features disabled= by default...or with default 0000 pins). (RFC1984 did mention regulatory p= roblems [export control] for example).

Rest is awesome!

regards,

Ralf
<= div>



On Wed, Nov 20, 20= 13 at 10:16 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:

Hi all,

Following up on item 3a from the status/plan mail [1] I sent
last week, Hannes and myself have written up an I-D [2] that
tries to capture the consensus in the room from the Vancouver
tech plenary and we're proposing as a BCP.

We're deliberately trying to keep this short and sweet and to
not (yet) go beyond what was the gist of the hums - we think
progressing e.g. the threat model or the privacy BCP or other
bits of related work is liable to take longer and there's value
in documenting that the IETF as a whole has consensus on the
most significant bit first so those and other bits of work
don't all have to re-establish that as they are processed.
Hopefully we can all easily agree that that's a useful target
and focus comments on whether on not we've expressed that
consensus well or not.

<boring-bit>
We've been bouncing versions of this around amongst the IESG
and IAB for the last week, and process-wise, that has been
fun already. As you'll see from section 3 of the draft, we can
no longer just shoot out an RFC agreed by the IESG and IAB so
the plan for this is that when Hannes and I figure this looks
ready, based on your comments, then we'll ask Jari to start a
4-week IETF LC for it. When he thinks that's ok he'll start it
and then we'll see how that goes. Assuming that goes well, then
sometime during IESG evaluation the IAB will decide if they
like the final text (or not, which'd be "interesting") and if=
they do then an IAB note saying "yep, we like it" will be added sometime during/after IESG evaluation before this goes to the
RFC editor. In an ideal world, you'll all love the -00 already
and tell us that and we'll be done with all of the above super
duper process stuff by the end of the year. (Haven't we built
ourselves a lovely crazy process? ;-)

I really hope we don't end up with a process debate over this,
since the above, silly and all as it is, should achieve the
desirable outcome which is a simple BCP, approved by the IESG
after an IETF LC and also supported by the IAB. The value in
that is that it seems to be as close as we can get to the same
setup as RFCs 1984 and 2804 which is the right kind of heritage
for this one. So there is a reasonably good reason for the
process-crap.
</boring-bit>

Anyway, ignoring process, comments on this are welcome, so
please take a read of the two pages of content and let us know
what you think. If you do think its already good enough for
starting an IETF last call, then saying that is useful as well.

And since the IETF LC will happen on the i= etf@ietf.org list,
using this list for initial processing should be fine.

Cheers,
S.

[1] http://www.ietf.org/mail-archive/web/perpass/curr= ent/msg01016.html
[2] http://tools.ietf.org/html/draft-farrell-perpass-attack<= br> _______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--089e01160edc8541e404ebae762f-- From ynir@checkpoint.com Thu Nov 21 05:58:47 2013 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 DB8131ADF78 for ; Thu, 21 Nov 2013 05:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 HiL9FUf35A4P for ; Thu, 21 Nov 2013 05:58:46 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE181ADF10 for ; Thu, 21 Nov 2013 05:58:45 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rALDwQES008206; Thu, 21 Nov 2013 15:58:26 +0200 X-CheckPoint: {528E0F2A-3-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 15:58:25 +0200 From: Yoav Nir To: Ralf Skyper Kaiser Thread-Topic: [perpass] "Its an attack" BCP draft Thread-Index: AQHO5j44GuxdNw/HskiWib62c9hVzpovcOkAgAAkkAA= Date: Thu, 21 Nov 2013 13:58:24 +0000 Message-ID: <223EC5F4-94E8-4507-95DB-56295F72FBB0@checkpoint.com> References: <528D34D7.1010303@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.110] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <09490A889CFC7048923180EEC64E37FD@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 21 Nov 2013 13:58:48 -0000 On Nov 21, 2013, at 1:47 PM, Ralf Skyper Kaiser wrote: > Hi, >=20 > "...pervasive monitoring significantly more expensive or infeasible" >=20 > Recommend to remove 'significantly'. (otherwise there will be an argument= what 'significant' means. 1M USD? 10M USD? And how expensive is it anyway = to send a RST to 240M users? 1 cent? 1 Dollar?). I agree there will be an argument. But don't you think we need some criteri= on for defining success? If we increase the cost 1000x, they have to total= ly change their operating model. If we increase the cost 10x, they will hav= e to scale back what they're doing. If we increase it 1.5x? Probably just = makes the American tax payer pay a little more. From hallam@gmail.com Thu Nov 21 07:34:43 2013 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 EA2481ADFB6 for ; Thu, 21 Nov 2013 07:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=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 nN0tiMr77G1Q for ; Thu, 21 Nov 2013 07:34:41 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B1F101ADFA5 for ; Thu, 21 Nov 2013 07:34:40 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id ev20so8791256lab.27 for ; Thu, 21 Nov 2013 07:34:32 -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=znNDSHRpyayQmF7MuzqKCQ6BTRUCfP39hp6cb/fZGDA=; b=iSxmk6Ia+ngIN9pESbLmAhkkmjrikECMQI7h4vzH1UM7022Ig0gKZ9UxbmerIkCPFv rjg/C+S+ivboGPxKZUxYvPXc2ysZzPK2n1yrLYnn9ZgCH7pywYSnv4VmmkGV+2ZRMytl uUnrxaxG0HSxQdSv54KB5gYlLp4HR+MV827fQywO9Qb+9GfD5yYuz/nrFqYKh0CfYqW2 q9hJ/ZhESQMHCHmKDh1Us4Hy/6dH6vXw8pbPaMvzuYHB/tsj+qklBSD7DxOjWX6C0m6A I6bLLcISx7tUDQu28Sh0MIVJ8nGmvIGgN4cYqDFQLLQB5YznvwIZarWYBEMeeqssoM1j psag== MIME-Version: 1.0 X-Received: by 10.152.23.167 with SMTP id n7mr82509laf.56.1385048070483; Thu, 21 Nov 2013 07:34:30 -0800 (PST) Received: by 10.112.46.98 with HTTP; Thu, 21 Nov 2013 07:34:30 -0800 (PST) In-Reply-To: <223EC5F4-94E8-4507-95DB-56295F72FBB0@checkpoint.com> References: <528D34D7.1010303@cs.tcd.ie> <223EC5F4-94E8-4507-95DB-56295F72FBB0@checkpoint.com> Date: Thu, 21 Nov 2013 10:34:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0160a5e63cf62304ebb1a227 Cc: perpass , Ralf Skyper Kaiser Subject: Re: [perpass] "Its an attack" BCP draft 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, 21 Nov 2013 15:34:43 -0000 --089e0160a5e63cf62304ebb1a227 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 21, 2013 at 8:58 AM, Yoav Nir wrote: > > On Nov 21, 2013, at 1:47 PM, Ralf Skyper Kaiser wrote: > > > Hi, > > > > "...pervasive monitoring significantly more expensive or infeasible" > > > > Recommend to remove 'significantly'. (otherwise there will be an > argument what 'significant' means. 1M USD? 10M USD? And how expensive is it > anyway to send a RST to 240M users? 1 cent? 1 Dollar?). > > I agree there will be an argument. But don't you think we need some > criterion for defining success? If we increase the cost 1000x, they have > to totally change their operating model. If we increase the cost 10x, they > will have to scale back what they're doing. If we increase it 1.5x? > Probably just makes the American tax payer pay a little more. > > The criteria that is used inside the NSA is GDP of adversary * number of years. Which is about $10 Trillion * 10 = $100 Trillion Which sounds a lot but we have billions of communications a day. So raising the attack cost to $100K per communication is enough. Website: http://hallambaker.com/ --089e0160a5e63cf62304ebb1a227 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Nov 21, 2013 at 8:58 AM, Yoav Nir <ynir@checkpoint.com> wrote:

On Nov 21, 2013, at 1:47 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:

> Hi,
>
> "...pervasive monitoring significantly more expensive or infeasib= le"
>
> Recommend to remove 'significantly'. (otherwise there will be = an argument what 'significant' means. 1M USD? 10M USD? And how expe= nsive is it anyway to send a RST to 240M users? 1 cent? 1 Dollar?).

I agree there will be an argument. But don't you think we need so= me criterion for defining success? =A0If we increase the cost 1000x, they h= ave to totally change their operating model. If we increase the cost 10x, t= hey will have to scale back what they're doing. If we increase it 1.5x?= =A0Probably just makes the American tax payer pay a little more.

<= br>
The criteria that is used inside the NSA is GDP of adversary = * number of years.


Which is about $= 10 Trillion * 10 =3D $100 Trillion

Which sounds a lot but we have billions of communicatio= ns a day. So raising the attack cost to $100K per communication is enough.<= /div>

=A0
Website: http://hallambaker.com/
--089e0160a5e63cf62304ebb1a227-- From joncallas@icloud.com Thu Nov 21 11:05:03 2013 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 38EE21AE072 for ; Thu, 21 Nov 2013 11:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1-tR86j3OMN for ; Thu, 21 Nov 2013 11:05:00 -0800 (PST) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtp004.mac.com [17.172.204.239]) by ietfa.amsl.com (Postfix) with ESMTP id 33A9E1AE023 for ; Thu, 21 Nov 2013 11:04:59 -0800 (PST) Received: from [10.9.215.27] (unsi-63-133-207-226.unsi.net [63.133.207.226]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MWM007A6NO3W270@st11p01mm-asmtp001.mac.com> for perpass@ietf.org; Thu, 21 Nov 2013 19:04:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.14,0.0.0000 definitions=2013-11-21_06:2013-11-21,2013-11-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1311210126 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jon Callas In-reply-to: <528D3B28.8020406@cs.tcd.ie> Date: Thu, 21 Nov 2013 11:04:54 -0800 Content-transfer-encoding: quoted-printable Message-id: <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1510) Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 21 Nov 2013 19:05:03 -0000 On Nov 20, 2013, at 2:43 PM, Stephen Farrell = wrote: >=20 > Fair point, and "bad-actor" doesn't fit that well anyway. Will > find a better term or gladly take suggestions. >=20 An appropriate term of art is "adversary." Jon From rlb@ipv.sx Thu Nov 21 11:57:41 2013 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 0D5151AE17E for ; Thu, 21 Nov 2013 11:57:41 -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 uUKqSGr2iW4w for ; Thu, 21 Nov 2013 11:57:38 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 95A191AE074 for ; Thu, 21 Nov 2013 11:57:38 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wm4so261987obc.24 for ; Thu, 21 Nov 2013 11:57: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:date :message-id:subject:from:to:cc:content-type; bh=04WkvoQsD0cmdhicCJX7Ro/HXGDH803M5QRBpUtOLkY=; b=dmRBEnC48kSsYWFSGet5vAOkNUHWGY7q1JfLS/2G4MpSuJTaog4lh7zKHqy3T4v9hl +9jg6+WcjKIi8GWM4XsEe3BoCs9bd0KRpZDk+veO1xbiVsv6RGmxLQARGOHhnltlKWse KvVBzzoZynbe3F07dGRuZWDYDLRPtaz10z7v4MiBdCxtmqkbJY/kIlhdAmtTGFrGfAqI xrSgg89arwR+6sDbx8BrXXLVqc040J9hb2bclzvF5nS7H/RIGKZJEOZCN+gUr4GKY3+n bzF56Hvtteb8bXfwnEUcw1bC+3YikOmGsOZI3qW+VJwKVAqu18VYswlkCBvvtIgnmJUg uH7A== X-Gm-Message-State: ALoCoQk92e2iSz3DSUK4ISxKa68ld+ANiTmkx1F/8YzjN/EBtZv5BnjMw7u7eWbobR3KHMfy6du3 MIME-Version: 1.0 X-Received: by 10.182.135.194 with SMTP id pu2mr7122741obb.38.1385063851690; Thu, 21 Nov 2013 11:57:31 -0800 (PST) Received: by 10.60.31.74 with HTTP; Thu, 21 Nov 2013 11:57:31 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Nov 2013 14:57:31 -0500 Message-ID: From: Richard Barnes To: "Moriarty, Kathleen" Content-Type: multipart/alternative; boundary=089e0122a6c0df23d904ebb54ec5 Cc: "perpass@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [perpass] Crypto scorecard released by EFF 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, 21 Nov 2013 19:57:41 -0000 --089e0122a6c0df23d904ebb54ec5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The link: https://www.eff.org/deeplinks/2013/11/encrypt-web-report-whos-doing-what#cr= ypto-chart On Wed, Nov 20, 2013 at 5:23 PM, Moriarty, Kathleen < kathleen.moriarty@emc.com> wrote: > I had the same problem and had to let the page load. The survey is > tracking the following in the columns: > > Encrypts data center links > > Supports HTTPS > > HTTPS Strict (HSTS) > > Forward Secrecy > > STARTTLS > > > > Best regards, > > Kathleen > > > > *From:* Fred Baker (fred) [mailto:fred@cisco.com] > *Sent:* Wednesday, November 20, 2013 5:20 PM > *To:* Moriarty, Kathleen > *Cc:* perpass@ietf.org > *Subject:* Re: [perpass] Crypto scorecard released by EFF > > > > > > On Nov 20, 2013, at 2:08 PM, "Moriarty, Kathleen" < > kathleen.moriarty@emc.com> wrote: > > > > EFF released a =91report card=92 for encryption capabilities of 18 compan= ies > and may be of interest to many of you. It is meant as a positive > encouragement to other companies to expand crypto capabilities per the we= b > link. > > > > > http://threatpost.com/eff-scorecard-shows-crypto-leaders-and-laggards/102= 987 > > > > Hmm. A chart with rows and columns. The rows have logos on them. The > columns are unidentified... > > > > Best regards, > > Kathleen > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > ----------------------------------- > "We are learning to do a great many clever things...The next great task > will be to learn not to do them." > > - G. K. Chesterton (1874-1936) > > > > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --089e0122a6c0df23d904ebb54ec5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <= div class=3D"gmail_extra">

On Wed, Nov 20, 2013 at 5:23 PM, Moriart= y, Kathleen <kathleen.moriarty@emc.com> wrote:

I had the same problem and had to let the pa= ge load.=A0 The survey is tracking the following in the columns:<= /u>

Encrypts data center link= s

Supports HTTPS

HTTPS Strict (HSTS)

Forwar= d Secrecy

STARTTLS

=A0=

Best regards,

Kathleen<= /u>

=A0<= /p>

From: Fred Bak= er (fred) [mailto:fred@= cisco.com]
Sent: Wednesday, November 20, 2013 5:20 PM
To: Moriarty, K= athleen
Cc: perpass@ietf.org
Subject: Re: [perpass] Crypto scorecard rel= eased by EFF

=A0=

=A0

On Nov 20, 2013, at 2:08 PM, "Moriarty, Kathleen" <kathleen.moriarty= @emc.com> wrote:



EFF released a =91report card=92 for encryption= capabilities of 18 companies and may be of interest to many of you.=A0 It = is meant as a positive encouragement to other companies to expand crypto ca= pabilities per the web link.

=A0

=

=A0=

Hmm. A chart with= rows and columns. The rows have logos on them. The columns are unidentifie= d...



Best regards,=

Kathleen

=A0

=

_______________________________= ________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass<= u>

=A0

<= div>

-----------------------------------
"We are learning to do a great many clever things...The next gre= at task
will be to learn not to do them."
- G. K. Chesterton (1874-1936)<= u>

=A0



=A0=


___________________________________________= ____
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--089e0122a6c0df23d904ebb54ec5-- From ned+perpass@mrochek.com Thu Nov 21 14:48:09 2013 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 B15A41AE3CF for ; Thu, 21 Nov 2013 14:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 Nmur2jm0O9O2 for ; Thu, 21 Nov 2013 14:48:07 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F21811AE3CE for ; Thu, 21 Nov 2013 14:48:06 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P11W3QK7GG0017RZ@mauve.mrochek.com> for perpass@ietf.org; Thu, 21 Nov 2013 14:42:55 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Thu, 21 Nov 2013 14:42:50 -0800 (PST) From: ned+perpass@mrochek.com Message-id: <01P11W3OG7H400004G@mauve.mrochek.com> Date: Thu, 21 Nov 2013 14:32:41 -0800 (PST) In-reply-to: "Your message dated Thu, 21 Nov 2013 14:57:31 -0500" References: To: Richard Barnes Cc: "perpass@ietf.org" , "Moriarty, Kathleen" , "Fred Baker \(fred\)" Subject: Re: [perpass] Crypto scorecard released by EFF 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, 21 Nov 2013 22:48:09 -0000 > The link: > https://www.eff.org/deeplinks/2013/11/encrypt-web-report-whos-doing-what#crypto-chart Too bad the creators of this survey had no idea what they were doing when it comes to email. For one thing web access != webmail != IMAP/POP/SUBMIT, and it is a known fact that several of these vendors, e.g., Yahoo, require SSL/TLS for some of these and don't allow it at all for others. (This was one of the big holes the NSA exploited, so yeah, it matters.) And for another, STARTTLS as presently specified is *not* an opportunistic encryption facility. And there are significant operational problems with using it that way. I've already discussed why this is so elswhere so I won't bother to repeat the details here. Ned From wilton@isoc.org Thu Nov 21 15:27:47 2013 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 3F9E71AE06D for ; Thu, 21 Nov 2013 15:27:47 -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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seVPDtvPgdnf for ; Thu, 21 Nov 2013 15:27:44 -0800 (PST) Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) by ietfa.amsl.com (Postfix) with ESMTP id 868911AE12C for ; Thu, 21 Nov 2013 15:27:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9617B2E80C5; Thu, 21 Nov 2013 18:27:37 -0500 (EST) X-Virus-Scanned: OK Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 062152E80E0; Thu, 21 Nov 2013 18:27:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_D26B57E5-97A3-49C6-B305-112E62FFCC6B"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> Date: Thu, 21 Nov 2013 23:27:31 +0000 Message-Id: References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> To: Jon Callas X-Mailer: Apple Mail (2.1283) Cc: perpass , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 21 Nov 2013 23:27:47 -0000 --Apple-Mail=_D26B57E5-97A3-49C6-B305-112E62FFCC6B Content-Type: multipart/alternative; boundary="Apple-Mail=_5AA2E7F1-617B-42E0-AE04-6DBCC095E7D5" --Apple-Mail=_5AA2E7F1-617B-42E0-AE04-6DBCC095E7D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm not sure I agree... in this context, "bad actors" are those who = exploit their legitimate participation in a system to act in = illegitimate ways, advancing their interests regardless of the = disbenefit to others or to the system itself.=20 That's not necessarily adversarial... R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 21 Nov 2013, at 19:04, Jon Callas wrote: > On Nov 20, 2013, at 2:43 PM, Stephen Farrell = wrote: >=20 >>=20 >> Fair point, and "bad-actor" doesn't fit that well anyway. Will >> find a better term or gladly take suggestions. >>=20 >=20 > An appropriate term of art is "adversary." >=20 > Jon >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_5AA2E7F1-617B-42E0-AE04-6DBCC095E7D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'm = not sure I agree... in this context, "bad actors" are those who exploit = their legitimate participation in a system to act in illegitimate ways, = advancing their interests regardless of the disbenefit to others or to = the system itself. 

That's not necessarily = adversarial...

R

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 21 Nov 2013, at 19:04, Jon Callas wrote:

On = Nov 20, 2013, at 2:43 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:


Fair point, and "bad-actor" doesn't fit that well anyway. = Will
find a better term or = gladly take suggestions.


An appropriate term of art is = "adversary."

= Jon


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

= = --Apple-Mail=_5AA2E7F1-617B-42E0-AE04-6DBCC095E7D5-- --Apple-Mail=_D26B57E5-97A3-49C6-B305-112E62FFCC6B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTIxMjMyNzMyWjAjBgkqhkiG9w0BCQQxFgQUn4EGBA863ZgLr4wTdL7F mLbTLOYwdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAIRLvUNZ136aCfyQoIqI4X0r q2wyrxw6OzvzZkib+EggPoEJvapgwK3LtT2xk4FmCMrvg2Lwli/zSFxafbE8ObrJxbmq/WSqyTlI dpQjJaOEt5V4Q74WmVeD2yKeYoG1mOZ95At0KuV2AHD9lZabJaepD7IeXDeMDOv7reydajvHNY2D L3d2m3kDCCIJLGrbYclCee7iIsIygVd3FTTkOetP67dkuf+ArV9IAjtCNqXIIoNsraACsf0SP684 7wHo+yPemekdUCi4kR9RktBcH8u80gwgGRw2HZBHWTszv4sxaB0/DjWW/i386WkntaZjkI6eW/q4 aTit5e/bysY/VNUAAAAAAAA= --Apple-Mail=_D26B57E5-97A3-49C6-B305-112E62FFCC6B-- From sm@resistor.net Thu Nov 21 15:58:17 2013 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 B31F91AE2E5 for ; Thu, 21 Nov 2013 15:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 e-7TvA_X43FE for ; Thu, 21 Nov 2013 15:58:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A596C1AE2CA for ; Thu, 21 Nov 2013 15:58:16 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rALNvx2C024724; Thu, 21 Nov 2013 15:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385078285; bh=kmu/J7FP9PncBwU3xwWH8DmZD3MmnlqxMlJLqBFzaXw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DPdzPBQW/qW1aLVymbWGpjgeN8pEEBGERTzeC5jJ1nzqqhYRqFynu0WqFdiWAE9cy AQVrJGV0mORnL97JXdOSsAt4wUII8l5RPxm7p6s9MIHZaJLz2rKMcUFiZcyfGsBWmR F+ZrqxHoQ3YXeu3pQIPPCOYEa11WeRvY3yM+5TP0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385078285; i=@resistor.net; bh=kmu/J7FP9PncBwU3xwWH8DmZD3MmnlqxMlJLqBFzaXw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iGIgZgPXThu2uftM5NzqLxrcCZlFncNAqlm9mWwF5k7s4ZcFHwbmWDQSHmQ4R64Ww RIU54vKp6EUsHlNjHPOs7aF/nTy5thIdoAT+wJs/wPoc07G0kl1Xf5p4mVPSM0JEVq XF0xprlWY5FN7/FSEJ/S/KMm8NLggnYhmRFiK3VI= Message-Id: <6.2.5.6.2.20131121153227.0ba37de0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Nov 2013 15:47:09 -0800 To: "Moriarty, Kathleen" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org, Nate Cardozo Subject: Re: [perpass] Crypto scorecard released by EFF 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, 21 Nov 2013 23:58:17 -0000 Hi Kathleen, [Courtesy copy to one of the authors of the article] At 14:08 20-11-2013, Moriarty, Kathleen wrote: >EFF released a 'report card' for encryption capabilities of 18 >companies and may be of interest to many of you. It is meant as a >positive encouragement to other companies to expand crypto >capabilities per the web link. Ned already commented [1] on the report. The report's title is "Encrypt the Web Report". The reports discusses about mail (SMTP, IMAP, etc). That's not the web in my humble opinion. The last row in the second column (https) mentions mail. Mixing mail and web creates a confusing picture. The end-result is that the chart can lead to misinterpretation. Regards, -sm 1. http://www.ietf.org/mail-archive/web/perpass/current/msg01106.html From sm@resistor.net Thu Nov 21 16:00:56 2013 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 7CC621AE33F for ; Thu, 21 Nov 2013 16:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 ME2ZWKtm1dAQ for ; Thu, 21 Nov 2013 16:00:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 981311AE33A for ; Thu, 21 Nov 2013 16:00:55 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rALNvx2E024724; Thu, 21 Nov 2013 15:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385078290; bh=FH/xVq051+hdmDT9cF4T1Lid0cOMJfMSCteYYyvv80g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dVlUHi3aGYrtubQl2490TEaDtIlboC7DN6PLEqerVBsI+Gr0n66MlN3JUN3Xp2Dbx yfroTg8pMdyXp1VVCE4fUjDJNhlziephoW3ewKrel1oG+bDpDasthad1pI8kIlGHM2 RyyJyju/jm2Ft1wzeFnvyY7JXmxQYjGQiOBMwGEw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385078290; i=@resistor.net; bh=FH/xVq051+hdmDT9cF4T1Lid0cOMJfMSCteYYyvv80g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZErl6O0wT9mg9/tF8fPodw/dGjWsVJCaqN+zUav0Rhf/PcfTuUrCtgN5AtGcpy7kV K4yHOp8WE1q4Qik9MgM6E0DKvEFvKzN+RQQ13UqbdxS4FBcNgV0+9iJbGega8ne8iO 3qkRCfPbjW7KXilgKOLrysNSjux93RnkTjxJp7Mk= Message-Id: <6.2.5.6.2.20131121155128.0ba36fc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Nov 2013 15:56:05 -0800 To: Robin Wilton From: SM In-Reply-To: References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass , Jon Callas , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 22 Nov 2013 00:00:56 -0000 Hi Robin, At 15:27 21-11-2013, Robin Wilton wrote: >I'm not sure I agree... in this context, "bad actors" are those who >exploit their legitimate participation in a system to act in >illegitimate ways, advancing their interests regardless of the >disbenefit to others or to the system itself. > >That's not necessarily adversarial... I am nitpicking instead of commenting about the draft. :-) There is a SIDR draft written by Stephen Kent about threats. It might be a useful read to figure out the right word(s). Regards, -sm From kent@bbn.com Fri Nov 22 06:56:59 2013 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 1A4161AE14D for ; Fri, 22 Nov 2013 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 EOBWzKTkqklN for ; Fri, 22 Nov 2013 06:56:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 546501AE149 for ; Fri, 22 Nov 2013 06:56:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58305 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VjsA1-000AhR-At for perpass@ietf.org; Fri, 22 Nov 2013 09:56:45 -0500 Message-ID: <528F70AC.8020306@bbn.com> Date: Fri, 22 Nov 2013 09:56:44 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] "Its an attack" BCP draft 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, 22 Nov 2013 14:56:59 -0000 Robin, Jon is correct in term of the usual terminology employed in the security community. Also, because we have said that we are trying to address passive wiretapping effected by a wide range of adversaries, I don't think we're focusing exclusively on entities who are "legitimate" participants. Steve On 11/21/13 6:27 PM, Robin Wilton wrote: > I'm not sure I agree... in this context, "bad actors" are those who > exploit their legitimate participation in a system to act in > illegitimate ways, advancing their interests regardless of the > disbenefit to others or to the system itself. > > That's not necessarily adversarial... > > R From wilton@isoc.org Fri Nov 22 08:55:57 2013 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 4DD291AE3E8 for ; Fri, 22 Nov 2013 08:55:57 -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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMDgf-outfsj for ; Fri, 22 Nov 2013 08:55:55 -0800 (PST) Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) by ietfa.amsl.com (Postfix) with ESMTP id 07F181AE047 for ; Fri, 22 Nov 2013 08:55:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BB19B2480A2; Fri, 22 Nov 2013 11:55:47 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 3A85B2480FA; Fri, 22 Nov 2013 11:55:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_12CE43EA-2792-4FBC-AAF8-E04B14B67ABD"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: <528F70AC.8020306@bbn.com> Date: Fri, 22 Nov 2013 16:55:39 +0000 Message-Id: <2CE72160-0814-457C-A8DD-F01A826D29FB@isoc.org> References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <686FEA45-2F2B-40E8-9063-7180C047483A@icloud.com> <528F70AC.8020306@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1283) Cc: perpass@ietf.org Subject: Re: [perpass] "Its an attack" BCP draft 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, 22 Nov 2013 16:55:57 -0000 --Apple-Mail=_12CE43EA-2792-4FBC-AAF8-E04B14B67ABD Content-Type: multipart/alternative; boundary="Apple-Mail=_47F2BEB7-7DC5-4CFE-B529-ECACB941846B" --Apple-Mail=_47F2BEB7-7DC5-4CFE-B529-ECACB941846B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fair points.=20 There is something about the recent revelations that makes this idea = seem important - of entities who have one nominal role in the = 'ecosystem' but abuse that role to conceal harmful activity... but OK, = we can reflect that in other ways than by the use of the term "bad = actor". Have a good weekend, everyone -=20 Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 22 Nov 2013, at 14:56, Stephen Kent wrote: > Robin, >=20 > Jon is correct in term of the usual terminology employed in the = security community. >=20 > Also, because we have said that we are trying to address passive = wiretapping > effected by a wide range of adversaries, I don't think we're focusing = exclusively > on entities who are "legitimate" participants. >=20 > Steve >=20 > On 11/21/13 6:27 PM, Robin Wilton wrote: >> I'm not sure I agree... in this context, "bad actors" are those who = exploit their legitimate participation in a system to act in = illegitimate ways, advancing their interests regardless of the = disbenefit to others or to the system itself. >>=20 >> That's not necessarily adversarial... >>=20 >> R > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_47F2BEB7-7DC5-4CFE-B529-ECACB941846B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Fair = points. 

There is something about the recent = revelations that makes this idea seem important - of entities who have = one nominal role in the 'ecosystem' but abuse that role to conceal = harmful activity... but OK, we can reflect that in other ways than by = the use of the term "bad actor".

Have a good weekend, = everyone = - 

Robin

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 22 Nov 2013, at 14:56, Stephen Kent wrote:

Robin,

Jon is correct in term of the usual = terminology employed in the security community.

Also, because we = have said that we are trying to address passive wiretapping
effected = by a wide range of adversaries, I don't think we're focusing = exclusively
on entities who are "legitimate" = participants.

Steve

On 11/21/13 6:27 PM, Robin Wilton = wrote:
I'm not sure I agree... in this = context, "bad actors" are those who exploit their legitimate = participation in a system to act in illegitimate ways, advancing their = interests regardless of the disbenefit to others or to the system = itself.

That's not = necessarily adversarial...

R
__________________________________________= _____
perpass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

<= /div>= --Apple-Mail=_47F2BEB7-7DC5-4CFE-B529-ECACB941846B-- --Apple-Mail=_12CE43EA-2792-4FBC-AAF8-E04B14B67ABD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMTIyMTY1NTM5WjAjBgkqhkiG9w0BCQQxFgQUKOtF3YB6XSIZhkdpahEj lbd5LqIwdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAEG1KxtMl9AyZh10Yve+jQ5y Oo4vV1yaFhZhYkTdDUvZTWMuG7IWaqpDKPqf810X+0Q2oSBgMj1nJj9eGUlajiKZS/LlzMh4SIAb fbU2GfZARMZz1V8x4XFeR0xz6y603psxSoCzQrjo6I9zAXW1rqEJMkwk/6A7bOijpYDFFD1lJ6qL O1KpsCX5yGwtS6uX0PA45dYruVwLgJGFNm/PBNUjhtTtbUU3NEqRpDPGbP3XE7u7CZGREWrv26lo M8Dw6Dhe6m+GK+lIribfZBlSxNlrnU9XzQkOwFda0Bi1yaLAakkYISP76vtLB3G8uPOfUryb9J/U LMZBIDKDy0UpHgoAAAAAAAA= --Apple-Mail=_12CE43EA-2792-4FBC-AAF8-E04B14B67ABD-- From warren@kumari.net Fri Nov 22 10:26:05 2013 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 3BDAC1AE091 for ; Fri, 22 Nov 2013 10:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpmkng72xxzo for ; Fri, 22 Nov 2013 10:26:03 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C21ADF89 for ; Fri, 22 Nov 2013 10:26:03 -0800 (PST) Received: from [5.5.8.8] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 979B81B405BE; Fri, 22 Nov 2013 13:25:52 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: Date: Fri, 22 Nov 2013 15:24:44 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70BC6020-DEE1-413D-B6A7-936C1A7B3297@kumari.net> References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com> <528D402F.9040407@comodo.com> <40D06EA2-3369-487F-9D37-AF1E103E8908@fugue.com> <528D4390.3000806@bogus.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) Cc: Joel Jaeggli , perpass , Rob Stradling , Warren Kumari , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 22 Nov 2013 18:26:05 -0000 On Nov 20, 2013, at 8:24 PM, Ted Lemon wrote: > On Nov 20, 2013, at 6:19 PM, joel jaeggli wrote: >> bad actor is a value judgement. have no doubt that the intent of >> surveillance is hostile with respect to the assumputions of the = privacy >> of one's communications. >=20 > It's a lot softer to say "we have to treat passive surveillance as an = attack because there is no way to distinguish between cases where it is = and is not an attack" than it is to say "passive surveillance is an = attack." Of course you can tell them apart -- simply require the passive = surveillant to set the evil bit in all packets that they touch if it is = an attack. If it is *not* an attack, they simply clear the evil bit. The = originating party should randomly (with a good source of randomness (of = course)) set the bit, and track which packets they did this on. The = receiver should track which packets had it set. They then compare (out = of band, and over a secure channel) which packets had the bit set, and = can then determine, with some good probability of detection if someone = was surveilling their traffic.=20 I can extend this solution to other layers with an elegant solution = involving checkboxes=85. There, I fixed it for you=85 W -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken >=20 > The document goes to some lengths not to examine the motivation of the = eavesdropper, so finding a better term than "bad actor" makes sense to = me. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken From dean.willis@softarmor.com Fri Nov 22 23:26:45 2013 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 E2BB81AE135 for ; Fri, 22 Nov 2013 23:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahPwiFPy2VuN for ; Fri, 22 Nov 2013 23:26:44 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6A29F1AE14B for ; Fri, 22 Nov 2013 23:26:44 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id k1so2415095oag.34 for ; Fri, 22 Nov 2013 23:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KiTezyxZePHWbDC/JUHot916iWJZVdHXk72PggnEaV8=; b=Lg+zKmJ+IPevsXU/r7FpOYEIbbwNwkD2rAttGYJO0KFnX2NUXkmzhWT92daUCszOOe Pge+IZC7nyx9tKVf6jKJX28nJifaL4C7irgDNgkS0zwH7PsK8LgTs3jZ3W4CXpc3jV5D KWkZMJlh+GCloSEUM91Ila39kXkrLyS3FNJVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KiTezyxZePHWbDC/JUHot916iWJZVdHXk72PggnEaV8=; b=ZbaS8Gsb7S40vsx80ONuapgE7DbYiyVWntK3jBjB3q1Zq6jN39FNI1xt4yHsHj/kkV 5S2GmjNWQZLTQfbvIN0hc29LdMkYMkIXD//UIWZwMy1HfPI3A6w00q+YMC22EunEOXmk J3U8mzI1vImTzrtvOrpQzDfqriBoy+78bXSZ78VScy9HuQqbbHk8VdSAdPWhI6NJqkz8 oEvOajMFVyROW8BgAdvAYDYCF3I7EF4SsCfA7PtagpitcfpfhH15jbDsvLA+diVcS5iP WRTIOUtYiDjb0yNiIAf6cOu9rSpKdLii9uAUXjnUWXqVUHIKkTWM9XhwWpJtRm1+kU6H vCew== X-Gm-Message-State: ALoCoQmrXJMc4VwMvlE/2l/bIgBW3KrtJJfwmR58dIGBM1FJ5afPYEzmwNHihMA2VHWMeZyF4+yO X-Received: by 10.182.22.18 with SMTP id z18mr740099obe.42.1385191596916; Fri, 22 Nov 2013 23:26:36 -0800 (PST) Received: from [192.168.2.145] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id m7sm53613954obo.7.2013.11.22.23.26.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:26:36 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dean Willis In-Reply-To: <528D3A85.5090003@gmail.com> Date: Sat, 23 Nov 2013 01:26:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <47115845-5892-4BAD-9FBA-0014AC026BE8@softarmor.com> References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1822) Cc: perpass , Stephen Farrell Subject: Re: [perpass] "Its an attack" BCP draft 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, 23 Nov 2013 07:26:46 -0000 On Nov 20, 2013, at 4:41 PM, Brian E Carpenter = wrote: >=20 > However, I am concerned by the 'bad actor' phrase. The problem is > that it's fine as explained in the draft, but it's highly likely to > be quoted out of context and thereby cause confusion. It would be > safer to use a neutral term ('observer'? 'surveyor'?). I like =93perp=94, which is cop-slang for =93perpetrator=94, which they = now tend to say instead of =93suspect=94. But it fits nicely with = =93perpass=94. If the surveillors are the perp in perpass, what does that make the = surveilled? Donkeys? =97 Dean From sm@elandsys.com Sun Nov 24 12:31:27 2013 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 B7C721AE20C for ; Sun, 24 Nov 2013 12:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 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.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-TpB6SFUpId for ; Sun, 24 Nov 2013 12:31:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8F1AE18C for ; Sun, 24 Nov 2013 12:31:26 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.157.109]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAOKV5tK023873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 24 Nov 2013 12:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385325077; bh=2HAr5av+r21GE3Tv+fwSwg1s6Tc146e0FstYjVIYano=; h=Date:To:From:Subject; b=Y32AUlblqV4F5JRi0YevJZcsQu0ZgjOapQAlbuUKrp3aUrl6YxeSIpsQdfibwx5jT 8gf1N/Tti4AhXg4sknDcVtJqUTkJBARePFSvjoMufSgeZdo5N8LcK/MTH6aUoQ2l+P a3+7rDt3WQDDPdawE/aZcvqcdOwilSLBpfsYLzPo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1385325077; i=@elandsys.com; bh=2HAr5av+r21GE3Tv+fwSwg1s6Tc146e0FstYjVIYano=; h=Date:To:From:Subject; b=JHVTwr/LnHKovPO6rMaCC3HogYklBlyAH37nBLWchbdy1Llol7FOY4fI3gFid4JZF puMR6Grdt758H0G6mFNmpf/gGhWHAlT3YTKsU4kU5LfXdqiQyt/2akHcO5ZXd2/K2Z 4DifaslkVLsRcDp3C26Wz8UYZfcuq4/FcU2QXjPg= Message-Id: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 24 Nov 2013 12:29:17 -0800 To: perpass@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [perpass] Traffic peeking 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, 24 Nov 2013 20:31:27 -0000 Hello, I posted a draft about traffic peeking [1]. Comments are welcome. Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-00 From iain.learmonth.09@aberdeen.ac.uk Sun Nov 24 14:37:29 2013 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 B3B251AE1B3 for ; Sun, 24 Nov 2013 14:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wAe4JmuTp0Mk for ; Sun, 24 Nov 2013 14:37:27 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id A45A81AE2E2 for ; Sun, 24 Nov 2013 14:37:26 -0800 (PST) Received: from AMSPR01MB149.eurprd01.prod.exchangelabs.com (10.242.92.15) by AMSPR01MB150.eurprd01.prod.exchangelabs.com (10.242.92.20) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 24 Nov 2013 22:37:18 +0000 Received: from AMSPR01MB149.eurprd01.prod.exchangelabs.com ([169.254.6.237]) by AMSPR01MB149.eurprd01.prod.exchangelabs.com ([169.254.6.237]) with mapi id 15.00.0820.005; Sun, 24 Nov 2013 22:37:17 +0000 From: "Learmonth, Iain Ross" To: S Moonesamy Thread-Topic: [perpass] Traffic peeking Thread-Index: AQHO6VQmhaJr2E88t0GA/BjPpT0YvJo09HPp Date: Sun, 24 Nov 2013 22:37:16 +0000 Message-ID: <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> In-Reply-To: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.92.41.201] x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(83072001)(80022001)(81686001)(74706001)(81342001)(53806001)(74876001)(4396001)(79102001)(87936001)(87266001)(66066001)(65816001)(47736001)(69226001)(2656002)(56816003)(46102001)(49866001)(15975445006)(50986001)(47976001)(81816001)(77096001)(76786001)(76796001)(15202345003)(76482001)(51856001)(54356001)(77982001)(59766001)(80976001)(33646001)(74482001)(83322001)(19580395003)(47446002)(74502001)(85306002)(74316001)(81542001)(74366001)(63696002)(56776001)(19580405001)(54316002)(31966008)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR01MB150; H:AMSPR01MB149.eurprd01.prod.exchangelabs.com; CLIP:84.92.41.201; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] Traffic peeking 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, 24 Nov 2013 22:37:29 -0000 > In 2007, Dan Shumow and Niels Ferguson discussed about the=0A= > possibility of a backdoor in a Dual Elliptic Curve pseudorandom=0A= > number generator [Rump].=0A= =0A= I'm not sure how this paragraph is relevant to the rest of the draft. You o= nly discuss the use of encryption, not particular schemes.=0A= =0A= > Entities exchanging traffic over the Internet should assume that any=0A= > traffic which is not encrypted will be intercepted given that peeking= =0A= > is irresistible.=0A= =0A= This should probably be re-worded to be something like "any traffic which i= s not encrypted should be assumed to be compromised". Let's be honest, they= 're not capturing and storing every single bit of traffic, they definitely = don't have the capacity for that.=0A= =0A= > The Hypertext Transfer Protocol (HTTP) [RFC2616] is widely used to=0A= > access the web. The protocol is sometimes used to provide web access=0A= > to email. Section 15 of RFC 2616 [RFC2616] does not provide any=0A= > guidance about encrypting the traffic generated by the protocol.=0A= =0A= This is currently being discussed by httpbis[1] and any discussion related = to the use of encryption with HTTP should be had there.=0A= =0A= The other protocols will be discussed by the new uta (Using TLS in Applicat= ions) working group[2].=0A= =0A= Other bits in general, there's a lot of talking about state sponsered surve= illence, but there are other problems too. Botnets with nodes operating beh= ind firewalls can sniff the wires, rouge sysadmins, anyone who can poison B= GP tables, etc.=0A= =0A= Encryption is also only half the solution, the other half is authentication= as if you're sending your data encrypted straight to the NSA while they Mi= tM you, you've solved nothing.=0A= =0A= Given that one of the stated tasks for the uta working group is:=0A= =0A= "- Specify a set of best practices for TLS clients and servers, including b= ut not=0A= limited to recommended versions of TLS, using forward secrecy, and one or m= ore=0A= ciphersuites and extensions that are mandatory to implement."=0A= =0A= I believe that this draft would be more suited to be being discussed there.= =0A= =0A= Iain.=0A= =0A= [1]: http://datatracker.ietf.org/wg/httpbis/charter/=0A= [2]: http://datatracker.ietf.org/wg/uta/charter/=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: perpass on behalf of S Moonesamy =0A= Sent: 24 November 2013 20:29=0A= To: perpass@ietf.org=0A= Subject: [perpass] Traffic peeking=0A= =0A= Hello,=0A= =0A= I posted a draft about traffic peeking [1]. Comments are welcome.=0A= =0A= Regards,=0A= S. Moonesamy=0A= =0A= 1. http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-00=0A= =0A= _______________________________________________=0A= perpass mailing list=0A= perpass@ietf.org=0A= https://www.ietf.org/mailman/listinfo/perpass=0A= From sm@elandsys.com Sun Nov 24 16:11:45 2013 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 BF34F1AE2E2 for ; Sun, 24 Nov 2013 16:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 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.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2zZufZuY0EY for ; Sun, 24 Nov 2013 16:11:43 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1A31AE2E9 for ; Sun, 24 Nov 2013 16:11:43 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.157.109]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAP0BJvG016417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Nov 2013 16:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385338291; bh=22Hwi7XhirR+P22Zr30GVRAokQpGrFGvm0yPaVVAV0U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OhqxUtkKo6SEmkQOSNXAU7hlYYydHDxrkYV7NC7mvY1z5MgnRB3VABeaR4b4DIuxB 4DS27Ujcy5GOmDmj38wfatQJwvOEsRL1/rTZG94q2cHvSD1iXorOAETf4abkZxOxyn /1fz/b0IMcn1l+XgKGgDbWlN2yiW7+nN/T5rrkg0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1385338291; i=@elandsys.com; bh=22Hwi7XhirR+P22Zr30GVRAokQpGrFGvm0yPaVVAV0U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0pciVSz22t6rf8arLqgcVYrl8Egq6PSqQPEiFiaXDBQQiCCkO72w44t8dLYV3Onf8 G/z4+7sTdhoO0BOuQYu2Y7cp5G6QGejMONPvQV8JqgYYCHwQCe8s7IxX+8cHcIl9sh SKgqq3FaBs6TBiCGCiZ8OYGKAazjeJqCaAbnkGbs= Message-Id: <6.2.5.6.2.20131124144605.0a990610@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 24 Nov 2013 16:10:16 -0800 To: "Learmonth, Iain Ross" From: S Moonesamy In-Reply-To: <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.pro d.exchangelabs.com> References: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Traffic peeking 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, 25 Nov 2013 00:11:45 -0000 Hi Iain, Thanks for the feedback. At 14:37 24-11-2013, Learmonth, Iain Ross wrote: > > In 2007, Dan Shumow and Niels Ferguson discussed about the > > possibility of a backdoor in a Dual Elliptic Curve pseudorandom > > number generator [Rump]. > >I'm not sure how this paragraph is relevant to the rest of the >draft. You only discuss the use of encryption, not particular schemes. The sentence is more of a lead-in to standardization of encryption schemes. Discussing about particular schemes is like jumping into the solution. I'll look into the above again once the SAAG minutes are published. > > Entities exchanging traffic over the Internet should assume that any > > traffic which is not encrypted will be intercepted given that peeking > > is irresistible. > >This should probably be re-worded to be something like "any traffic >which is not encrypted should be assumed to be compromised". Let's >be honest, they're not capturing and storing every single bit of >traffic, they definitely don't have the capacity for that. In my humble opinion it is more complicated than that. I agree that not all traffic is being captured and stored. The usage of the term "meta-data" within the IETF is different from that used in other venues. The reduction in what could be stored is 1:150 (unverified information). I'll go with the wording you proposed as it is a better fit. > > The Hypertext Transfer Protocol (HTTP) [RFC2616] is widely used to > > access the web. The protocol is sometimes used to provide web access > > to email. Section 15 of RFC 2616 [RFC2616] does not provide any > > guidance about encrypting the traffic generated by the protocol. > >This is currently being discussed by httpbis[1] and any discussion >related to the use of encryption with HTTP should be had there. I avoided mentioning protocols which are work in progress, i.e. what is being discussed in HTTPBIS. >The other protocols will be discussed by the new uta (Using TLS in >Applications) working group[2]. I don't recall joining that mailing list. I'll take a look at it. >Other bits in general, there's a lot of talking about state >sponsered surveillence, but there are other problems too. Botnets >with nodes operating behind firewalls can sniff the wires, rouge >sysadmins, anyone who can poison BGP tables, etc. In a way the above highlights the problem. The discussion has been focused on state sponsored surveillance while there has been little discussion of the other problems. >Encryption is also only half the solution, the other half is >authentication as if you're sending your data encrypted straight to >the NSA while they MitM you, you've solved nothing. The problem with authentication is that it can cause a problem for anonymity. Every solution comes with its share of problems. The draft does not discuss the entire matter as an IETF security problem. It recognizes that some of issues are related to policy. If you put policy in a protocol people won't like it. The people will find a way around that and you won't like that. >Given that one of the stated tasks for the uta working group is: > >"- Specify a set of best practices for TLS clients and servers, >including but not >limited to recommended versions of TLS, using forward secrecy, and one or more >ciphersuites and extensions that are mandatory to implement." > >I believe that this draft would be more suited to be being discussed there. Although the draft mentions some application protocols it isn't specific to applications. I doubt that that proposed working group would take up the draft. Regards, S. Moonesamy From eburger@standardstrack.com Mon Nov 25 04:46:43 2013 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 EA2901AD957 for ; Mon, 25 Nov 2013 04:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 Ll42NMClotkZ for ; Mon, 25 Nov 2013 04:46:41 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1A1AD34C for ; Mon, 25 Nov 2013 04:46:41 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:53065 helo=[192.168.15.105]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VkvYm-00014J-9K for perpass@ietf.org; Mon, 25 Nov 2013 04:46:41 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_2F4A1F7C-239A-4375-80AE-E9AC52CA3B99"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <06D44542-5BB7-4046-86EE-CD24B3D052E4@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Mon, 25 Nov 2013 07:46:34 -0500 References: <5287FA09.3060100@gmail.com> , <528837B4.7000601@gmail.com> <5289125D.6020100@gmail.com> To: perpass In-Reply-To: X-Mailer: Apple Mail (2.1822) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS] 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, 25 Nov 2013 12:46:43 -0000 --Apple-Mail=_2F4A1F7C-239A-4375-80AE-E9AC52CA3B99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Is it physically possible to tell the difference between a CDN and a = MITM? IMHO the only way of doing this is if the authentication token = presented by the CDN saying it represents the source is if that token is = issued (signed) by the source. In theory, no problem. X.509 chains have no problem with Symantec = issuing a certificate to foo (the source) and foo issuing a certificate = on foo=92s behalf to bar (the CDN). In reality, foo is buying service from bar *because* they are not in the = IT business. They want bar to handle all of the =93technical stuff.=94 If we can make this easy, we can break the CDN =3D MITM connection. On Nov 17, 2013, at 2:00 PM, Brian E Carpenter = wrote: >=20 > On 17/11/2013 22:25, Learmonth, Iain Ross wrote: >>>> Also, to completely contradict that point, facebook with https = enabled still uses a CDN, so the theory that https prevents CDNs from = working is apparently wrong anyway. >>=20 >>> I said "possibly" because I wasn't sure. Maybe somebody can explain >> how it works and how the associated trust model works? >>=20 >> The CDN has one TLS connection from the client to the CDN and another = from the CDN to the server, it sees everything in plaintext. A CA signs = the CDNs TLS server certificate so that it can still be accepted by = browsers. Depending on the CA, different verifications of ownership may = be made. >>=20 >> This does raise the issue that these CDNs, which may be managing many = large services, would be a great place to tap the wires. Maybe we should = be discouraging them? >=20 > Yep, that's my concern about the trust model (also after redaing Ted = Lemon's response). >=20 > All I know is that some site I have decided to trust has redirected me > to content on a third-party site, which presents an apparently valid = cert. > I don't understand why I should trust that third-party site. >=20 > Brian > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_2F4A1F7C-239A-4375-80AE-E9AC52CA3B99 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 iQIcBAEBAgAGBQJSk0arAAoJEDY/T2tCIPW3O5gQAIbo+EV6G8MRT8XC2ulovdPg ixapn36Hcl/x17jg2VwaVXpXkhOsyPWVmdq/dhlwVjYE3Y3XDUX+Arvdfo/WB7bs /mCFMu764b8/3csxpeLAEg2KDBvMVEFquvXGbiVnYmJfahtAi3GmNzdsnsECZJPa F2te+iEkL0G200K8Kg0rv0IQWcymJ2e9p0TuOWo5x0gxmvuEfCYmIqB0+2XNaos8 JLlrQ7hCPkLxY2cA59ygWzPyOCj88BdO5wcUwZLVyrexMeSrEwrt1XL440lScKvo OWNO3R/Z4eaOtPclSrDuigW5GjUl8jubAyPCVeBrlmh73fyxMKR2aVic+T5o3XLx Z8uZS7v+5QeYTSj5ztkVbJp7itfZ+WImLKW3ujhU0U5p0nwpHQ5DyvJIi87fpoUc wBEWO8Maepb9KXr5q0vnS6H4iYkOc76wUfzi8n+quFkpFd0wf9FJrcsBR1TLSRJp Qs45pPMeY8/OFK6ai53p+C+KeFDJ3xPi5DeC3p/224MbCCyJRTWt97hEqry9y8yE xUxWlgrhcSBF1CQGU3yYh3QNFJMjYQZR90bPjAgGkbxglWl+AK6wpR9OHYNKWbIG 77RS8mHF5WGvnFkdMoHU2frTHac0kRpJqjXXeM1n3/+hJ+nLqcXF1RCxtSz0PjFt hsc8MT5ar95/3l50P/5C =Rwdu -----END PGP SIGNATURE----- --Apple-Mail=_2F4A1F7C-239A-4375-80AE-E9AC52CA3B99-- From iain.learmonth.09@aberdeen.ac.uk Mon Nov 25 05:18:49 2013 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 386031AD6C1 for ; Mon, 25 Nov 2013 05:18:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2N_gGuZM2nR for ; Mon, 25 Nov 2013 05:18:46 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0082.outbound.protection.outlook.com [213.199.154.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1921ACCE3 for ; Mon, 25 Nov 2013 05:18:45 -0800 (PST) Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB156.eurprd01.prod.exchangelabs.com (10.141.2.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 25 Nov 2013 13:18:45 +0000 Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Mon, 25 Nov 2013 13:18:45 +0000 From: "Learmonth, Iain Ross" To: Eric Burger Thread-Topic: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS] Thread-Index: AQHO6dxpycQ9awqVTkuFpL1Gzz+Slpo17JOp Date: Mon, 25 Nov 2013 13:18:45 +0000 Message-ID: <2f15a7307f4f409db7be7b620d56f3ef@DB3PR01MB153.eurprd01.prod.exchangelabs.com> References: <5287FA09.3060100@gmail.com> , <528837B4.7000601@gmail.com> <5289125D.6020100@gmail.com> , <06D44542-5BB7-4046-86EE-CD24B3D052E4@standardstrack.com> In-Reply-To: <06D44542-5BB7-4046-86EE-CD24B3D052E4@standardstrack.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.50.178.224] x-forefront-prvs: 0041D46242 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(51704005)(479174003)(377454003)(69226001)(81342001)(76786001)(76796001)(74316001)(56816003)(77096001)(74482001)(74502001)(74662001)(74366001)(49866001)(31966008)(46102001)(47446002)(33646001)(74876001)(81816001)(15975445006)(59766001)(77982001)(56776001)(54316002)(76482001)(80976001)(83322001)(54356001)(85306002)(19580395003)(19580405001)(81686001)(74706001)(2656002)(4396001)(47976001)(65816001)(80022001)(53806001)(47736001)(87936001)(50986001)(87266001)(83072001)(79102001)(81542001)(51856001)(66066001)(63696002)(224303002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB156; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:137.50.178.224; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aberdeen.ac.uk Cc: perpass Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS] 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, 25 Nov 2013 13:18:49 -0000 It could be that a CA does have a problem with signing a cert that can be u= sed to sign other certs that would potentially be mishandled by a non-techn= ical group allowing certs that appear to have a trust chain back to the CA = whereas the CA hasn't really verified anything about those downstream signi= ngs.=0A= =0A= Iain.=0A= =0A= --=0A= Iain R. Learmonth MBCS=0A= Electronics Research Group=0A= School of Engineering=0A= University of Aberdeen=0A= Kings College=0A= Aberdeen=0A= AB24 3UE=0A= =0A= Tel: +44 1224 27 2799=0A= =0A= The University of Aberdeen is a charity registered in Scotland No.SCO13683= =0A= =0A= ________________________________________=0A= From: perpass on behalf of Eric Burger =0A= Sent: 25 November 2013 12:46=0A= To: perpass=0A= Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral k= eying in HTTP/1.0 without TLS]=0A= =0A= Is it physically possible to tell the difference between a CDN and a MITM? = IMHO the only way of doing this is if the authentication token presented by= the CDN saying it represents the source is if that token is issued (signed= ) by the source.=0A= =0A= In theory, no problem. X.509 chains have no problem with Symantec issuing a= certificate to foo (the source) and foo issuing a certificate on foo=92s b= ehalf to bar (the CDN).=0A= =0A= In reality, foo is buying service from bar *because* they are not in the IT= business. They want bar to handle all of the =93technical stuff.=94=0A= =0A= If we can make this easy, we can break the CDN =3D MITM connection.=0A= =0A= On Nov 17, 2013, at 2:00 PM, Brian E Carpenter wrote:=0A= =0A= >=0A= > On 17/11/2013 22:25, Learmonth, Iain Ross wrote:=0A= >>>> Also, to completely contradict that point, facebook with https enabled= still uses a CDN, so the theory that https prevents CDNs from working is a= pparently wrong anyway.=0A= >>=0A= >>> I said "possibly" because I wasn't sure. Maybe somebody can explain=0A= >> how it works and how the associated trust model works?=0A= >>=0A= >> The CDN has one TLS connection from the client to the CDN and another fr= om the CDN to the server, it sees everything in plaintext. A CA signs the C= DNs TLS server certificate so that it can still be accepted by browsers. De= pending on the CA, different verifications of ownership may be made.=0A= >>=0A= >> This does raise the issue that these CDNs, which may be managing many la= rge services, would be a great place to tap the wires. Maybe we should be d= iscouraging them?=0A= >=0A= > Yep, that's my concern about the trust model (also after redaing Ted Lemo= n's response).=0A= >=0A= > All I know is that some site I have decided to trust has redirected me=0A= > to content on a third-party site, which presents an apparently valid cert= .=0A= > I don't understand why I should trust that third-party site.=0A= >=0A= > Brian=0A= > _______________________________________________=0A= > perpass mailing list=0A= > perpass@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/perpass=0A= =0A= =0A= From kent@bbn.com Mon Nov 25 06:11:02 2013 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 CD44E1ADBE5 for ; Mon, 25 Nov 2013 06:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ty27tLQgE1Kx for ; Mon, 25 Nov 2013 06:11:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CA5751ADBD3 for ; Mon, 25 Nov 2013 06:11:00 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:59788 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VkwsO-0007G5-JR for perpass@ietf.org; Mon, 25 Nov 2013 09:11:00 -0500 Message-ID: <52935A75.1090907@bbn.com> Date: Mon, 25 Nov 2013 09:11:01 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: <5287FA09.3060100@gmail.com> , <528837B4.7000601@gmail.com> <5289125D.6020100@gmail.com> , <06D44542-5BB7-4046-86EE-CD24B3D052E4@standardstrack.com> <2f15a7307f4f409db7be7b620d56f3ef@DB3PR01MB153.eurprd01.prod.exchangelabs.com> In-Reply-To: <2f15a7307f4f409db7be7b620d56f3ef@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS] 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, 25 Nov 2013 14:11:03 -0000 Iain, You're right, but there the Basic Constraints extension can be used to limit the length of the cert chain, and thus minimize the problem. Steve From stephen.farrell@cs.tcd.ie Mon Nov 25 06:24:38 2013 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 464601ADBCB for ; Mon, 25 Nov 2013 06:24:38 -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, RP_MATCHES_RCVD=-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 f5H5hUF2aKfj for ; Mon, 25 Nov 2013 06:24: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 BA3051AD9AD for ; Mon, 25 Nov 2013 06:24:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A981FBE53; Mon, 25 Nov 2013 14:24:36 +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 X7n7p+VZ8-BA; Mon, 25 Nov 2013 14:24:36 +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 86432BE4C; Mon, 25 Nov 2013 14:24:36 +0000 (GMT) Message-ID: <52935DA5.90309@cs.tcd.ie> Date: Mon, 25 Nov 2013 14:24:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: S Moonesamy , "Learmonth, Iain Ross" References: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <6.2.5.6.2.20131124144605.0a990610@elandnews.com> In-Reply-To: <6.2.5.6.2.20131124144605.0a990610@elandnews.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: [perpass] UTA charter (was: Re: Traffic peeking) 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, 25 Nov 2013 14:24:38 -0000 On 11/25/2013 12:10 AM, S Moonesamy wrote: > >> The other protocols will be discussed by the new uta (Using TLS in >> Applications) working group[2]. > > I don't recall joining that mailing list. I'll take a look at it. I don't believe a list was setup for that just yet. The charter was sent out for review on the IETF list [1] on Friday last. I'd say discussion of that charter would be best done on apps-discuss@ietf.org since its proposed as an APPS area WG and the apps-discuss list is probably where there's the best concentration of relevant expertise, so please direct any substantive discussion there. Assuming the WG gets approved, which I'd expect, we'll be able to chalk that one up as having being sufficiently triaged here:-) S. [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12140.html From rlb@ipv.sx Mon Nov 25 07:02:26 2013 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 6E7171ADBE5 for ; Mon, 25 Nov 2013 07:02:26 -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 1b8OEargX6VA for ; Mon, 25 Nov 2013 07:02:24 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id E83AC1ADEA6 for ; Mon, 25 Nov 2013 07:02:23 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wm4so4300196obc.14 for ; Mon, 25 Nov 2013 07:02:24 -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:date:message-id:subject:from:to :content-type; bh=spWx/h4ebYo7ApLNh64lVr2MR2MdBGCju5NDspXJzro=; b=lryt6VkFFtkW6LPRUPPLkHCgjd8vcu5MuqmH6aEzbqZXe+FS3exkiiGAf+QLQWKzN9 VrqdH/Vkj/3HPFZzqKt6lJ9cH1chZKbxg8WwMfYdqnz1yYdblPpUMQqYJn8Z5U10tMUo h4+Vyd9jW4Noj3KeIbxMkrCkC1t2ieXoswgg0lvs2gKPOBIELHBlc2cm/cIS0CZ7qGRe +8ZUKNKWDSC5qSx+bzKm8gXkc9dilOoj+YM/fpVX8iZB1todRBw5zMN+W5qzV5/r5Cai jN6QR2+2R7jfatthZL0xr3pix9hWb9qk+CcqiTfA4alHEwqfoTSZqoqF4t1jp1unZE1c CuBA== X-Gm-Message-State: ALoCoQnaSwY+aIbxmrsGgd2v1YouS3ovfz58i1vJAneH0pH0cH7lUkJUPD7DdnZ2mP84MIVyc3MC MIME-Version: 1.0 X-Received: by 10.182.135.165 with SMTP id pt5mr639967obb.66.1385391743960; Mon, 25 Nov 2013 07:02:23 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 25 Nov 2013 07:02:23 -0800 (PST) Date: Mon, 25 Nov 2013 10:02:23 -0500 Message-ID: From: Richard Barnes To: perpass Content-Type: multipart/alternative; boundary=089e0112cb9ec6437c04ec01a627 Subject: [perpass] The problem with scaling authentication... 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, 25 Nov 2013 15:02:26 -0000 --089e0112cb9ec6437c04ec01a627 Content-Type: text/plain; charset=ISO-8859-1 ... is that the authorities can make bad decisions. The Economist has an article this week about suspect passport issuance practices among a collection of Caribbean nations. For example, an official in Suriname simultaneously serving as counter-terrorism official and issuing false passports to Hezbollah. Or several countries that now allow "economic citizenship" for a few 100k$. Just wanted to observe that authentication woes are not unique to the Internet and its collection of CAs. Authenticating things on a global basis is hard. < http://www.economist.com/news/americas/21590574-murky-world-bouterses-passports-ignominy > --089e0112cb9ec6437c04ec01a627 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
... is that the authorities can make bad decisio= ns.=A0

The Economist has an article this week about suspect p= assport issuance practices among a collection of Caribbean nations.=A0 For = example, an official in Suriname simultaneously serving as counter-terroris= m official and issuing false passports to Hezbollah.=A0 Or several countrie= s that now allow "economic citizenship" for a few 100k$.

Just wanted to observe that authentication woes are not unique to the I= nternet and its collection of CAs.=A0 Authenticating things on a global bas= is is hard.
--089e0112cb9ec6437c04ec01a627-- From sm@resistor.net Mon Nov 25 11:25:52 2013 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 B5D5C1ADF80 for ; Mon, 25 Nov 2013 11:25: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKz9hku9FBdH for ; Mon, 25 Nov 2013 11:25:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12B61AE00D for ; Mon, 25 Nov 2013 11:25:51 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAPJPkAu012729; Mon, 25 Nov 2013 11:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385407551; bh=hMRZHKZEO2qvXgj28z4AN4KnAEu/rh63u2rENfaRY3o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ztcagksrd4VF9NK8kJjYAf3RNWmGWBiA5ITlHFH/fRJMmSSF9Nkav2WsKD+mZ6R95 fbmn5fc9svTU7M6U1rnfgIT5W8LprTQ7+xWx+SXCNCkY9VYhW/2dP2wybImJJkgP6k 5lhbi5Tqdzq9x8JmiY4kVVUCxMzNxoN7vzDrUqQk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385407551; i=@resistor.net; bh=hMRZHKZEO2qvXgj28z4AN4KnAEu/rh63u2rENfaRY3o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1uv/vVdQFOb2cQrLXsP7rITsSLutgCWOdvWL7tAse6ITRwHr+r8hayT6wPDYlOoj9 fZSyo5rL/SsaSnb2fxilC4PVM9hdPIE02QVFuWoNzzDsIANScPNweqKUybZ9DdTNPX C/AsxIg/S4vLMyFjFMQkQgh2gCILsEoi8ne5Xm10= Message-Id: <6.2.5.6.2.20131125092440.0d240ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Nov 2013 09:42:59 -0800 To: Richard Barnes From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] The problem with scaling authentication... 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, 25 Nov 2013 19:25:52 -0000 Hi Richard, At 07:02 25-11-2013, Richard Barnes wrote: >... is that the authorities can make bad decisions. [snip] >Just wanted to observe that authentication woes are not unique to >the Internet and its collection of CAs. Authenticating things on a >global basis is hard. There is a significant number of examples of bad decisions. I'd say that proof of possession was not used as much in the non-Internet world. Regards, -sm From kent@bbn.com Mon Nov 25 12:14:33 2013 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 6C4E91AE03A for ; Mon, 25 Nov 2013 12:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 7_ZZzGcyniG6 for ; Mon, 25 Nov 2013 12:14:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 450431AE03C for ; Mon, 25 Nov 2013 12:14:31 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48867 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vl2YA-000B7Y-PL for perpass@ietf.org; Mon, 25 Nov 2013 15:14:30 -0500 Message-ID: <5293AFA5.3070804@bbn.com> Date: Mon, 25 Nov 2013 15:14:29 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: <6.2.5.6.2.20131125092440.0d240ae0@resistor.net> In-Reply-To: <6.2.5.6.2.20131125092440.0d240ae0@resistor.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] The problem with scaling authentication... 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, 25 Nov 2013 20:14:33 -0000 >> Just wanted to observe that authentication woes are not unique to the >> Internet and its collection of CAs. Authenticating things on a global >> basis is hard. > > There is a significant number of examples of bad decisions. I'd say > that proof of possession was not used as much in the non-Internet world. > > Regards, > -sm I'm puzzled by your last comment. In the PKI context, the phrase "proof of possession" (PoP) refers to a mechanism used to verify that a subject requesting a cert possesses the private key corresponding to the public key in the cert request. When an entity receives a cert containing Subject name (or Subject alt name) that is not appropriately associated with the entity, that is NOT a failure of PoP. The entity presumably does possess the corresponding private key, since it can't complete a TLS exchange without it. Steve From sm@resistor.net Mon Nov 25 13:51:04 2013 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 2F2B11AE050 for ; Mon, 25 Nov 2013 13:51:04 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2XuXxuL6GTY for ; Mon, 25 Nov 2013 13:51:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 369601AE040 for ; Mon, 25 Nov 2013 13:51:03 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAPLorsa008174; Mon, 25 Nov 2013 13:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385416259; bh=Yprso7yQNeSRBa7cCEBqBO1vZKirk/maSzU8c3JM7YM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P93dL6tK+LgIiczgw18Qu/vvNvnQnbIWRiICgbt5LuUPb/x7pQHmBFyeuTGfDFw8x G6L1WA3GYjpBxqkGSyHX6roTUBPln3tWMeJTCdFo0xl/cT7dt9vi+TJDoIWEwu3/09 lqMWO/h0n5jn51DbYuWWDDw/01iZd0LrihnSQ9CY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385416259; i=@resistor.net; bh=Yprso7yQNeSRBa7cCEBqBO1vZKirk/maSzU8c3JM7YM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DErF7dvaLLhN5F/aQ0qJD94cjFji62gx7uw36ksJedPOb3LqZMgOcG86g3Ib3ns4a 0ombewBS9EOhptXr0cnU5qrPKv2tMQOgdnsyCEKHwB4fXLEjYT9r80eDY9WfEXe23Y 9melwIm+nUtwz2IUK+yyS50q0iBbgu+4bt7Q4Wpw= Message-Id: <6.2.5.6.2.20131125123240.0cbf8680@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Nov 2013 13:42:20 -0800 To: Stephen Kent From: SM In-Reply-To: <5293AFA5.3070804@bbn.com> References: <6.2.5.6.2.20131125092440.0d240ae0@resistor.net> <5293AFA5.3070804@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] The problem with scaling authentication... 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, 25 Nov 2013 21:51:04 -0000 Hi Steve, At 12:14 25-11-2013, Stephen Kent wrote: >I'm puzzled by your last comment. In the PKI context, the phrase >"proof of possession" >(PoP) refers to a mechanism used to verify that a subject requesting >a cert possesses the >private key corresponding to the public key in the cert request. > >When an entity receives a cert containing Subject name (or Subject alt name) >that is not appropriately associated with the entity, that is NOT a failure >of PoP. The entity presumably does possess the corresponding private key, >since it can't complete a TLS exchange without it. I wasn't thinking about failure of PoP or PKI. Your message reminded me that I didn't think about some real world details when I made that comment. Regards, -sm P.S. I was thinking about how often passports were used. From bortzmeyer@nic.fr Wed Nov 27 03:11:32 2013 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 2FEB71AE101 for ; Wed, 27 Nov 2013 03:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-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 MNsHMx81bqoA for ; Wed, 27 Nov 2013 03:11:22 -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 B29A51AE2B9 for ; Wed, 27 Nov 2013 03:08:09 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id F1602280291; Wed, 27 Nov 2013 12:08:07 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id ECC1B28028E; Wed, 27 Nov 2013 12:08:07 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id EA1124C007F; Wed, 27 Nov 2013 12:07:37 +0100 (CET) Date: Wed, 27 Nov 2013 12:07:37 +0100 From: Stephane Bortzmeyer To: Brian Trammell Message-ID: <20131127110737.GA2608@nic.fr> References: <528DF1DD.7010904@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528DF1DD.7010904@tik.ee.ethz.ch> X-Operating-System: Debian GNU/Linux 7.2 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] Of potential interest: MinimaLT 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, 27 Nov 2013 11:11:32 -0000 On Thu, Nov 21, 2013 at 12:43:25PM +0100, Brian Trammell wrote a message of 16 lines which said: > MinimaLT, YA transport layer replacement with a focus on maximizing > confidentiality, was presented at CCS last week in Berlin; Executive summary: each time two machines want to talk, an encrypted tunnel is automatically setup and used afterwards. The encryption setup cost is therefore paid for all the connections (until the teardown). So, some state will be necessary. Biggest problem is that the authentication (apparently in one direction only) is done only by X.509 (so it inherits all of the problems of X.509), with certificates fetched via the DNS. API for the applications is unclear. (It seems done mostly for a new OS, without installed base.) (More detailed analysis, in French ) From bortzmeyer@nic.fr Wed Nov 27 03:46:07 2013 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 18A441AE1A3 for ; Wed, 27 Nov 2013 03:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-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 B7bnfJEfcli6 for ; Wed, 27 Nov 2013 03:46:06 -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 1DF2E1AE1AB for ; Wed, 27 Nov 2013 03:46:06 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6C518280378; Wed, 27 Nov 2013 12:46:05 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 679F12802D5; Wed, 27 Nov 2013 12:46:05 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id 5ADC14C0081; Wed, 27 Nov 2013 12:45:35 +0100 (CET) Date: Wed, 27 Nov 2013 12:45:35 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20131127114535.GA6620@nic.fr> References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> <5242D8AA.4040108@cs.tcd.ie> <20130925124059.GA8996@nic.fr> <20131111121027.GA31723@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131111121027.GA31723@sources.org> X-Operating-System: Debian GNU/Linux 7.2 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 , Andy Wilson Subject: Re: [perpass] DNS confidentiality 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, 27 Nov 2013 11:46:07 -0000 On Mon, Nov 11, 2013 at 01:10:27PM +0100, Stephane Bortzmeyer wrote a message of 14 lines which said: > Done. > http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy Now moved to dnsop, per request of the ADs http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy From dhc@dcrocker.net Wed Nov 27 06:07:04 2013 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 1F2001ADF5C for ; Wed, 27 Nov 2013 06:07:04 -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 zxGt5OklieQd for ; Wed, 27 Nov 2013 06:06:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9BACF1ADEA3 for ; Wed, 27 Nov 2013 06:06:58 -0800 (PST) Received: from [192.168.200.184] (rrcs-74-62-19-234.west.biz.rr.com [74.62.19.234]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rARE6tng031348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Nov 2013 06:06:58 -0800 Message-ID: <5295FC4F.7060309@dcrocker.net> Date: Wed, 27 Nov 2013 06:06: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.1.1 MIME-Version: 1.0 To: perpass 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]); Wed, 27 Nov 2013 06:06:58 -0800 (PST) Subject: [perpass] "Guide to intranet protection"? 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: Wed, 27 Nov 2013 14:07:04 -0000 Morning mid-coffee question: There have been some recent news articles about various major ISPs taking steps to encrypt their (internal) traffic. These prompt me to wonder whether it would be practical and useful for the IETF to produce a basic draft that gives guidance to other ISP and enterprise operators about the steps they should take to protect their traffic. I'm assuming that providing meaningful protection takes a statement beyond "encrypt all your links". Perhaps it doesn't, but I thought I'd ask... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Wed Nov 27 06:13:09 2013 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 929821ADF85 for ; Wed, 27 Nov 2013 06:13:09 -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, RP_MATCHES_RCVD=-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 udMYsWO1guCw for ; Wed, 27 Nov 2013 06:13:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CA2591ADFC7 for ; Wed, 27 Nov 2013 06:12:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19EB6BE58; Wed, 27 Nov 2013 14:12:56 +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 nSD3faVUWFCb; Wed, 27 Nov 2013 14:12:56 +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 F3283BE55; Wed, 27 Nov 2013 14:12:55 +0000 (GMT) Message-ID: <5295FDE8.5000402@cs.tcd.ie> Date: Wed, 27 Nov 2013 14:12:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net, perpass References: <5295FC4F.7060309@dcrocker.net> In-Reply-To: <5295FC4F.7060309@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] "Guide to intranet protection"? 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, 27 Nov 2013 14:13:11 -0000 On 11/27/2013 02:06 PM, Dave Crocker wrote: > Morning mid-coffee question: > > There have been some recent news articles about various major ISPs > taking steps to encrypt their (internal) traffic. These prompt me to > wonder whether it would be practical and useful for the IETF to produce > a basic draft that gives guidance to other ISP and enterprise operators > about the steps they should take to protect their traffic. > > I'm assuming that providing meaningful protection takes a statement > beyond "encrypt all your links". Perhaps it doesn't, but I thought I'd > ask... I'd say that'd be a fine thing if we could get someone who'd done that job to help write it. S. > d/ From hallam@gmail.com Wed Nov 27 06:53:29 2013 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 952161AE046 for ; Wed, 27 Nov 2013 06:53:29 -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 lAmgBdhZxwPr for ; Wed, 27 Nov 2013 06:53:24 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 47A171ADBF7 for ; Wed, 27 Nov 2013 06:53:24 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id w7so5367827lbi.22 for ; Wed, 27 Nov 2013 06:53: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=sSKLfmSWg89VxNPT02scc6/Nbm7xNEA9JpPydQiMeGI=; b=L8YtikWqcIKkWrXXz016SDeL1a7mDdxE7QxKPxDg47xPK63AxRrQqvvVZhl4Dot9MI rjADWD3LmEMqieoUtsyEszmF4FcWRWbI9i4Fp/dV4vSEpcDK9s+Zv6/cyrRFqZgcSY0L l17ASVjFJkjufC4WhGtJBDqh8JYIo9vDDyziX4M1dZz8tYXHrcvxETZQlopnrKM4ApcZ gIxoE9vmjZbNCHIOmjY1hNWWPb/gv43UZh7nU7uDyNRqln3vklec/PCep4s7cez7ZMgJ ltu/mTXAu9EQLFkG8QytoEd5Mp9/jZ4GqVwVy3kRo/m4Zl/3VhmPxz7g5ZfMWNxOBfbc FGmw== MIME-Version: 1.0 X-Received: by 10.112.72.70 with SMTP id b6mr3154543lbv.0.1385564002856; Wed, 27 Nov 2013 06:53:22 -0800 (PST) Received: by 10.112.37.172 with HTTP; Wed, 27 Nov 2013 06:53:22 -0800 (PST) In-Reply-To: <5295FC4F.7060309@dcrocker.net> References: <5295FC4F.7060309@dcrocker.net> Date: Wed, 27 Nov 2013 09:53:22 -0500 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c23c4034350b04ec29c2e5 Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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, 27 Nov 2013 14:53:29 -0000 --001a11c23c4034350b04ec29c2e5 Content-Type: text/plain; charset=ISO-8859-1 +1 But I don't have time to help write it. This proposal is similar to what we did in the CA industry after the Iranian attack against Comodo. We had a series of information sharing sessions. One important consequence for me personally was that Symantec/VeriSign gave a presentation on how the root key management system works which means that I now feel free to talk about that. Although I later discovered that the entire system that I and others considered a highly proprietary trade secret is actually described in detail in the CPS and CP. The big change in mindset was that we recognized that an attack on one of us is an attack on all and that security is not a competitive differentiator. DigiNotar damaged the entire industry. One other point, this is not just one government or even governments. There is a group of ex-NSA staff semi-openly touting 'cyber-defense' operations that include an 'offshore' component. The only reason I can think of to have the operations offshore and boast about them is to perform acts that would be criminal in the US. The individuals behind the company concerned were very senior in a previous administration and quite possibly believe that they can get away with criminal behavior because the establishment will cover up for them. Lawlessness begets lawlessness. People who are accustomed to ignore the laws while working for the government are inclined to continue to ignore them. I expect that in the immediate aftermath of Snowdonia there will be something of an exodus from Fort Meade. And many of those people will take their knowledge with them in their head and have no compunction about putting that knowledge to 'commercial' use. It is all going to end in a very ugly scandal but the perpetrators can do a lot of damage between now and their day of reckoning. People need to put down strong defenses. On Wed, Nov 27, 2013 at 9:06 AM, Dave Crocker wrote: > Morning mid-coffee question: > > There have been some recent news articles about various major ISPs > taking steps to encrypt their (internal) traffic. These prompt me to > wonder whether it would be practical and useful for the IETF to produce a > basic draft that gives guidance to other ISP and enterprise operators about > the steps they should take to protect their traffic. > > I'm assuming that providing meaningful protection takes a statement > beyond "encrypt all your links". Perhaps it doesn't, but I thought I'd > ask... > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -- Website: http://hallambaker.com/ --001a11c23c4034350b04ec29c2e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 But I don't have time to help write it.

This proposal is similar to what we did in the CA industry after th= e Iranian attack against Comodo. We had a series of information sharing ses= sions. One important consequence for me personally was that Symantec/VeriSi= gn gave a presentation on how the root key management system works which me= ans that I now feel free to talk about that. Although I later discovered th= at the entire system that I and others considered a highly proprietary trad= e secret is actually described in detail in the CPS and CP.

The big change in mindset was that we recognized that a= n attack on one of us is an attack on all and that security is not a compet= itive differentiator. DigiNotar damaged the entire industry.=A0


One other point, this is not just one governm= ent or even governments. There is a group of ex-NSA staff semi-openly touti= ng 'cyber-defense' operations that include an 'offshore' co= mponent. The only reason I can think of to have the operations offshore and= boast about them is to perform acts that would be criminal in the US.

The individuals behind the company concerned were very = senior in a previous administration and quite possibly believe that they ca= n get away with criminal behavior because the establishment will cover up f= or them.

Lawlessness begets lawlessness. People who are accustom= ed to ignore the laws while working for the government are inclined to cont= inue to ignore them.=A0

I expect that in the immed= iate aftermath of Snowdonia there will be something of an exodus from Fort = Meade. And many of those people will take their knowledge with them in thei= r head and have no compunction about putting that knowledge to 'commerc= ial' use.=A0

It is all going to end in a very ugly scandal but the p= erpetrators can do a lot of damage between now and their day of reckoning. = People need to put down strong defenses.

=A0


On Wed,= Nov 27, 2013 at 9:06 AM, Dave Crocker <dhc@dcrocker.net> wro= te:
Morning mid-coffee question:

=A0 =A0 =A0There have been some recent news articles about various major IS= Ps taking steps to encrypt their (internal) traffic. =A0These prompt me to = wonder whether it would be practical and useful for the IETF to produce a b= asic draft that gives guidance to other ISP and enterprise operators about = the steps they should take to protect their traffic.

=A0 =A0 =A0I'm assuming that providing meaningful protection takes a st= atement beyond "encrypt all your links". =A0Perhaps it doesn'= t, but I thought I'd ask...

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass



-- Website: http://hallambaker.com/<= br>
--001a11c23c4034350b04ec29c2e5-- From bortzmeyer@nic.fr Wed Nov 27 07:06:22 2013 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 294841AE05D for ; Wed, 27 Nov 2013 07:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-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 lpu7EeIJJB-M for ; Wed, 27 Nov 2013 07:06:19 -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 AF3041ADBE8 for ; Wed, 27 Nov 2013 07:06:19 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C09CC28048A; Wed, 27 Nov 2013 16:06:18 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id BBE3628038C; Wed, 27 Nov 2013 16:06:18 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id B94764C007F; Wed, 27 Nov 2013 16:05:48 +0100 (CET) Date: Wed, 27 Nov 2013 16:05:48 +0100 From: Stephane Bortzmeyer To: Nicholas Weaver Message-ID: <20131127150548.GA25960@nic.fr> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> X-Operating-System: Debian GNU/Linux 7.2 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] A reminder, the Network is the Enemy... 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, 27 Nov 2013 15:06:22 -0000 On Wed, Nov 20, 2013 at 12:42:53PM -0800, Nicholas Weaver wrote a message of 70 lines which said: > http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/ You mention DNSSEC twice, as a solution against some man-on-the-side attacks (injecting false DNS answers). The Schneier paper about QUANTUM mentions packet injection but not the DNS. We don't know if the NSA does DNS poisoning (but we may assume they - and other actors - do it). However, if the attacker is the NSA, we have to take into account the possibility that they can sign data with the root's private key, which is under US management. Therefore, is DNSSEC still useful? May be, in these cases: * the attacker may consider that DNSSEC validation is so uncommon today that it is not worth the work to inject spoofed RRSIG * some people may have trust anchors located at lower levels (some registries do publish them for instance ). Do you think it is technically sound? Many people decided not to publish these trust anchors, because of the management costs and risks, but it was before Snowden. May be we should actively recommend the publication of such "lower" trust anchors now? From stephen.farrell@cs.tcd.ie Wed Nov 27 07:11:08 2013 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 607481AE07F for ; Wed, 27 Nov 2013 07:11:08 -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, RP_MATCHES_RCVD=-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 jKaRJWJzsCrz for ; Wed, 27 Nov 2013 07:11:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E61321ADBC9 for ; Wed, 27 Nov 2013 07:10:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B528BE5B; Wed, 27 Nov 2013 15:10: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 U8DtTgy7dn5O; Wed, 27 Nov 2013 15:10: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 B62F5BE2F; Wed, 27 Nov 2013 15:10:57 +0000 (GMT) Message-ID: <52960B81.2060008@cs.tcd.ie> Date: Wed, 27 Nov 2013 15:10:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> <5242D8AA.4040108@cs.tcd.ie> <20130925124059.GA8996@nic.fr> <20131111121027.GA31723@sources.org> <20131127114535.GA6620@nic.fr> In-Reply-To: <20131127114535.GA6620@nic.fr> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Andy Wilson Subject: Re: [perpass] DNS confidentiality 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, 27 Nov 2013 15:11:08 -0000 On 11/27/2013 11:45 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 11, 2013 at 01:10:27PM +0100, > Stephane Bortzmeyer wrote > a message of 14 lines which said: > >> Done. >> http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy > > Now moved to dnsop, per request of the ADs > > http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy Cool. Another one triaged:-) S. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From jari.arkko@piuha.net Wed Nov 27 13:10:27 2013 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 B98071AE14B for ; Wed, 27 Nov 2013 13:10:27 -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, RP_MATCHES_RCVD=-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 s_YfJ2L55vkO for ; Wed, 27 Nov 2013 13:10:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C76F41ADF27 for ; Wed, 27 Nov 2013 13:10:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 30BD52CC6B; Wed, 27 Nov 2013 23:10:23 +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 vhsjpqgmh4jZ; Wed, 27 Nov 2013 23:10:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B26792CC48; Wed, 27 Nov 2013 23:10:22 +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: <528D34D7.1010303@cs.tcd.ie> Date: Wed, 27 Nov 2013 23:10:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <528D34D7.1010303@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1510) Cc: perpass Subject: Re: [perpass] "Its an attack" BCP draft 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, 27 Nov 2013 21:10:28 -0000 > then we'll ask Jari to start a > 4-week IETF LC for it. When he thinks that's ok he'll start it > and then we'll see how that goes. I just wanted to send out a message saying that I'm watching this.=20 Stephen's message had a lot of explanation of what the IAB and IESG = think about it. I do think, however, the key is what the IETF thinks. = Obviously. So lets keep those comments coming, so that Stephen/Hannes = and I can do an initial assessment of what if anything needs to change = in the -00 for me to start an IETF Last Call. Jari From randy@psg.com Wed Nov 27 19:43:51 2013 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 6DADD1AE0F9 for ; Wed, 27 Nov 2013 19:43:51 -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, RP_MATCHES_RCVD=-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 29-b4DOoGbrK for ; Wed, 27 Nov 2013 19:43:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id E785F1AE0AD for ; Wed, 27 Nov 2013 19:43:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VlsVw-0007yT-23; Thu, 28 Nov 2013 03:43:41 +0000 Date: Thu, 28 Nov 2013 11:43:35 +0800 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <5295FDE8.5000402@cs.tcd.ie> References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass , dcrocker@bbiw.net Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 03:43:51 -0000 >> I'm assuming that providing meaningful protection takes a statement >> beyond "encrypt all your links". Perhaps it doesn't, but I thought >> I'd ask... > I'd say that'd be a fine thing if we could get someone who'd done that > job to help write it. may not work out as well as we might wish, as folk who have done it may not want to disclose details. but i am sure there are folk who have not done it who will be happy to tell others how they should run their networks :) randy From dhc@dcrocker.net Wed Nov 27 20:39:30 2013 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 4618C1AE10A for ; Wed, 27 Nov 2013 20:39:30 -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 pl84AA59M_Vf for ; Wed, 27 Nov 2013 20:39:28 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA5EB1ADF87 for ; Wed, 27 Nov 2013 20:39:28 -0800 (PST) Received: from [10.211.51.212] (rbiguest.jcresorts.com [206.170.126.120] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rAS4dOfn025753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Nov 2013 20:39:28 -0800 Message-ID: <5296C8CC.2060508@dcrocker.net> Date: Wed, 27 Nov 2013 20:38:36 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Randy Bush References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> 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.66]); Wed, 27 Nov 2013 20:39:28 -0800 (PST) Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 04:39:30 -0000 On 11/27/2013 7:43 PM, Randy Bush wrote: >>> I'm assuming that providing meaningful protection takes a statement >>> beyond "encrypt all your links". Perhaps it doesn't, but I thought >>> I'd ask... >> I'd say that'd be a fine thing if we could get someone who'd done that >> job to help write it. > > may not work out as well as we might wish, as folk who have done it may > not want to disclose details. but i am sure there are folk who have not > done it who will be happy to tell others how they should run their > networks :) with such a warm and inviting tone being offered at this stage of the topic, i'm sure everyone will feel quite comfortable testing their suggestions and comments, to produce a frank and open exchange that will vet the contents of the draft document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From huitema@huitema.net Wed Nov 27 21:15:33 2013 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 663D31AE0DB for ; Wed, 27 Nov 2013 21:15:33 -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 KzYjsKjFIA-S for ; Wed, 27 Nov 2013 21:15:31 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3331AC828 for ; Wed, 27 Nov 2013 21:15:31 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Vltwn-0004GA-Q8 for perpass@ietf.org; Thu, 28 Nov 2013 00:15:30 -0500 Received: (qmail 12558 invoked from network); 28 Nov 2013 05:15:28 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[72.235.170.205]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Nov 2013 05:15:27 -0000 From: "Christian Huitema" To: , "'perpass'" References: <5295FC4F.7060309@dcrocker.net> In-Reply-To: <5295FC4F.7060309@dcrocker.net> Date: Wed, 27 Nov 2013 21:15:21 -0800 Message-ID: <027801ceebf8$da0328e0$8e097aa0$@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: AQL2Ez6VpOy/raTxzEp1sYC1gihbz5fryxUA Content-Language: en-us Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 05:15:33 -0000 -----Original Message----- From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, November 27, 2013 6:06 AM To: perpass Subject: [perpass] "Guide to intranet protection"? Morning mid-coffee question: There have been some recent news articles about various major ISPs taking steps to encrypt their (internal) traffic. These prompt me to wonder whether it would be practical and useful for the IETF to produce a basic draft that gives guidance to other ISP and enterprise operators about the steps they should take to protect their traffic. I'm assuming that providing meaningful protection takes a statement beyond "encrypt all your links". Perhaps it doesn't, but I thought I'd ask... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From dhc@dcrocker.net Wed Nov 27 21:24:14 2013 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 A60191AE079 for ; Wed, 27 Nov 2013 21:24:14 -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 zwfsS4NUY9Bb for ; Wed, 27 Nov 2013 21:24:13 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6B031AE06D for ; Wed, 27 Nov 2013 21:24:13 -0800 (PST) Received: from [10.211.51.212] (rbiguest.jcresorts.com [206.170.126.120] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rAS5O6l1027514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Nov 2013 21:24:10 -0800 Message-ID: <5296D346.2090300@dcrocker.net> Date: Wed, 27 Nov 2013 21:23:18 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> In-Reply-To: <5295FDE8.5000402@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]); Wed, 27 Nov 2013 21:24:10 -0800 (PST) Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 05:24:14 -0000 On 11/27/2013 6:12 AM, Stephen Farrell wrote: >> I'm assuming that providing meaningful protection takes a statement >> >beyond "encrypt all your links". Perhaps it doesn't, but I thought I'd >> >ask... > I'd say that'd be a fine thing if we could get someone who'd > done that job to help write it. So let's move to the meta-question: what's the benefit that such experts (or their organizations) will accrue from participating? One possible point is that intra-network security probably gets better, the more neighbors there are with equally good security. Fewer sources of badness, and all that... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From huitema@huitema.net Wed Nov 27 21:37:10 2013 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 54F711AE116 for ; Wed, 27 Nov 2013 21:37:10 -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 oTE1uaetpjLE for ; Wed, 27 Nov 2013 21:37:09 -0800 (PST) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) by ietfa.amsl.com (Postfix) with ESMTP id 134BA1AE0E8 for ; Wed, 27 Nov 2013 21:37:09 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VluHj-0003lu-Gp for perpass@ietf.org; Thu, 28 Nov 2013 00:37:07 -0500 Received: (qmail 27221 invoked from network); 28 Nov 2013 05:37:06 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[72.235.170.205]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Nov 2013 05:37:05 -0000 From: "Christian Huitema" To: , "'Randy Bush'" References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> In-Reply-To: <5296C8CC.2060508@dcrocker.net> Date: Wed, 27 Nov 2013 21:37:04 -0800 Message-ID: <027a01ceebfb$df99f290$9ecdd7b0$@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: AQL2Ez6VpOy/raTxzEp1sYC1gihbzwHsqXzSAhtuobgA+sA7rpfDuINg Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 05:37:10 -0000 >> may not work out as well as we might wish, as folk who have done it may >> not want to disclose details. but i am sure there are folk who have not >> done it who will be happy to tell others how they should run their >> networks :) > > with such a warm and inviting tone being offered at this stage of the > topic, i'm sure everyone will feel quite comfortable testing their > suggestions and comments, to produce a frank and open exchange that will > vet the contents of the draft document. Randy is quite right. The attacks reported in the news article were against the private optical fibers linking the geographically distributed data centers of large companies like Google or Yahoo. A discussion about that should start with the folks in charge of securing these data centers at Google, Yahoo, Facebook, Microsoft, et cetera. I can see some difficulties, because a fair bit of the data centers architectures is probably treated as trade secret. And I am really not sure that the IETF is the best place to conduct such discussions. -- Christian Huitema From hallam@gmail.com Wed Nov 27 21:44:21 2013 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 DB4361AE032 for ; Wed, 27 Nov 2013 21:44:21 -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 6VZ4yzxc5VMn for ; Wed, 27 Nov 2013 21:44:20 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A40311ADF52 for ; Wed, 27 Nov 2013 21:44:19 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ep20so5794842lab.3 for ; Wed, 27 Nov 2013 21:44:18 -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=JC0LGS9yS/qiPhPoZCwL6Dete8Bx6pR9QxMeuJAA5CY=; b=RSK1O9lbagKdEz6NEXSd73VcwbeVQoVM6BApnXTxbHaiz5zA7Ir+gyT9YGikBukr6h h87HmAfcXqYW3LpB0ivOtew7DCW+ewOuKfa47tlmgWccxuvBwSL2raZfYvdJ1iSCqfWW KuFrpD0yH+ugK0+b951HcCR5LCQevhi2u9A7ZtGxk06B/pJjYDkgPNjHgUY8gazEIu8C +gHuUVJA1sjbDiIfQ0UlLseRNXc7eJ8euTvhpYDrpiOCHdmLPavMmtVt/MsnXXngMxex 259YPsGtJoEkdEkNXShDN7s0QLYsbM8k/+u59xihWp42TVCJxEF1b2ZAzLuKssqldtAz pUpg== MIME-Version: 1.0 X-Received: by 10.152.120.102 with SMTP id lb6mr3039374lab.37.1385617458139; Wed, 27 Nov 2013 21:44:18 -0800 (PST) Received: by 10.112.37.172 with HTTP; Wed, 27 Nov 2013 21:44:18 -0800 (PST) In-Reply-To: <5296D346.2090300@dcrocker.net> References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296D346.2090300@dcrocker.net> Date: Thu, 28 Nov 2013 00:44:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=089e01227ab66317ea04ec3634c2 Cc: perpass , Stephen Farrell Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 05:44:22 -0000 --089e01227ab66317ea04ec3634c2 Content-Type: text/plain; charset=ISO-8859-1 Dave, This is not really an intranet issue, this is a backbone issue. The two are completely different where security is concerned. There is already a body of literature on setting up corporate VPNs to secure an Intranet. That is all happening at the IP layer and IPSEC is a good tool. What is going on at Google and Yahoo is that they have got to be so large that they are deploying routers that are designed for supporting backbone traffic and they are essentially backbone providers. And the body of work that exists on IPSEC is just not relevant to that part of their problem. It is not a unique problem though. AT&T, Comcast and the backbone providers have the same sort of issues. They are problems that arise from carrying traffic that is coming from someone else who may have a different idea about how confidential it is to the carrier. A group of large enterprises like ICI faced a similar problem a while back and formed the Jericho forum to tell manufacturers what sort of IT security they needed. It might be useful for a group of like minded companies that buy the biggest of the big iron to come together and hammer out security requirements to hand off to the vendors. Might not wok though. Jericho forum closed recently but I can't see any sign of the data level security they were talking about. There is this place in Fort Meade that it seems could use some of that rather badly and they are not the only ones. --089e01227ab66317ea04ec3634c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dave,=A0

This = is not really an intranet issue, this is a backbone issue. The two are comp= letely different where security is concerned.

There is already a body of literature = on setting up corporate VPNs to secure an Intranet. That is all happening a= t the IP layer and IPSEC is a good tool.
What is going on at Google and Yahoo is th= at they have got to be so large that they are deploying routers that are de= signed for supporting backbone traffic and they are essentially backbone pr= oviders. And the body of work that exists on IPSEC is just not relevant to = that part of their problem.

It is not a= unique problem though. AT&T, Comcast and the backbone providers have t= he same sort of issues. They are problems that arise from carrying traffic = that is coming from someone else who may have a different idea about how co= nfidential it is to the carrier.

A group of = large enterprises like ICI faced a similar problem a while back and formed = the Jericho forum to tell manufacturers what sort of IT security they neede= d. It might be useful for a group of like minded companies that buy the big= gest of the big iron to come together and hammer out security requirements = to hand off to the vendors.

Might not w= ok though. Jericho forum closed recently but I can't see any sign of th= e data level security they were talking about. There is this place in Fort = Meade that it seems could use some of that rather badly and they are not th= e only ones.

--089e01227ab66317ea04ec3634c2-- From randy@psg.com Wed Nov 27 22:08:45 2013 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 BDBB51AE0ED for ; Wed, 27 Nov 2013 22:08:45 -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, RP_MATCHES_RCVD=-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 LiqeYlE1uDyf for ; Wed, 27 Nov 2013 22:08:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACB01AE10B for ; Wed, 27 Nov 2013 22:08:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VlumE-0008Bf-CT; Thu, 28 Nov 2013 06:08:39 +0000 Date: Thu, 28 Nov 2013 14:08:37 +0800 Message-ID: From: Randy Bush To: "Christian Huitema" In-Reply-To: <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: 'perpass' , dcrocker@bbiw.net Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 06:08:46 -0000 > Randy is quite right. has to happen occasionally > The attacks reported in the news article were against the private > optical fibers linking the geographically distributed data centers of > large companies like Google or Yahoo. A discussion about that should > start with the folks in charge of securing these data centers at > Google, Yahoo, Facebook, Microsoft, et cetera. I can see some > difficulties, because a fair bit of the data centers architectures is > probably treated as trade secret. And I am really not sure that the > IETF is the best place to conduct such discussions. we had/have the same oroblem with datacenter* wgs. the folk who really do it think of it as secret sauce. so it becomes the vendors trying to sell solutions to problems they don't understand. hell, i don't even know iij datacentr technology to any depth. randy From hannes.tschofenig@gmx.net Thu Nov 28 01:29:08 2013 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 810A81AD959 for ; Thu, 28 Nov 2013 01:29:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 b0aIoB9ruuCE for ; Thu, 28 Nov 2013 01:29:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC721AD8DA for ; Thu, 28 Nov 2013 01:29:06 -0800 (PST) Received: from Masham-MAC.local ([80.200.183.132]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M54L0-1VQjEc2WYo-00zC0G for ; Thu, 28 Nov 2013 10:29:04 +0100 Message-ID: <52970CDD.2090601@gmx.net> Date: Thu, 28 Nov 2013 10:29:01 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christian Huitema References: <5295FC4F.7060309@dcrocker.net> <027801ceebf8$da0328e0$8e097aa0$@huitema.net> In-Reply-To: <027801ceebf8$da0328e0$8e097aa0$@huitema.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9aXQBVUlpw2kkYx14RFkZvBRhnXj9gD71IMgv/lAShXGV3C95Dt YIsxQccJlch1qZOSe9nUJCquphSqRhgqFKIlV7l/3gMCZlp/FGHaOFTNxUK67UYTy/9B6Dx WGu40yKPgQiFQp/gvh7EoAW4zM+mLa8PgCtflDKgwTh8kO7bRzjFp/2EzxRup1Pu2pvNZ2U iJqSQR4XkKF45PhJpadkg== Cc: 'perpass' , hannes.tschofenig@gmx.net, dcrocker@bbiw.net Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 09:29:08 -0000 Am 28.11.13 06:15, schrieb Christian Huitema: > There have been some recent news articles about various major ISPs > taking steps to encrypt their (internal) traffic. I have not seen those articles (unless you refer to the data centers of Google & co). Do you hae some pointers? Ciao Hannes From stephen.farrell@cs.tcd.ie Thu Nov 28 02:00:15 2013 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 702021AD957 for ; Thu, 28 Nov 2013 02:00:15 -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, RP_MATCHES_RCVD=-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 jO3IUHhKRB8h for ; Thu, 28 Nov 2013 02:00:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 071111A1F58 for ; Thu, 28 Nov 2013 02:00:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 065FABE5C; Thu, 28 Nov 2013 10:00:13 +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 Jl-HZjX0fWuP; Thu, 28 Nov 2013 10:00: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 CAA11BE59; Thu, 28 Nov 2013 10:00:12 +0000 (GMT) Message-ID: <5297142D.6010101@cs.tcd.ie> Date: Thu, 28 Nov 2013 10:00:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Randy Bush , Christian Huitema References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'perpass' , dcrocker@bbiw.net Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 10:00:15 -0000 On 11/28/2013 06:08 AM, Randy Bush wrote: >> Randy is quite right. > > has to happen occasionally :-) >> The attacks reported in the news article were against the private >> optical fibers linking the geographically distributed data centers of >> large companies like Google or Yahoo. A discussion about that should >> start with the folks in charge of securing these data centers at >> Google, Yahoo, Facebook, Microsoft, et cetera. I can see some >> difficulties, because a fair bit of the data centers architectures is >> probably treated as trade secret. And I am really not sure that the >> IETF is the best place to conduct such discussions. > > we had/have the same oroblem with datacenter* wgs. the folk who really > do it think of it as secret sauce. Yep, that's the problem all right. However, we do sometimes get folks who are willing to document stuff like that that they've done, so if there are any out there then they should know that we'd love to see that draft, could get them some help with writing it if that's needed and with moving it through the process-maze. And as Dave said, there is a potential benefit if more organisations secure their internal networks since a lot of them are inter-dependent one way or another via cloudy-foo stuff. Cheers, S. From eburger@cs.georgetown.edu Thu Nov 28 03:36:38 2013 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 805C71AE02A for ; Thu, 28 Nov 2013 03:36:38 -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, RP_MATCHES_RCVD=-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 3GmTtiIrg3xO for ; Thu, 28 Nov 2013 03:36:36 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8FC1ADF5B for ; Thu, 28 Nov 2013 03:36:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 23E614737A for ; Thu, 28 Nov 2013 06:36:35 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfmYNZcSTrf4 for ; Thu, 28 Nov 2013 06:36:31 -0500 (EST) Received: from [192.168.15.104] (ip68-100-74-215.dc.dc.cox.net [68.100.74.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 80C1847366 for ; Thu, 28 Nov 2013 06:36:31 -0500 (EST) From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_8500FEF6-F745-4C31-952A-BF6358DF1DCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Thu, 28 Nov 2013 06:36:29 -0500 References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> To: perpass In-Reply-To: <5297142D.6010101@cs.tcd.ie> X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Thu, 28 Nov 2013 03:38:41 -0800 Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 11:36:38 -0000 --Apple-Mail=_8500FEF6-F745-4C31-952A-BF6358DF1DCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would offer the problem is not securing links (VPN) or backbones = (links), but to remind people of this (seemingly obsolete) IETF = principle called =91end-to-end.=92 In the context of security, it is = that one cannot presume security because you happen to own the network. = Bad things happen within a single, private network for a whole host of = reasons. So, lock down stuff at the endpoints. Put eight pages of boilerplate on the above and I just wrote the entire = ID Dave suggested. On Nov 28, 2013, at 5:00 AM, Stephen Farrell = wrote: >=20 >=20 > On 11/28/2013 06:08 AM, Randy Bush wrote: >>> Randy is quite right. >>=20 >> has to happen occasionally >=20 > :-) >=20 >>> The attacks reported in the news article were against the private >>> optical fibers linking the geographically distributed data centers = of >>> large companies like Google or Yahoo. A discussion about that should >>> start with the folks in charge of securing these data centers at >>> Google, Yahoo, Facebook, Microsoft, et cetera. I can see some >>> difficulties, because a fair bit of the data centers architectures = is >>> probably treated as trade secret. And I am really not sure that the >>> IETF is the best place to conduct such discussions. >>=20 >> we had/have the same oroblem with datacenter* wgs. the folk who = really >> do it think of it as secret sauce. =20 >=20 > Yep, that's the problem all right. However, we do sometimes > get folks who are willing to document stuff like that that > they've done, so if there are any out there then they should > know that we'd love to see that draft, could get them some > help with writing it if that's needed and with moving it > through the process-maze. >=20 > And as Dave said, there is a potential benefit if more > organisations secure their internal networks since a lot of > them are inter-dependent one way or another via cloudy-foo > stuff. >=20 > Cheers, > S. >=20 >=20 >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_8500FEF6-F745-4C31-952A-BF6358DF1DCE 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 iQIcBAEBAgAGBQJSlyq9AAoJEBTjQnN5ojkBQMkP/Ax+9Elj5av/+9hXFEJPEF8s LzM8Lp37J+DZOwRiz7qRhArjaaaP6JyeSkIuBbHaKmLM6yDsOCzLj7qLJ4ync6XG 3t9kVdjI/3uaErsv2gfRkrAeWjFtVgkgr6m5fYrdDvcuANrhp5V+AexAJCAaLTp0 s7g5Xuiy7ldvHPMDk+O3lmO6wky9A0rZqMaZ5X47l09iAqv+1Ep/F1KClN4tFcnL uGjVOEc8YlaZvKqVZfrUs/BuVHnGHZ3qVNupfT4nOxBreojRVxckdFwMqMzUeT+2 WUsYyYI8acXEnjZ9YMIwzB9rEHbaZ1xf3A1bLdzb2REV5hpbWiqO1Pwni3QxRsPc f8d5K7AXshJBSq++o3A5U6EpnK8pI+0kmMyO5NIMz7elUCYdsHWUtpS6XFvwmi8S YBa3XfqYG010Wt8WCivgukO64Mbnz2x/ootDkzLfipoPRC/iVesm1RYlHEsxCHjF EWcHssEGyT+tnVmR1gCa3E7FdTQ3BQbLS8UGThHWr/xxAY+ShqP8Q2e8++QecBDc bLf/hJfezBXsDd8tebKEJS8xk9QnV5U4fVXC9ImzAq0yMlyyUHGN01H9IMcUI1GW RcHm64NGZS3ryn2zck3XGVwsPpKq9Qs8z5DmaJYqMNvd4f1a+lQW55DJl6UwowuQ Jx2oYKhTI3yTfPi9ezOq =XC8/ -----END PGP SIGNATURE----- --Apple-Mail=_8500FEF6-F745-4C31-952A-BF6358DF1DCE-- From nb@bollow.ch Thu Nov 28 03:48:02 2013 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 30CAD1AE08D for ; Thu, 28 Nov 2013 03:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DqfxMxV-W8xH for ; Thu, 28 Nov 2013 03:48:00 -0800 (PST) Received: from beta.bollow.ch (beta.bollow.ch [193.37.152.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0691AE086 for ; Thu, 28 Nov 2013 03:48:00 -0800 (PST) Received: from quill (59-34.62-81.cust.bluewin.ch [81.62.34.59]) by beta.bollow.ch (Postfix) with ESMTPSA id 804B8140219; Thu, 28 Nov 2013 12:55:30 +0100 (CET) Date: Thu, 28 Nov 2013 12:47:18 +0100 From: Norbert Bollow To: Eric Burger Message-ID: <20131128124718.357ee20f@quill> In-Reply-To: References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> Organization: ZielBaum Beratung N. Bollow X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/zk_hPwr0+a/SEufgvMl+iqo"; protocol="application/pgp-signature" Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 11:48:02 -0000 --Sig_/zk_hPwr0+a/SEufgvMl+iqo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Burger wrote: > I would offer the problem is not securing links (VPN) or backbones > (links), but to remind people of this (seemingly obsolete) IETF > principle called =E2=80=98end-to-end.=E2=80=99 In the context of security= , it is that > one cannot presume security because you happen to own the network. > Bad things happen within a single, private network for a whole host > of reasons. So, lock down stuff at the endpoints. Yes, end-to-end encryption is absolutely essential. But protecting "who communicated with whom" data, which can also be highly sensistive, requires further steps in addition to end-to-end encryption. Greetings, Norbert --Sig_/zk_hPwr0+a/SEufgvMl+iqo Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFSly1GGA9C3DSA3ZoRAtr0AJ0U+Vx3zX1pIkW7MkiUvFj5j9WAYQCgy90Y vbU1wswOvwad1Gpy88NOLUg= =VQX4 -----END PGP SIGNATURE----- --Sig_/zk_hPwr0+a/SEufgvMl+iqo-- From eburger@standardstrack.com Thu Nov 28 03:59:54 2013 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 5CE6F1AE061 for ; Thu, 28 Nov 2013 03:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.278 X-Spam-Level: X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 0vUegDwCALKX for ; Thu, 28 Nov 2013 03:59:53 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8401AE016 for ; Thu, 28 Nov 2013 03:59:53 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:58330 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Vm0G3-0005am-16 for perpass@ietf.org; Thu, 28 Nov 2013 03:59:51 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_1C0365F1-DFF5-4F79-8FE3-F03DE72C5283"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Thu, 28 Nov 2013 06:59:44 -0500 References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> <20131128124718.357ee20f@quill> To: perpass In-Reply-To: <20131128124718.357ee20f@quill> X-Mailer: Apple Mail (2.1822) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: [perpass] Source Routing [was Re: "Guide to intranet protection"?] 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, 28 Nov 2013 11:59:54 -0000 --Apple-Mail=_1C0365F1-DFF5-4F79-8FE3-F03DE72C5283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agreed. That was not what Dave was asking for, however. He was looking = for how an ISP can secure their customer network. One could advocate for TOR or SilentCircle style solutions, where all = traffic is forced to a particular node where one obfuscates next hops, = add in dummy packets, make all packets the same size, and transmit a = continuous train of packets. The good news is that would make it orders of magnitude harder for = someone monitoring the network to do traffic analysis. The bad news is it would make it trivial for someone to monitor the = network if they own the ingress node. This is in fact why a number of = repressive regimes are demanding the IETF create such protocols, under = the guise of =93please make sure our packets do not flow to the = US/UK/Iran/{favorite boogeyman of the moment}." On Nov 28, 2013, at 6:47 AM, Norbert Bollow wrote: > Eric Burger wrote: >=20 >> I would offer the problem is not securing links (VPN) or backbones >> (links), but to remind people of this (seemingly obsolete) IETF >> principle called =91end-to-end.=92 In the context of security, it is = that >> one cannot presume security because you happen to own the network. >> Bad things happen within a single, private network for a whole host >> of reasons. So, lock down stuff at the endpoints. >=20 > Yes, end-to-end encryption is absolutely essential. >=20 > But protecting "who communicated with whom" data, which can also be > highly sensistive, requires further steps in addition to end-to-end > encryption. >=20 > Greetings, > Norbert > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_1C0365F1-DFF5-4F79-8FE3-F03DE72C5283 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 iQIcBAEBAgAGBQJSlzAwAAoJEDY/T2tCIPW3fIAP/1ahy9F2LIoW9YJCLLvTHQrU WOiQJsjJT+dhScNMH5F8ckXyhrPCQgF0edqGOkd8paxFvCJqy8epoBr1SPXOIreI FRGSvLnoNBkoRFYXUZlhneqc3+nOCLaDw0vOmY4kDctGQzy+4sBngxW8YvnrOSsO 57WRpwZ2oPOWo+B0D+mgRepf3nAQdVQZZbElPeONFwBKZhEDuynutcm0uOxw3y4f ucu15frxZRi3ngWgrl3ykXmXuXRleDOUq2cbz65BhS9grfe6kMWckFP9dFJyRYBc m0bIEXuxbF1ohVZnl5nszgUbvIYZVk1I0WlW7ozaHAwU6Fig63tlz0Wwikgm8Y8c deItrMLW+xdGCt0t7D6sSyf1zWBMGwKp9qIQJQOnoYyCG72H9jVKr8q+UKwpcOzF HabAkq68ePjI4sPfNFgzyQwdkumw4Pp4p7qRHLMXn5fECkaTlpVoyBrAbS5X3kSb JTV3yhdrDlmG7f9zRZkJij7ma6vlk0rPzdZo9887jfrfQ0vMX2za4vkIYXAf1r/9 P55NumdRL8mFZZPSHli9XVoKV2ItJ5CtZtYOHwqkozcckzIxpjZwRr5iRJ0UTE1A 5uuwh5iEy7KupgkHNhNVZMX839Fl1sG3KMsf42NuoBnaWBJAZuLsY0P9xdT/AAwJ jfzozf0bI+Oy0At+3n3w =XLRR -----END PGP SIGNATURE----- --Apple-Mail=_1C0365F1-DFF5-4F79-8FE3-F03DE72C5283-- From hannes.tschofenig@gmx.net Thu Nov 28 06:19:52 2013 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 A25411AE022 for ; Thu, 28 Nov 2013 06:19:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 vM7HYyFOlOQf for ; Thu, 28 Nov 2013 06:19:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 743FC1ADF9D for ; Thu, 28 Nov 2013 06:19:50 -0800 (PST) Received: from Masham-MAC.local ([80.200.183.132]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M5a9E-1VSIhw30au-00xXHE for ; Thu, 28 Nov 2013 15:19:48 +0100 Message-ID: <52975102.1020202@gmx.net> Date: Thu, 28 Nov 2013 15:19:46 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Eric Burger References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5IBsPjb7vv1B2dKfA2PVtsR7At+5GZCBF0OxwnaBk6scBSPk0bC jfCcqCh3WPS0zQZN01eyiUt6/reCdFEwUb3ul7dKJ4ywhq0DrHf+es+PO3awPciIthjR3Ds 5ElNpozsHlGoUqYpCozCcrtuCq1oTU1jW7rp36sDmJihF33pJmtp5/GG84y00NU449hMtlu g3pnZDTV8VMUmiTuysINA== Cc: perpass , hannes.tschofenig@gmx.net Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 14:19:52 -0000 I think the biggest problem is in the believe that there would be something as "inside" and "outside". Outside is supposed to be the Internet and inside is the secure enterprise network. There is just the perception that stuff inside is secure. Just per definition it is secure. I have seen this many times. Am 28.11.13 12:36, schrieb Eric Burger: > I would offer the problem is not securing links (VPN) or backbones (links), but to remind people of this (seemingly obsolete) IETF principle called ‘end-to-end.’ In the context of security, it is that one cannot presume security because you happen to own the network. Bad things happen within a single, private network for a whole host of reasons. So, lock down stuff at the endpoints. > > Put eight pages of boilerplate on the above and I just wrote the entire ID Dave suggested. > > On Nov 28, 2013, at 5:00 AM, Stephen Farrell wrote: > >> >> >> On 11/28/2013 06:08 AM, Randy Bush wrote: >>>> Randy is quite right. >>> >>> has to happen occasionally >> >> :-) >> >>>> The attacks reported in the news article were against the private >>>> optical fibers linking the geographically distributed data centers of >>>> large companies like Google or Yahoo. A discussion about that should >>>> start with the folks in charge of securing these data centers at >>>> Google, Yahoo, Facebook, Microsoft, et cetera. I can see some >>>> difficulties, because a fair bit of the data centers architectures is >>>> probably treated as trade secret. And I am really not sure that the >>>> IETF is the best place to conduct such discussions. >>> >>> we had/have the same oroblem with datacenter* wgs. the folk who really >>> do it think of it as secret sauce. >> >> Yep, that's the problem all right. However, we do sometimes >> get folks who are willing to document stuff like that that >> they've done, so if there are any out there then they should >> know that we'd love to see that draft, could get them some >> help with writing it if that's needed and with moving it >> through the process-maze. >> >> And as Dave said, there is a potential benefit if more >> organisations secure their internal networks since a lot of >> them are inter-dependent one way or another via cloudy-foo >> stuff. >> >> Cheers, >> S. >> >> >> >> >> _______________________________________________ >> 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 > From dcrocker@bbiw.net Thu Nov 28 06:29:47 2013 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 950AD1AE144 for ; Thu, 28 Nov 2013 06:29:47 -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 W-4MLAHyvn4A for ; Thu, 28 Nov 2013 06:29:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E01AE141 for ; Thu, 28 Nov 2013 06:29:46 -0800 (PST) Received: from [10.211.51.212] (rbiguest.jcresorts.com [206.170.126.120] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rASETcsX017412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Nov 2013 06:29:42 -0800 Message-ID: <52975322.8010402@bbiw.net> Date: Thu, 28 Nov 2013 06:28:50 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Norbert Bollow , Eric Burger References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> <20131128124718.357ee20f@quill> In-Reply-To: <20131128124718.357ee20f@quill> 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]); Thu, 28 Nov 2013 06:29:42 -0800 (PST) X-Mailman-Approved-At: Thu, 28 Nov 2013 06:33:20 -0800 Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 14:29:47 -0000 On 11/28/2013 3:47 AM, Norbert Bollow wrote: > Yes, end-to-end encryption is absolutely essential. > > But protecting "who communicated with whom" data, which can also be > highly sensistive, requires further steps in addition to end-to-end > encryption. I've been skeptical about the avid focus on using TLS, because it isn't end-to-end. Object-based mechanisms, like PGP or TLS, are what's needed for that. Then it was pointed out exactly the above, namely that these mechanisms protect little or none of the meta-data, whereas TLS does protect it (except within transit nodes, between TLS sessions, of course) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Thu Nov 28 06:41:29 2013 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 56FBC1AE022 for ; Thu, 28 Nov 2013 06:41:29 -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 4S1jeuz3Z7rI for ; Thu, 28 Nov 2013 06:41:27 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 22D771ADFB0 for ; Thu, 28 Nov 2013 06:41:26 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id y1so4278280lam.11 for ; Thu, 28 Nov 2013 06:41:25 -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=uznid94MwaxAACxIVTKBVRbj7+D6GLztwF41qYbcBRA=; b=P0BGMGatosBHi+2UP19dlFHUKOv/Uwjl5ra9ivsepAhXpbLZA5mD/zOCUd9ZEr4AvO oFRT19Qu0uUX1JalHjM3SnKgEBVyFuiSZvQ2w7Lm3Ln8PRxk8nM4IZ1RkucuZg3fFMSd gurQgd1T5+gS5keZyXLqYA3kKSL5M9Mm7pGEP9wcwtEy3BsmXg3Y8lQ5TdFyGKgsPd2M QEAIloVp/1Q+bj6F8XOtRRtVYu8wDcbO6WudZ7/RWxAwV4llL879Fu4epgQAaH8H/CBL 3zRUK0fnOKtHkKiO5Vhg9//5SZy8A/bfmbMcZzKkP/C1Ke2JNan2J7DH3ItZgyxNFWY2 17qg== MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr15460127lbb.23.1385649685333; Thu, 28 Nov 2013 06:41:25 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 28 Nov 2013 06:41:25 -0800 (PST) In-Reply-To: References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> Date: Thu, 28 Nov 2013 09:41:25 -0500 Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c264a4470f5404ec3db5e8 Cc: perpass , Dave Crocker , Stephen Farrell Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 14:41:29 -0000 --001a11c264a4470f5404ec3db5e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 27, 2013 at 10:43 PM, Randy Bush wrote: > >> I'm assuming that providing meaningful protection takes a statement > >> beyond "encrypt all your links". Perhaps it doesn't, but I thought > >> I'd ask... > > I'd say that'd be a fine thing if we could get someone who'd done that > > job to help write it. > > may not work out as well as we might wish, as folk who have done it may > not want to disclose details. but i am sure there are folk who have not > done it who will be happy to tell others how they should run their > networks :) > That is less of an issue than you might imagine. Absent an external threat, companies see each other as competitors. An external attack changes minds very quickly. I don't think anyone is going to be putting a network diagram of their datacenter on the table but that isn't really the point. It is the processes and controls that matter, not the instances. Microsoft and Google cooperate here to write a specification but they don't usually share source code. And even if they do as in Chromium, it does not make a great deal of difference as competitors don't start from the same legacy. The number of people who move companies in the valley is very large. The chance that any of the details are really very secret is small. NDAs stop people blabbing about it to likely attackers, but thats about all. The business value in sharing the information is greater than the business value in keeping it secret. -- Website: http://hallambaker.com/ --001a11c264a4470f5404ec3db5e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 27, 2013 at 10:43 PM, Randy Bush <= randy@psg.com> wrote:
>> I'm assuming = that providing meaningful protection takes a statement
>> beyond "encrypt all your links". =A0Perhaps it doesn'= ;t, but I thought
>> I'd ask...
> I'd say that'd be a fine thing if we could get someone who'= ;d done that
> job to help write it.

may not work out as well as we might wish, as folk who have done it m= ay
not want to disclose details. =A0but i am sure there are folk who have not<= br> done it who will be happy to tell others how they should run their
networks :)

That is less of an issue th= an you might imagine.

Absent an external threat, c= ompanies see each other as competitors. An external attack changes minds ve= ry quickly.

I don't think anyone is going to be putting a netwo= rk diagram of their datacenter on the table but that isn't really the p= oint. It is the processes and controls that matter, not the instances. Micr= osoft and Google cooperate here to write a specification but they don't= usually share source code. And even if they do as in Chromium, it does not= make a great deal of difference as competitors don't start from the sa= me legacy.

The number of people who move companies in the valley i= s very large. The chance that any of the details are really very secret is = small. NDAs stop people blabbing about it to likely attackers, but thats ab= out all.

The business value in sharing the information is greate= r than the business value in keeping it secret.

<= div>
--
Website: http://ha= llambaker.com/
--001a11c264a4470f5404ec3db5e8-- From dhc@dcrocker.net Thu Nov 28 06:48:30 2013 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 142AC1AE145 for ; Thu, 28 Nov 2013 06:48:30 -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 AfWaQRv_NeyH for ; Thu, 28 Nov 2013 06:48:29 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7A1AE13E for ; Thu, 28 Nov 2013 06:48:28 -0800 (PST) Received: from [10.211.51.212] (rbiguest.jcresorts.com [206.170.126.120] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rASEmLDq018433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Nov 2013 06:48:25 -0800 Message-ID: <52975784.20408@dcrocker.net> Date: Thu, 28 Nov 2013 06:47:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Norbert Bollow , Eric Burger References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <5297142D.6010101@cs.tcd.ie> <20131128124718.357ee20f@quill> In-Reply-To: <20131128124718.357ee20f@quill> 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, 28 Nov 2013 06:48:25 -0800 (PST) Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 14:48:30 -0000 On 11/28/2013 3:47 AM, Norbert Bollow wrote: > Yes, end-to-end encryption is absolutely essential. > > But protecting "who communicated with whom" data, which can also be > highly sensistive, requires further steps in addition to end-to-end > encryption. I've been skeptical about the avid focus on using TLS, because it isn't end-to-end. Object-based mechanisms, like PGP or TLS, are what's needed for that. Then it was pointed out exactly the above, namely that these mechanisms protect little or none of the meta-data, whereas TLS does protect it (except within transit nodes, between TLS sessions, of course) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Thu Nov 28 06:50:03 2013 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 0AEC11AE158 for ; Thu, 28 Nov 2013 06:50:03 -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 RQrMW2ZIuf20 for ; Thu, 28 Nov 2013 06:50:01 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id A34EB1AE086 for ; Thu, 28 Nov 2013 06:50:00 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id w7so6115468lbi.8 for ; Thu, 28 Nov 2013 06:49:59 -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=VOzS+TskL31fsvF9S3eZqe7BnDLL5/9p6lVvN9ZLCUU=; b=ph3MQi9WBPr+77DQyDkw6elrnSCAmaNbE95wTdqtnzUCIo233OCqCEAu8gKqJOLJ02 wZIIXlI9XHZtaOIpRDRSpnxLnRcvl1eXObtWjiiXxT8BYYRgyBiyFllvwN+j8Za4Jt1j dX9Mh+dv/lMSgYYoaSXCa1Bl6c6psWQ8q/j5hALRigIjPYLvpCnVyZol0QNZ0lpBA8hb ZqwxlVUMqKwcdk7xlKOJTvAyUbo5/XZqtP70DSkq9KMsdGy+0cNNafuftmUQ3NUcejRv RhwDjdYY/M+cQjZ0cqQ9P6eWesLmQ0yeFM1U5aNDbP5BKu3FqQNcCfmg53dxRzF3hPAV cDwg== MIME-Version: 1.0 X-Received: by 10.112.40.104 with SMTP id w8mr835071lbk.45.1385650199121; Thu, 28 Nov 2013 06:49:59 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 28 Nov 2013 06:49:59 -0800 (PST) In-Reply-To: References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> Date: Thu, 28 Nov 2013 09:49:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: multipart/alternative; boundary=001a113371a0e6d54f04ec3dd324 Cc: perpass , Christian Huitema , Dave Crocker Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 14:50:03 -0000 --001a113371a0e6d54f04ec3dd324 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 28, 2013 at 1:08 AM, Randy Bush wrote: > > Randy is quite right. > > has to happen occasionally > > > The attacks reported in the news article were against the private > > optical fibers linking the geographically distributed data centers of > > large companies like Google or Yahoo. A discussion about that should > > start with the folks in charge of securing these data centers at > > Google, Yahoo, Facebook, Microsoft, et cetera. I can see some > > difficulties, because a fair bit of the data centers architectures is > > probably treated as trade secret. And I am really not sure that the > > IETF is the best place to conduct such discussions. > > we had/have the same oroblem with datacenter* wgs. the folk who really > do it think of it as secret sauce. so it becomes the vendors trying to > sell solutions to problems they don't understand. hell, i don't even > know iij datacentr technology to any depth. > Just to be clear, when I said they are more willing to share than you said earlier, I was referring to a closed door sharing in some members only forum. That model definitely works. The IETF might play a role in brokering the setting up of such an organization but any sharing is not going to take place in public and not in the IETF and it is going to take place at a certain degree of abstraction. -- Website: http://hallambaker.com/ --001a113371a0e6d54f04ec3dd324 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 28, 2013 at 1:08 AM, Randy Bush <randy@psg.com> wrote:
> Randy is quite right.

has to happen occasionally

> The attacks reported in the news article were against the private
> optical fibers linking the geographically distributed data centers of<= br> > large companies like Google or Yahoo. A discussion about that should > start with the folks in charge of securing these data centers at
> Google, Yahoo, Facebook, Microsoft, et cetera. I can see some
> difficulties, because a fair bit of the data centers architectures is<= br> > probably treated as trade secret. And I am really not sure that the > IETF is the best place to conduct such discussions.

we had/have the same oroblem with datacenter* wgs. =A0the folk who re= ally
do it think of it as secret sauce. =A0so it becomes the vendors trying to sell solutions to problems they don't understand. =A0hell, i don't = even
know iij datacentr technology to any depth.

=
Just to be clear, when I said they are more willing to share than you = said earlier, I was referring to a closed door sharing in some members only= forum. That model definitely works.

The IETF might play a role in brokering the setting up = of such an organization but any sharing is not going to take place in publi= c and not in the IETF and it is going to take place at a certain degree of = abstraction.

=A0

--
Website: http://hallambaker.com/
--001a113371a0e6d54f04ec3dd324-- From atlunde@panix.com Thu Nov 28 07:25:37 2013 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 917F31AE120 for ; Thu, 28 Nov 2013 07:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FBC33KLnNhvo for ; Thu, 28 Nov 2013 07:25:35 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id A54BB1AD7BF for ; Thu, 28 Nov 2013 07:25:35 -0800 (PST) Received: from [192.168.15.3] (unknown [50.9.9.201]) by mailbackend.panix.com (Postfix) with ESMTP id 4B0F135D9C for ; Thu, 28 Nov 2013 10:25:34 -0500 (EST) Message-ID: <5297607B.3070103@panix.com> Date: Thu, 28 Nov 2013 09:25:47 -0600 From: Albert Lunde User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] "Guide to intranet protection"? 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, 28 Nov 2013 15:25:37 -0000 Loosely on topic, there is this recent blog entry from Twitter on what they did to implement Forward Security: https://blog.twitter.com/2013/forward-secrecy-at-twitter-0 The main point seems to be that they dynamically rotate through SSL session keys and try to avoid storing them anywhere long-term. They in turn cite: Imperial Violet "How to botch TLS forward secrecy" https://www.imperialviolet.org/2013/06/27/botchingpfs.html From TurnerS@ieca.com Fri Nov 29 20:09:00 2013 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 7882F1AE0B7 for ; Fri, 29 Nov 2013 20:09:00 -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 Yem6kye4ABmN for ; Fri, 29 Nov 2013 20:08:58 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.144.14]) by ietfa.amsl.com (Postfix) with ESMTP id 628141AE08F for ; Fri, 29 Nov 2013 20:08:58 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 5A7DAEC2FAFEF; Fri, 29 Nov 2013 22:07:39 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 304A7EC2FAFCF for ; Fri, 29 Nov 2013 22:07:39 -0600 (CST) Received: from [173.73.126.4] (port=53493 helo=[192.168.1.100]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VmbrT-00042L-35; Fri, 29 Nov 2013 22:08:55 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_E4A8C4D8-C418-4773-B957-FE329395DA91"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sean Turner In-Reply-To: <528CF08D.7070400@cs.tcd.ie> Date: Fri, 29 Nov 2013 23:08:52 -0500 Message-Id: <270675DF-77E7-4B9C-96B3-DC21DDB9B2A4@ieca.com> References: <32DE3A49-ACEE-48FC-93B2-E45CE7AE14AA@vigilsec.com> <528CF08D.7070400@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1822) 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.126.4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.100]) [173.73.126.4]:53493 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: Richard Barnes , perpass , Russ Housley Subject: Re: [perpass] RSA-OAEP 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, 30 Nov 2013 04:09:00 -0000 --Apple-Mail=_E4A8C4D8-C418-4773-B957-FE329395DA91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 for what it=92s worth: +1 to saag I=92d like to see both OAEP and PSS be more widely adopted. spt On Nov 20, 2013, at 12:25, Stephen Farrell = wrote: >=20 > I agree that OAEP is better and would be a better MTI. >=20 > But that's been tried, and each time, current deployment > considerations trumped it and specs choose pkcs#1v1.5. >=20 > I may well be wrong but I suspect someone putting in a > bit of concerted work on coding will be needed before > OAEP will get accepted, esp since the attacks are all > million-message attacks so far. Or am I out of date > in terms of which libraries now have OAEP in 'em? >=20 > Lastly, while that is a worthwhile and good security > thing to do, I think the linkage to pervasive > monitoring isn't that strong, so maybe this'd be a > better topic for the saag list? >=20 > S >=20 > On 11/20/2013 05:18 PM, Richard Barnes wrote: >> That makes sense. Would you say the same in the signature domain, = i.e., >> PKCS#1 v1.5 -> PSS? >>=20 >>=20 >> On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley = wrote: >>=20 >>> I do not know of any place where RSA-OAEP has been called out as the >>> mandatory to implement algorithm, but there are many places where = PKCS#1 >>> v1.5 still enjoys this status. I suggest we make RSA-OAEP the = mandatory to >>> implement algorithm in our specifications. >>>=20 >>> Russ >>>=20 >>>=20 >>> On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: >>>=20 >>> What are you proposing be done, besides supporting OAEP in new specs = or >>> back-porting it to old ones? In order to make people use OAEP, we = would >>> need to call in the protocol police. >>>=20 >>>=20 >>> On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley = wrote: >>>=20 >>>> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC = 2313) >>>> is vulnerable to adaptive chosen ciphertext attacks when applied = for >>>> encryption purposes. Exploitation reveals the result of a = particular RSA >>>> decryption, requires access to an oracle which will respond to a = hundreds >>>> of thousands of ciphertexts), which are constructed adaptively in = response >>>> to previously-received replies providing information on the = successes or >>>> failures of attempted decryption operations. As a result, the = attack >>>> appears significantly less feasible to perpetrate in = store-and-forward >>>> environments than for interactive ones. >>>>=20 >>>> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP = to >>>> address this situation, but we have seen very little movement = toward >>>> RSA-OAEP. While we are reviewing algorithm choices in light of the >>>> pervasive surveillance situation, I think we should take the time = to >>>> address known vulnerabilities like this one. If we don't, then we = are >>>> leaving an partially open door for a well funded attacker. >>>>=20 >>>> Russ >>>> _______________________________________________ >>>> perpass mailing list >>>> perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass >>>>=20 >>>=20 >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_E4A8C4D8-C418-4773-B957-FE329395DA91 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 hvcNAQkFMQ8XDTEzMTEzMDA0MDg1M1owIwYJKoZIhvcNAQkEMRYEFJgAdYazxqBW+9iGh8ozffEC 8CxrMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBLnp47uKc33yB11Yw/0szTde9i o1eLg12CnP10n1ioRoWmdbKY0qsAfuVrSmjmuN0uAHajYyBXYVEdEnRzZqIy4oJnBd38UFcFxoIQ Bx4DMJRRUFW83puVAHms57VId4t7OtY5IBbjvU7X1bu48ilwVen0S9WnDaXHjsUnf58pgUDPJWTs BLnAQV4k6bTw1p907szmUWuO/2qL74sqjIUYbH8+X7cePcoFAMee84LYn+fcz9FAWGdn/hLmkOIy QHqEQ8Z7ugn2JszHBU+MM7mIUVSjogtERHyc/vhcpXRExuQwuBGba/LEaRNsWNRv9eV7YFpepDfG sBk6lQ+LX2VoAAAAAAAA --Apple-Mail=_E4A8C4D8-C418-4773-B957-FE329395DA91-- From eburger@standardstrack.com Sat Nov 30 07:56:46 2013 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 C399A1AE448 for ; Sat, 30 Nov 2013 07:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 gFWXG3K9q8zv for ; Sat, 30 Nov 2013 07:56:45 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id B729B1AE447 for ; Sat, 30 Nov 2013 07:56:45 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:52875 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VmmuQ-0002WU-MB for perpass@ietf.org; Sat, 30 Nov 2013 07:56:43 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_7BDEEDB3-9013-4D9F-B1A4-3CF9A276CD38"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <9E17C7BF-FBFD-4C6C-81E9-34704FB24FC4@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Sat, 30 Nov 2013 10:32:25 -0500 References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> To: perpass In-Reply-To: X-Mailer: Apple Mail (2.1822) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [perpass] "Guide to intranet protection"? 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, 30 Nov 2013 15:56:47 -0000 --Apple-Mail=_7BDEEDB3-9013-4D9F-B1A4-3CF9A276CD38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In the shameless self-promotion department, this IS my day job. See = http://s2erc.georgetown.edu/projects/cyberISE/ for the theoretical work = and http://gcsc.georgetown.edu/ if one needs an operational venue. On Nov 28, 2013, at 9:49 AM, Phillip Hallam-Baker = wrote: > On Thu, Nov 28, 2013 at 1:08 AM, Randy Bush wrote: > > Randy is quite right. >=20 > has to happen occasionally >=20 > > The attacks reported in the news article were against the private > > optical fibers linking the geographically distributed data centers = of > > large companies like Google or Yahoo. A discussion about that should > > start with the folks in charge of securing these data centers at > > Google, Yahoo, Facebook, Microsoft, et cetera. I can see some > > difficulties, because a fair bit of the data centers architectures = is > > probably treated as trade secret. And I am really not sure that the > > IETF is the best place to conduct such discussions. >=20 > we had/have the same oroblem with datacenter* wgs. the folk who = really > do it think of it as secret sauce. so it becomes the vendors trying = to > sell solutions to problems they don't understand. hell, i don't even > know iij datacentr technology to any depth. >=20 > Just to be clear, when I said they are more willing to share than you = said earlier, I was referring to a closed door sharing in some members = only forum. That model definitely works. >=20 > The IETF might play a role in brokering the setting up of such an = organization but any sharing is not going to take place in public and = not in the IETF and it is going to take place at a certain degree of = abstraction. >=20 > =20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_7BDEEDB3-9013-4D9F-B1A4-3CF9A276CD38 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 iQIcBAEBAgAGBQJSmgUJAAoJEDY/T2tCIPW3tm8P/02wieV1lJeCP3dUFiQwWs4f 0E+5jfaH3SCkooB7u+4KaKJH/V9RaSc36U4PSSDxjiKbfPjaVsGXcK47MVIFAGh3 zQ1yx/mv25MjIlSA812hQuboPZYnNWZ1+c1J9yow7XYTTVcTcOw2bJQlEe2EhGBx K24XlLOdSIipEzBH6ZSG5WuK8bqAPcLkNX5bsgXEsJYfIMDflz8rQ/CI9w027IEj f7EDip5NN0vfLveKG4iMDfS3W/beU+5DmZKRROqe+GvGkHH64imn1i7NCqXhVW0V 8+7I88paa1FATZn+mGwXESRkq2krR1YIfCgXBteIVgoZriuu5lxwOSfYdqgERvgz W4UfpDpmeZKJR0bNhyjgRsUaoaqZOqagY3RLDYJ8e05l6ggZtu1UYKUN6ohyOL8f JkxzG65lsstQMJqfLjeXSp0aojoqaglafDNbVY/wgowTE0gtfVsFk/0ykcVGBsnA YUZW2DUHQjN+fRFLWkJX7/wOLvdMkZnMDU4EFf46NuGCl8pk6OiS/MRFeYpGMPmD F2vvbETUlQt/vem7PNPKmFPEAL/ENT69vCn4CDnF8MBOrT0T3zo18sOU2usaRI6I KfAvuV0ydlCN5D4XCWOKclKWKGRsik6xZomvoLumTNHq/XmarRZUEV/nOimB0x9I UGNBKXe8H3Egw04S0Ia5 =OmHu -----END PGP SIGNATURE----- --Apple-Mail=_7BDEEDB3-9013-4D9F-B1A4-3CF9A276CD38--