From nobody Sat Apr 11 10:24:12 2015 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 8D1631B2C00 for ; Sat, 11 Apr 2015 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 wsv4I2D1dtHe for ; Sat, 11 Apr 2015 10:24:10 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BB31B2BB7 for ; Sat, 11 Apr 2015 10:24:09 -0700 (PDT) Received: by labbd9 with SMTP id bd9so32357374lab.2 for ; Sat, 11 Apr 2015 10:24:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ok6QzbAlHqXIRVd/RQgDoVM93x9INhZ0WEazh+TEpBA=; b=mU5aFVEW8KmGQhjrrmylSMO3g2c91zpRI8/HjLVan7BHKVcj4ND+z+i2/3NTpwdu5I e/65sxtWDuVDq+ipDN3uXFfE2rS5UCid2zM9JIjGuBjT5DgB/HEelFMpQ7IkL3gA5axo Df3Vlcixzg2zTqr7yt2iFItgzRh9NXZO+uUiOY9ZjCSL6kcMIHy8VjLTkZYCGXJU5ICT 1GRlrHQUceA04bBlOBJX0WPW82/uxiVtKfTi4BNtfeB2PVm/z8xxBPZs/4CMWDnPFIxy gmOSTptwJyS0sjJG1oh1VMmjbNT3ATf+QcLojQK3pXQFcniE2gPwPRNrTj0rrrSIoS/E Jcyg== X-Gm-Message-State: ALoCoQkVD+vwsnbWMMknjYjdMJdOY7nLcNvrtSon5EBNDPfWf8dhnarT09APVuQ/8GYYN/P0Y6zp X-Received: by 10.112.236.40 with SMTP id ur8mr6205440lbc.18.1428773048023; Sat, 11 Apr 2015 10:24:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.18.36 with HTTP; Sat, 11 Apr 2015 10:23:47 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <55035662.1070307@cs.tcd.ie> <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> <5506E725.2050003@bbn.com> From: Tim Bray Date: Sat, 11 Apr 2015 10:23:47 -0700 Message-ID: To: Robin Wilton Content-Type: multipart/alternative; boundary=001a11c3c310fe12ef051376254f Archived-At: Cc: perpass , Stephen Kent Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 17:24:11 -0000 --001a11c3c310fe12ef051376254f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I finally got around to submitting the -01 draft, considerably re-organized, per feedback here, to make it clear that the discussion is independent of any particular technology, and to include a tl;dr er cough excuse me =E2=80=9CSummary=E2=80=9D section. Real HTML is at https://www.tbray.org/tmp/draft-bray-privacy-choices-01.htm= l =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-bray-privacy-choices-01.txt has been successfully submitted by Tim Bray and posted to the IETF repository. Name: draft-bray-privacy-choices Revision: 01 Title: Privacy Choices for Internet Data Services Document date: 2015-04-11 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-bray-privacy-choices-01.txt Status: https://datatracker.ietf.org/doc/draft-bray-privacy-choices= / Htmlized: http://tools.ietf.org/html/draft-bray-privacy-choices-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bray-privacy-choices-01 Abstract: This document argues in favor of Internet service providers deploying technologies which offer increased privacy to users of their services. The discussion is independent of any particular privacy technology. The approach is to consider common objections to the the deployment of such technologies, and show that these objections are not well-founded. On Mon, Mar 16, 2015 at 7:45 AM, Robin Wilton wrote: > Hi Steve - and thanks for the correction. > > I agree with your additional use-cases/threat scenarios, naturally=E2=80= =A6 I was > just trying to keep it to one simple illustration ;^) > > R > > On 16 Mar 2015, at 14:22, Stephen Kent wrote: > > > Robin, > >> ... > >> > >> Primrose goes to InsureMe.com, where she will be asked for a lot of > personal data. InsureMe.com invites her to register and create a new > account, with an ID and password; all this is done over https, so > InsureMe.com is confident it has taken suitable steps to protect the data > from being visible to third parties. > > Third parties on the wire. Experience shows that Primrose's data is mos= t > likely to be > > disclosed to third parties once it is on the InsureMe.com web site. You= r > example > > goes on to cite a privacy violation in the form of Gotcher.com. But, a > successful attack > > against InsureMe.com also would violate the confidentiality of > Primrose's data. > > > > Bottom line: I agree with your observation that privacy is not the same > as > > confidentiality, and we often overly simplify these discussions. > > > > 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 > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3c310fe12ef051376254f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I f= inally got around to submitting the -01 draft, considerably re-organized, p= er feedback here, to make it clear that the discussion is independent of an= y particular technology, and to include a tl;dr er cough excuse me =E2=80= =9CSummary=E2=80=9D section.

Real HTML is at=C2=A0https://www.tbray.org/tmp/draft-bray-privacy-choices= -01.html
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
A new version of I-D, draft-b= ray-privacy-choices-01.= txt
has been successfully submitted by Tim Bray and post= ed to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0draft-bray-privacy-choices
Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Privacy Choices for Internet Data Services
Document dat= e:=C2=A0=C2=A02015-04-11
Grou= p:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://www.ietf.org/internet-drafts= /draft-bray-privacy-choices-01.txt
Status:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bray-privacy-choices/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draft-bray-privacy-choi= ces-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf= .org/rfcdiff?url2=3Ddraft-bray-privacy-choices-01

Abstract:
=C2=A0 =C2= =A0This document argues in favor of Internet service providers deploying
=C2=A0 =C2=A0technologies which offer increased privacy to= users of their
=C2=A0 =C2=A0services.=C2=A0 The discuss= ion is independent of any particular privacy
=C2=A0 =C2= =A0technology.=C2=A0 The approach is to consider common objections to the t= he
=C2=A0 =C2=A0deployment of such technologies, and sho= w that these objections are
=C2=A0 =C2=A0not well-founde= d.

On Mon, Mar 16, 2015 at 7:45 AM, Robin Wilton <= ;wilton@isoc.org&g= t; wrote:
Hi Steve - and thanks fo= r the correction.

I agree with your additional use-cases/threat scenarios, naturally=E2=80=A6= I was just trying to keep it to one simple illustration ;^)

R

On 16 Mar 2015, at 14:22, Stephen Kent <= kent@bbn.com> wrote:

> Robin,
>> ...
>>
>> Primrose goes to InsureMe.com, where she will be asked for a lot o= f personal data. InsureMe.com invites her to register and create a new acco= unt, with an ID and password; all this is done over https, so InsureMe.com = is confident it has taken suitable steps to protect the data from being vis= ible to third parties.
> Third parties on the wire. Experience shows that Primrose's data i= s most likely to be
> disclosed to third parties once it is on the InsureMe.com web site. Yo= ur example
> goes on to cite a privacy violation in the form of Gotcher.com. But, a= successful attack
> against InsureMe.com also would violate the confidentiality of Primros= e's data.
>
> Bottom line: I agree with your observation that privacy is not the sam= e as
> confidentiality, and we often overly simplify these discussions.
>
> 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




--
- Tim Bray (If you=E2=80=99d l= ike to send me a private message, see https://keybase.io/timbray)
--001a11c3c310fe12ef051376254f-- From nobody Tue Apr 14 06:19:53 2015 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 206DC1A9107 for ; Tue, 14 Apr 2015 06:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPku14ZrO3VN for ; Tue, 14 Apr 2015 06:19:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9384E1A8BB1 for ; Tue, 14 Apr 2015 06:19:48 -0700 (PDT) Received: from CO2PR0601MB0982.namprd06.prod.outlook.com (25.160.7.27) by CO2PR0601MB0934.namprd06.prod.outlook.com (25.160.10.148) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 13:19:30 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0982.namprd06.prod.outlook.com (25.160.7.27) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 13:19:29 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 13:19:29 +0000 From: Robin Wilton To: Tim Bray Thread-Topic: [perpass] draft-bray-privacy-choices-00.html Thread-Index: AQHQXc/AhfdvI7OZZUKCc7g7lWuc4Z0a7YsAgAEOXrqAAzG7gIAAB08AgCkH9oCABHOtAA== Date: Tue, 14 Apr 2015 13:19:28 +0000 Message-ID: References: <55035662.1070307@cs.tcd.ie> <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> <5506E725.2050003@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: textuality.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0982; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0934; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(377424004)(252514010)(66654002)(51914003)(24454002)(377454003)(19580405001)(19580395003)(77156002)(46102003)(2656002)(87936001)(82746002)(2950100001)(93886004)(106116001)(40100003)(2900100001)(19617315012)(62966003)(551544002)(92566002)(102836002)(15975445007)(110136001)(122556002)(230783001)(16236675004)(83716003)(99936001)(33656002)(54356999)(76176999)(50986999)(16601075003)(86362001)(99286002)(36756003)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0982; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR0601MB0982; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0982; x-forefront-prvs: 054642504A Content-Type: multipart/signed; boundary="Apple-Mail=_24969314-F968-4E37-9E91-30747B98A9CC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 13:19:28.7973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0982 X-OriginatorOrg: isoc.org Archived-At: Cc: perpass , Stephen Kent Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:19:52 -0000 --Apple-Mail=_24969314-F968-4E37-9E91-30747B98A9CC Content-Type: multipart/alternative; boundary="Apple-Mail=_9C5808E3-891C-4972-B8E6-75F1374DF607" --Apple-Mail=_9C5808E3-891C-4972-B8E6-75F1374DF607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks, Tim - I think this is a substantial improvement, and still, of course, a = worthwhile line of investigation. There are two areas where I think the situation is more nuanced than the = text currently suggests, though I appreciate your wish to keep things as = simple and succinct as possible. Here are a couple of comments on those = two areas: 5.1 Free public data: I agree with your basic thesis, which is that the publisher of = information can=92t reliably tell whether accessing that information = will have negative consequences for the individual concerned. The negative consequences are likely to arise from culturally- or = nationally-specific factors, which may not apply (or even occur) to the = publisher, whereas access to the data in question is overwhelmingly = likely to transcend national and cultural boundaries. (Of course, things = that qualify as =93free public data=94 in one national or cultural = context may be no such thing in another). Therefore, you conclude, publishers=92 default should be to publish in a = way that respects the privacy of their readership. The implication is = that it should be possible to access free public data anonymously or = pseudonymously. I agree, but you will also encounter people who strongly believe = otherwise. I blogged about some of the perverse consequences of that = position, after the IGF in Baku. Bottom line: your privacy-respecting stance here will come under attack = for reasons other than the ones your thesis currently implies. I happen = to think most of those attacks are ill-founded, but they will surface = and need to be dealt with. 5.2 Privacy at user option Here, your basic thesis is that privacy decisions are complex enough to = make it impractical for users to have to "opt in=94 if they want = privacy; therefore maximum privacy protection should be the default. = There=92s an implication that users should have to explicitly opt out of = privacy protections as and where they see fit, but I=92m not sure = whether you even intend them to have that choice=85 As I will say below, = I=92m not sure whether you are advocating removal of the need to choose, = or the ability to choose =97 and I think those are quite different. I think you will encounter two forms of push-back to this position.=20 First, we have seen (in the arguments over a =93Do Not Track=94 flag in = browsers) how some vendors/service providers will maintain that a = =93privacy by default=94 setting does not truly reflect the wishes of = the user (and some would go further and claim that it is not in their = best interests, either). There is the potential for paternalism on both = sides of this argument, so one has to be careful how the question is = framed: is =93opted out by default, with the user choosing to opt in=94 = any better than =93opted in by default, with the user choosing to opt = out=94? If maximum privacy protection is to be the default, what=92s the best = way to allow users to share consensually when they intend to do so? Second, it=92s probably true that the decisions to opt in or opt out are = indeed complex, contextual, variable over time, etc. etc=85 But removing = the need (or ability) to decide is not necessarily the answer. (Tired = analogy: my current car=92s engine is far more complex than the one my = old Mini had. It makes millions of decisions on my behalf, every time I = use it. But the interface presented to me is still the same arrangement = of pedals, gear lever and dials=85 and the engine only produces the = effects I intend, even if the underlying process is beyond my = understanding). Bottom line: I think there is scope for the complexity of privacy = decisions (whether opt-out or opt-in) to be partly addressed by = improvements in the technology that acts on the user=92s behalf - = putting the user=92s simply-stated preferences and choices into = practice, without requiring the user to renew or confirm those every = time the question arises. An intelligent user agent, over which the user = exercises complete control. (And, as I say, I think this would only form = part of the over-all picture). Well, I can dream, can=92t I? HTH, Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 11 Apr 2015, at 18:23, Tim Bray wrote: > I finally got around to submitting the -01 draft, considerably = re-organized, per feedback here, to make it clear that the discussion is = independent of any particular technology, and to include a tl;dr er = cough excuse me =93Summary=94 section. >=20 > Real HTML is at = https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A new version of I-D, draft-bray-privacy-choices-01.txt > has been successfully submitted by Tim Bray and posted to the > IETF repository. >=20 > Name: draft-bray-privacy-choices > Revision: 01 > Title: Privacy Choices for Internet Data Services > Document date: 2015-04-11 > Group: Individual Submission > Pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-bray-privacy-choices-01.txt > Status: = https://datatracker.ietf.org/doc/draft-bray-privacy-choices/ > Htmlized: = http://tools.ietf.org/html/draft-bray-privacy-choices-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bray-privacy-choices-01 >=20 > Abstract: > This document argues in favor of Internet service providers = deploying > technologies which offer increased privacy to users of their > services. The discussion is independent of any particular privacy > technology. The approach is to consider common objections to the = the > deployment of such technologies, and show that these objections are > not well-founded. >=20 > On Mon, Mar 16, 2015 at 7:45 AM, Robin Wilton wrote: > Hi Steve - and thanks for the correction. >=20 > I agree with your additional use-cases/threat scenarios, naturally=85 = I was just trying to keep it to one simple illustration ;^) >=20 > R >=20 > On 16 Mar 2015, at 14:22, Stephen Kent wrote: >=20 > > Robin, > >> ... > >> > >> Primrose goes to InsureMe.com, where she will be asked for a lot of = personal data. InsureMe.com invites her to register and create a new = account, with an ID and password; all this is done over https, so = InsureMe.com is confident it has taken suitable steps to protect the = data from being visible to third parties. > > Third parties on the wire. Experience shows that Primrose's data is = most likely to be > > disclosed to third parties once it is on the InsureMe.com web site. = Your example > > goes on to cite a privacy violation in the form of Gotcher.com. But, = a successful attack > > against InsureMe.com also would violate the confidentiality of = Primrose's data. > > > > Bottom line: I agree with your observation that privacy is not the = same as > > confidentiality, and we often overly simplify these discussions. > > > > Steve > > > > _______________________________________________ > > 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 >=20 > --=20 > - Tim Bray (If you=92d like to send me a private message, see = https://keybase.io/timbray) --Apple-Mail=_9C5808E3-891C-4972-B8E6-75F1374DF607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Many = thanks, Tim -

I think this is a substantial = improvement, and still, of course, a worthwhile line of = investigation.

There are two areas where I = think the situation is more nuanced than the text currently suggests, = though I appreciate your wish to keep things as simple and succinct as = possible. Here are a couple of comments on those two = areas:

5.1 Free public = data:

I agree with your basic thesis, which is = that the publisher of information can=92t reliably tell whether = accessing that information will have negative consequences for the = individual concerned.
The negative consequences are likely to = arise from culturally- or nationally-specific factors, which may not = apply (or even occur) to the publisher, whereas access to the data in = question is overwhelmingly likely to transcend national and cultural = boundaries. (Of course, things that qualify as =93free public data=94 in = one national or cultural context may be no such thing in = another).

Therefore, you conclude, publishers=92 = default should be to publish in a way that respects the privacy of their = readership. The implication is that it should be possible to access free = public data anonymously or pseudonymously.

I = agree, but you will also encounter people who strongly believe = otherwise. I blogged about some of = the perverse consequences of that position, after the IGF in = Baku.

Bottom line: your privacy-respecting = stance here will come under attack for reasons other than the ones your = thesis currently implies. I happen to think most of those attacks are = ill-founded, but they will surface and need to be dealt = with.


5.2 Privacy at user = option

Here, your basic thesis is that privacy = decisions are complex enough to make it impractical for users to have to = "opt in=94 if they want privacy; therefore maximum privacy protection = should be the default. There=92s an implication that users should have = to explicitly opt out of privacy protections as and where they see fit, = but I=92m not sure whether you even intend them to have that choice=85 = As I will say below, I=92m not sure whether you are advocating removal = of the need to choose, or the ability to choose =97 and I think those = are quite different.

I think you will encounter = two forms of push-back to this = position. 

First, we have seen (in the = arguments over a =93Do Not Track=94 flag in browsers) how some = vendors/service providers will maintain that a =93privacy by default=94 = setting does not truly reflect the wishes of the user (and some would go = further and claim that it is not in their best interests, either). There = is the potential for paternalism on both sides of this argument, so one = has to be careful how the question is framed: is =93opted out by = default, with the user choosing to opt in=94 any better than =93opted in = by default, with the user choosing to opt out=94?
If maximum = privacy protection is to be the default, what=92s the best way to allow = users to share consensually when they intend to do = so?

Second, it=92s probably true that the = decisions to opt in or opt out are indeed complex, contextual, variable = over time, etc. etc=85 But removing the need (or ability) to decide is = not necessarily the answer. (Tired analogy: my current car=92s engine is = far more complex than the one my old Mini had. It makes millions of = decisions on my behalf, every time I use it. But the interface presented = to me is still the same arrangement of pedals, gear lever and dials=85 = and the engine only produces the effects I intend, even if the = underlying process is beyond my = understanding).

Bottom line: I think there is = scope for the complexity of privacy decisions (whether opt-out or = opt-in) to be partly addressed by improvements in the technology that = acts on the user=92s behalf - putting the user=92s simply-stated = preferences and choices into practice, without requiring the user to = renew or confirm those every time the question arises. An intelligent = user agent, over which the user exercises complete control. (And, as I = say, I think this would only form part of the over-all = picture).

Well, I can dream, can=92t = I?

HTH,
Robin

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

email: wilton@isoc.org
Phone: +44 705 = 005 2931
Twitter: @futureidentity

On 11 Apr 2015, at 18:23, Tim Bray <tbray@textuality.com> = wrote:

I finally got around to submitting the -01 = draft, considerably re-organized, per feedback here, to make it clear = that the discussion is independent of any particular technology, and to = include a tl;dr er cough excuse me =93Summary=94 section.

Real HTML is = at http= s://www.tbray.org/tmp/draft-bray-privacy-choices-01.html

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A new version of I-D, = draft-bray-privacy-choices-01.txt
has been successfully submitted = by Tim Bray and posted to the
IETF repository.

Name:        =    draft-bray-privacy-choices
Revision:      =  01
Title:        =   Privacy Choices for Internet Data Services
Document = date:  2015-04-11
Group:        =   Individual Submission
Pages:        =   5
URL:        =     http://www.ietf.org/internet-drafts= /draft-bray-privacy-choices-01.txt
Status:      =    https://datatracker.ietf.org/doc/dr= aft-bray-privacy-choices/
Htmlized:      =  http://tools.ietf.org/html/draft-br= ay-privacy-choices-01
Diff:        =    http://www.ietf.org/rfcdiff?url2=3D= draft-bray-privacy-choices-01

Abstract:
   This document argues = in favor of Internet service providers deploying
   technologies which = offer increased privacy to users of their
   services.  The = discussion is independent of any particular privacy
   technology.  = The approach is to consider common objections to the the
   deployment of such = technologies, and show that these objections are
   not = well-founded.

On Mon, Mar 16, 2015 at 7:45 AM, Robin Wilton = <wilton@isoc.org> wrote:
Hi Steve - and thanks for the correction.

I agree with your additional use-cases/threat scenarios, naturally=85 I = was just trying to keep it to one simple illustration ;^)

R

On 16 Mar 2015, at 14:22, Stephen Kent <kent@bbn.com> wrote:

> Robin,
>> ...
>>
>> Primrose goes to InsureMe.com, where she will be asked = for a lot of personal data. InsureMe.com invites her to register = and create a new account, with an ID and password; all this is done over = https, so InsureMe.com is confident = it has taken suitable steps to protect the data from being visible to = third parties.
> Third parties on the wire. Experience shows that Primrose's data is = most likely to be
> disclosed to third parties once it is on the InsureMe.com web site. Your example
> goes on to cite a privacy violation in the form of Gotcher.com. But, a successful = attack
> against InsureMe.com also would = violate the confidentiality of Primrose's data.
>
> Bottom line: I agree with your observation that privacy is not the = same as
> confidentiality, and we often overly simplify these = discussions.
>
> 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




--
- Tim Bray (If you=92d like = to send me a private message, see https://keybase.io/timbray)

= --Apple-Mail=_9C5808E3-891C-4972-B8E6-75F1374DF607-- --Apple-Mail=_24969314-F968-4E37-9E91-30747B98A9CC 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----- iEYEARECAAYFAlUtFKoACgkQx1kEWLxmyT0lgACfRm756mZtmwn6E5gGFyMVvoR3 5p0AoJEVBabbkkOQ8dg0mocDTz9eb7HI =bKy8 -----END PGP SIGNATURE----- --Apple-Mail=_24969314-F968-4E37-9E91-30747B98A9CC-- From nobody Fri Apr 17 04:29:55 2015 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 6FA8F1A1A2E for ; Fri, 17 Apr 2015 04:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOzL2R5rpzbo for ; Fri, 17 Apr 2015 04:29:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12061A1A1E for ; Fri, 17 Apr 2015 04:29:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9B0FBBF15 for ; Fri, 17 Apr 2015 12:29:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd7dP4egqeFX for ; Fri, 17 Apr 2015 12:29:49 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E7AFBF14 for ; Fri, 17 Apr 2015 12:29:49 +0100 (IST) Message-ID: <5530EEAB.5050601@cs.tcd.ie> Date: Fri, 17 Apr 2015 12:29:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 11:29:53 -0000 Hiya, I think this list has been really useful since we started it back in August 2013. We initiated a bunch of new work on here (e.g. cfrg curves, tcpinc, dprive, rfc7258) and I think the concerns dealt with here have influenced lots of other work in the IETF as well. Many thanks for all that great input and of course most of the things above aren't finished, but even so, we're now looking for some more great input:-) The IESG will be meeting f2f in early May at our "retreat" and one of the topics on that agenda is "where next with perpass" so your ideas on that are very welcome. Please discuss those here and/or send 'em to the IESG or to some random AD or to me. But discussing 'em on this list is way better, and of course even betterer is to write an I-D (and please do point again at ones you've written, just to refresh folks' minds). While I do have some ideas, I'd rather not skew the discussion by throwing those out right now. I will also report back here after the IESG discussion. And just as a reminder, we've used this list mostly for very initial discussions and seen all chunky items of work handled elsewhere, be that in current WGs or by forming new WGs or whatever. I think that's been a good mode of operation so far, so we're not really asking here about how to change that, but rather for discussion of which topics we can usefully try handle in that same way over the coming year or two. So, fire away... Thanks, S. From nobody Fri Apr 17 07:02:51 2015 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 2FF8F1B2D08 for ; Fri, 17 Apr 2015 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 isIcEz1QC_A9 for ; Fri, 17 Apr 2015 07:02:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153231B2D10 for ; Fri, 17 Apr 2015 07:02:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 24BC1E033 for ; Fri, 17 Apr 2015 10:13:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E178563B76; Fri, 17 Apr 2015 10:02:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CC9F9636B6 for ; Fri, 17 Apr 2015 10:02:32 -0400 (EDT) From: Michael Richardson To: perpass In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> References: <5530EEAB.5050601@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 14:02:50 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Stephen Farrell wrote: > While I do have some ideas, I'd rather not skew the discussion by > throwing those out right now. I will also report back here after > the IESG discussion. > And just as a reminder, we've used this list mostly for very > initial discussions and seen all chunky items of work handled > elsewhere, be that in current WGs or by forming new WGs or > whatever. I think that's been a good mode of operation so far, > so we're not really asking here about how to change that, but > rather for discussion of which topics we can usefully try handle > in that same way over the coming year or two. I think that the items have been correctly chunked off, and I think that waiting is not yet complete, so we can not yet grok what the next step is. I think that the ACME work is very significant, and once it is further alon= g, I think that extending it into non-web-server realms is important. The biggest issue that I see in the perpass space has been persistent market failures of some of our key technologies. Not entirely our problem, but ea= ch time I see an industry "consortia" write a specification behind closed doors that is more than a list of RFCs, I think we have failed. Among groups that I have observed the Broadband Forum has done the best job in my opinion. This is very much a case where there has been a significant gap between what we specify, and what there are resources to actually implement *AND* deploy. I wish that the consortia could be involved in funding and coordinating open source reference implementations. The Eclipse and Apache foundations are sometimes really good at this, but they also seem to go and invent new specifications at times for reasons I think has more to do who is funding them than what is needed. So my message to the IESG for your retreat is: how can the IETF better leverage ISOC's contacts and marketing efforts... How can we make IETF work= (including "running code") more relevant to things like Tenure Track committees... can we "infiltrate" NSF-like entities in various places. Many ccTLD entities seem to have money to spend on infrastructure initiatives (CIRA, nic.cz, nic.nl, nic.mx are the ones I know about)... maybe there could be some overt coordination here. =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; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTESeICLcPvd0N1lAQL6bggAq/AzjMY1T/HlNcbifr5Hhx+22KSf/5k9 bJOlJKkWve4MIjFLfjFXvr519uCVPjfNlkozBOm/0bsgcDb+eG9zUWmfhSTXv7I9 e4INQraEjrX4VjidxHP/u+FIXzChHmmkFM6wQWAQsPQHhaglzkqgJdEPD/BGXF1/ 8vP26u7YjtaP4Qb5N+5iuSyO902RGyXZIu8Fj2260Tevi3Qsx0hxS+EMWAROiL4Q S/m7EjW1pO/2uNPZaSgW1OLlhu+hCgXCPTwIaz0RDBZZDyGpdWHMJpWHJ+WK04Ny /XdFZqp6aVullmvsv8RcjNi8KDEUdBuNxwCMk6P4efOf19YvM4BgWw== =PSJX -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 17 12:02:12 2015 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 4007F1A8965 for ; Fri, 17 Apr 2015 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRmXywmA_IZP for ; Fri, 17 Apr 2015 12:02:09 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4694F1B2F85 for ; Fri, 17 Apr 2015 12:01:59 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t3HJ1woC014853 for ; Fri, 17 Apr 2015 12:01:58 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 8D5EA40115CB for ; Fri, 17 Apr 2015 12:01:58 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl0ZLjtlKxh2 for ; Fri, 17 Apr 2015 12:01:57 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id 70F2840115C1 for ; Fri, 17 Apr 2015 12:01:57 -0700 (PDT) Message-ID: <553158A6.3060504@well.com> Date: Fri, 17 Apr 2015 12:01:58 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5530EEAB.5050601@cs.tcd.ie> In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 19:02:11 -0000 Hi all, Congratulations on the great work to date. But let's understand, that while the workproducts to date will help shore up the security of our legacy internet architecture, My impression after Snowden et. is that the whole stack offers up a vast exploitable attack surface. and that IETF ought to begin _serious_ consideration of completely new secure architectures - e.g. a secure onion/tor routed peer internet, meshnets, blockchains for cerificated authentication ., etc. It's a little ironic that the military, IC and black hats already have secure p2p internets, Isn't it time for the rest of us to enjoy the same levels of privacy and security, and *resilience*? Michael Liebhold Senior Researcher, Distinguished Fellow Institute for the Future @mikeliebhold @iftf On 4/17/15 4:29 AM, Stephen Farrell wrote: > Hiya, > > I think this list has been really useful since we started it back > in August 2013. We initiated a bunch of new work on here (e.g. cfrg > curves, tcpinc, dprive, rfc7258) and I think the concerns dealt > with here have influenced lots of other work in the IETF as well. > Many thanks for all that great input and of course most of the > things above aren't finished, but even so, we're now looking for > some more great input:-) > > The IESG will be meeting f2f in early May at our "retreat" and one > of the topics on that agenda is "where next with perpass" so your > ideas on that are very welcome. > > Please discuss those here and/or send 'em to the IESG or to some > random AD or to me. But discussing 'em on this list is way better, > and of course even betterer is to write an I-D (and please do point > again at ones you've written, just to refresh folks' minds). > > While I do have some ideas, I'd rather not skew the discussion by > throwing those out right now. I will also report back here after > the IESG discussion. > > And just as a reminder, we've used this list mostly for very > initial discussions and seen all chunky items of work handled > elsewhere, be that in current WGs or by forming new WGs or > whatever. I think that's been a good mode of operation so far, > so we're not really asking here about how to change that, but > rather for discussion of which topics we can usefully try handle > in that same way over the coming year or two. > > So, fire away... > > Thanks, > S. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From nobody Fri Apr 17 21:44:20 2015 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 309821A9026 for ; Fri, 17 Apr 2015 21:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jRcoknNHO4m for ; Fri, 17 Apr 2015 21:44:16 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8A81A9007 for ; Fri, 17 Apr 2015 21:44:15 -0700 (PDT) Received: by wgsk9 with SMTP id k9so130707663wgs.3 for ; Fri, 17 Apr 2015 21:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9QbOaShjxOlwl2YEpEbDMEjTbr4mQYwDPCl0knVYUmw=; b=JqWr19mOjam+QuxfUR9yPyM2T4toEs9mWv1UQ2M6r6u7ftZTrk02jaToPoPheqEkFl RbGrC4kj4oG01disVCJtv4ODWRg6zGXEFg4KluDz7KJbsPGMBzUUdEZKhwyL8HA33hV7 M9B005Yk9GEEU48OgPRdLIIfR97y8eItfP/P6i1zHJwNX74EsoXfwqeJpWVWBrVxCwcJ /s/zFWPAZnPihZ+ScFp+fooaFA84aXOMhM3JT1TdXNfWWVwQ+VqHLigcQ7AKNp5fMW5B AAPzQJy7mps3UMdgaTnaDXE/6j5dG388Ky7qduYw5DcZHyfWpLf+89NCbn2YQ2H6KTGb ZljA== MIME-Version: 1.0 X-Received: by 10.180.99.42 with SMTP id en10mr6770346wib.83.1429332254813; Fri, 17 Apr 2015 21:44:14 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Fri, 17 Apr 2015 21:44:14 -0700 (PDT) In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> References: <5530EEAB.5050601@cs.tcd.ie> Date: Fri, 17 Apr 2015 21:44:14 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: perpass Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 04:44:18 -0000 On Fri, Apr 17, 2015 at 4:29 AM, Stephen Farrell wrote: > > Hiya, > > I think this list has been really useful since we started it back > in August 2013. We initiated a bunch of new work on here (e.g. cfrg > curves, tcpinc, dprive, rfc7258) and I think the concerns dealt > with here have influenced lots of other work in the IETF as well. > Many thanks for all that great input and of course most of the > things above aren't finished, but even so, we're now looking for > some more great input:-) > > The IESG will be meeting f2f in early May at our "retreat" and one > of the topics on that agenda is "where next with perpass" so your > ideas on that are very welcome. > > Please discuss those here and/or send 'em to the IESG or to some > random AD or to me. But discussing 'em on this list is way better, > and of course even betterer is to write an I-D (and please do point > again at ones you've written, just to refresh folks' minds). -Key discovery in email has been kicked around a bunch, but no reasonable proposals yet. Doesn't seem that hard. -Messaging might be premature to discuss, as there are various approaches, but we should think about it. -There has been talk of PGP refreshing, but I don't know if that happened/is being worked on -Much of the work on better SSH has been ignored in standards: would be nice to see some things adopted (useable PKI, etc) -Anonymity remains untouched. Sincerely, Watson Ladd > > While I do have some ideas, I'd rather not skew the discussion by > throwing those out right now. I will also report back here after > the IESG discussion. > > And just as a reminder, we've used this list mostly for very > initial discussions and seen all chunky items of work handled > elsewhere, be that in current WGs or by forming new WGs or > whatever. I think that's been a good mode of operation so far, > so we're not really asking here about how to change that, but > rather for discussion of which topics we can usefully try handle > in that same way over the coming year or two. > > So, fire away... > > Thanks, > S. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Apr 18 05:29:18 2015 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 38A811A86E6 for ; Sat, 18 Apr 2015 05:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFgUrQyjFM0s for ; Sat, 18 Apr 2015 05:29:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F281A802D for ; Sat, 18 Apr 2015 05:29:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24F93BEF5; Sat, 18 Apr 2015 13:29:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAXnbI-z3j7h; Sat, 18 Apr 2015 13:29:06 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E4427BEE5; Sat, 18 Apr 2015 13:29:05 +0100 (IST) Message-ID: <55324E0C.7010104@cs.tcd.ie> Date: Sat, 18 Apr 2015 13:29:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Watson Ladd References: <5530EEAB.5050601@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: perpass Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 12:29:17 -0000 Just adding a factoid... On 18/04/15 05:44, Watson Ladd wrote: > -There has been talk of PGP refreshing, but I don't know if that > happened/is being worked on Yep, there's been nicely active discussion on the openpgp list [1] for the last month and a bit and that may be shaping up to turn into a wg that'll mostly develop an RFC4880bis, at least to start off with. If anyone cares about that: goto [1] :-) S. [1] https://www.ietf.org/mail-archive/web/openpgp/current/maillist.html From nobody Sat Apr 18 09:38:11 2015 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 F1F0D1A8859 for ; Sat, 18 Apr 2015 09:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 NNsWkuBu_ZYO for ; Sat, 18 Apr 2015 09:38:08 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173B01A0004 for ; Sat, 18 Apr 2015 09:38:08 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so103357882lbb.2 for ; Sat, 18 Apr 2015 09:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mwoMMForLARYSC4Aw+qLr8EfZWMfGp+n0TjyhSYIBhI=; b=piAyl0sNFT0Yovzg4/wus1nFpa/ZmfM6Fw6Q5XPTLr+nXD9dNUuifDOTAQ7zEZa2zU fXKcR8vB8KSF/ya8wZ25t7sqCxEySvi2sdQ8m7PWuK4KR7bYzOMuvzVJoexDq6u21+TH edOmBhb0pmDwgBerCIX6xjveBdpDUZVsGKtMw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mwoMMForLARYSC4Aw+qLr8EfZWMfGp+n0TjyhSYIBhI=; b=CT3qtOMKD7+2j4nr7cDBPb666TFJATarQfrGNr7cSGKtkcOurr1pBfcAOwyEsVy2lH A5AxlYTgErWzP5mSJSADPUY1/5hKSKM+pHxx6jMEn8WO1GoFq5ODEqghITcuILmRjiNs j/+1QMrcFM+/M/vKHJEEBlJOfrJc0UaCQFRK9HYMe9gwrQ04ERCvbRj6Ll5rFBxMRaug C5OaHVyjPm6nJw/8iKH8pX/SntgWHH79o2z74FvsTgOdTYMkLHzc7+X50gEuKcILScYg s0z8Stre74jKL3+TEa861ySga9epyvXsCqHreVbyalCLn+RzHVyQccDttDmWogYJ84ge CGNw== X-Gm-Message-State: ALoCoQlfscq2uaU1uIThWU5+klFh2fme43uj3e5c7tldNJpewyN4/qo5OKbOFCzA158F5jBOp73F X-Received: by 10.152.205.106 with SMTP id lf10mr8871467lac.89.1429375086461; Sat, 18 Apr 2015 09:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.125.9 with HTTP; Sat, 18 Apr 2015 09:37:46 -0700 (PDT) In-Reply-To: References: <5530EEAB.5050601@cs.tcd.ie> From: Adam Caudill Date: Sat, 18 Apr 2015 12:37:46 -0400 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1134990847969e051402522f Archived-At: Cc: perpass , Stephen Farrell Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 16:38:10 -0000 --001a1134990847969e051402522f Content-Type: text/plain; charset=UTF-8 On Sat, Apr 18, 2015 at 12:44 AM, Watson Ladd wrote: > -Key discovery in email has been kicked around a bunch, but no > reasonable proposals yet. Doesn't seem that hard. > Key discovery, if we limit the scope of the initiative, shouldn't be that hard to achieve, and could lead to a huge amount of progress. Email is so horribly broken, I think the entire system needs to be replaced, but I think it's clear that we aren't at a point where that's going to happen. While I, and I think many of us, would like a solution that addresses the metadata leaking and other major issues, the changes are too radical to work within the current system. So, if we can get to the point that we are encrypting a higher percentage, I think that's a goal worth pursuing. We aren't going to achieve the perfect, certainly not now, and to achieve anything, I think we are going to have to limit our definition of good. While I want to see email as we know it replaced with something that provides strong modern crypto, forward secrecy, minimal metadata leaks, and all messages encrypted by default - at this point I'd be happy if we could get the number of emails using end to end crypto to a non-trivial number. For now, that might be the best we can actually achieve. Email is likely the largest source of exposed information that end users expect to be private, and while much has been done in other areas, email remains wide open. Opportunistic SSL/TLS has become more common, and it does provide some privacy, we all know that it's not real security and how trivial it is for an active attacker to disable. This is an area that desperately needs some progress made. There's been some discussion on the endymail[1] list, but there hasn't been any real progress - I don't believe anything actionable has come out of it so far. [1] https://www.ietf.org/mail-archive/web/endymail/current/maillist.html --001a1134990847969e051402522f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 18, 2015 at 12:44 AM, Watson Ladd <watsonbladd@gmail.= com> wrote:
-Key discovery in email has been kicked around a bunch, but no reasonable proposals yet. Doesn't seem that hard.
= =C2=A0
Key discovery, if we limit the scope of the initiativ= e, shouldn't be that hard
to achieve, and could lead to a hug= e amount of progress.

Email is so horribly broken,= I think the entire system needs to be replaced, but
I think it&#= 39;s clear that we aren't at a point where that's going to happen. = While
I, and I think many of us, would like a solution that addre= sses the metadata
leaking and other major issues, the changes are= too radical to work within the
current system. So, if we can get= to the point that we are encrypting a higher
percentage, I think= that's a goal worth pursuing. We aren't going to achieve the
=
perfect, certainly not now, and to achieve anything, I think we are go= ing to
have to limit our definition of good. While I want to see = email as we know it
replaced with something that provides strong = modern crypto, forward secrecy,
minimal metadata leaks, and all m= essages encrypted by default - at this point
I'd be happy if = we could get the number of emails using end to end crypto to a
no= n-trivial number. For now, that might be the best we can actually achieve.<= /div>

Email is likely the largest source of exposed info= rmation that end users expect
to be private, and while much has b= een done in other areas, email remains wide
open. Opportunistic S= SL/TLS has become more common, and it does provide some
privacy, = we all know that it's not real security and how trivial it is for an
active attacker to disable. This is an area that desperately needs = some progress
made. There's been some discussion on the endym= ail[1] list, but there hasn't
been any real progress - I don&= #39;t believe anything actionable has come out of it
so far.


--001a1134990847969e051402522f-- From nobody Sat Apr 18 20:26:35 2015 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 6C26A1A883F for ; Sat, 18 Apr 2015 20:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 d8B8RuJQnJV1 for ; Sat, 18 Apr 2015 20:26:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B201A883C for ; Sat, 18 Apr 2015 20:26:33 -0700 (PDT) Received: (qmail 84135 invoked from network); 19 Apr 2015 03:26:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Apr 2015 03:26:32 -0000 Date: 19 Apr 2015 03:26:10 -0000 Message-ID: <20150419032610.1333.qmail@ary.lan> From: "John Levine" To: perpass@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: watsonbladd@gmail.com Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 03:26:34 -0000 >-Key discovery in email has been kicked around a bunch, but no >reasonable proposals yet. Doesn't seem that hard. There's a draft in DANE which I think is fatally flawed for reasons that boil down to DNS lookups are utterly unlike mailbox lookups. I agree it's not that hard. Something like webfinger with the http server found via SRV should work. R's, John From nobody Sat Apr 18 20:26:50 2015 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 9F7101ACEC5 for ; Sat, 18 Apr 2015 20:26:48 -0700 (PDT) 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 vfuVwYkHv6UN for ; Sat, 18 Apr 2015 20:26:46 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A1A1ACEC2 for ; Sat, 18 Apr 2015 20:26:46 -0700 (PDT) Received: by labbd9 with SMTP id bd9so105038366lab.2 for ; Sat, 18 Apr 2015 20:26:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dhfBmFHQ99eZhyUNFLWUf87SiMwbJpg2jziJHKckQBI=; b=lbz8kvN4P74ynuwGxlonYPNo3LHZkGb5IrR8pONnF+LzSBN/Ekb68CVfl+s3IDgcI2 Jp4DuPM9Y9kU5TopYUlS3RrP1CNUOBGpZm0P0kGl2c6YjTQ8svTpm3PR8BNBv0BeNjfy f3n3k0V4YiLuB+sIi6M6r29PnJv2CAt/0VenLyqwmpuxBlF73tRdsEv2d94u3na9l4Ub PfXhuYFp8QZSNZLjqF1rc16FSiq91WPW8Sw8ewrb0zBLbZJKIgpEwIHHtqVzrcTyCts1 xLz1skdaI6QFk/Ac1OWCsvxmqfxqtvBll+zzFXQfPLm74gd3JrFETJQCCfuHQcudw1cS GlEg== X-Gm-Message-State: ALoCoQnX9zBA75rosBgzC0X29s3rbBJERxk7j3rISIlCRTm6DSEWASH0qo914EsYpHYynomaW6T6 X-Received: by 10.112.126.136 with SMTP id my8mr10351717lbb.18.1429414004800; Sat, 18 Apr 2015 20:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.18.36 with HTTP; Sat, 18 Apr 2015 20:26:24 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> References: <5530EEAB.5050601@cs.tcd.ie> From: Tim Bray Date: Sat, 18 Apr 2015 20:26:24 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c3799afe531e05140b6158 Archived-At: Cc: perpass Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 03:26:48 -0000 --001a11c3799afe531e05140b6158 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess, since I submitted two revs of https://tools.ietf.org/html/draft-bray-privacy-choices, it=E2=80=99s probab= ly self-evident that I think that=E2=80=99s a useful line of work. But just t= o be explicit: I do, and am available for editorial duties if there=E2=80=99s co= nsensus on moving it forward. On Fri, Apr 17, 2015 at 4:29 AM, Stephen Farrell wrote: > > Hiya, > > I think this list has been really useful since we started it back > in August 2013. We initiated a bunch of new work on here (e.g. cfrg > curves, tcpinc, dprive, rfc7258) and I think the concerns dealt > with here have influenced lots of other work in the IETF as well. > Many thanks for all that great input and of course most of the > things above aren't finished, but even so, we're now looking for > some more great input:-) > > The IESG will be meeting f2f in early May at our "retreat" and one > of the topics on that agenda is "where next with perpass" so your > ideas on that are very welcome. > > Please discuss those here and/or send 'em to the IESG or to some > random AD or to me. But discussing 'em on this list is way better, > and of course even betterer is to write an I-D (and please do point > again at ones you've written, just to refresh folks' minds). > > While I do have some ideas, I'd rather not skew the discussion by > throwing those out right now. I will also report back here after > the IESG discussion. > > And just as a reminder, we've used this list mostly for very > initial discussions and seen all chunky items of work handled > elsewhere, be that in current WGs or by forming new WGs or > whatever. I think that's been a good mode of operation so far, > so we're not really asking here about how to change that, but > rather for discussion of which topics we can usefully try handle > in that same way over the coming year or two. > > So, fire away... > > Thanks, > S. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3799afe531e05140b6158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I g= uess, since I submitted two revs of=C2=A0https://tools.ietf.org/html/draft-bray-privacy-choices, = it=E2=80=99s probably self-evident that I think that=E2=80=99s a useful lin= e of work.=C2=A0 But just to be explicit: I do, and am available for editor= ial duties if there=E2=80=99s consensus on moving it forward.



On Fri, Apr 17, 2015 at 4:29 AM, Stephe= n Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

I think this list has been really useful since we started it back
in August 2013. We initiated a bunch of new work on here (e.g. cfrg
curves, tcpinc, dprive, rfc7258) and I think the concerns dealt
with here have influenced lots of other work in the IETF as well.
Many thanks for all that great input and of course most of the
things above aren't finished, but even so, we're now looking for some more great input:-)

The IESG will be meeting f2f in early May at our "retreat" and on= e
of the topics on that agenda is "where next with perpass" so your=
ideas on that are very welcome.

Please discuss those here and/or send 'em to the IESG or to some
random AD or to me. But discussing 'em on this list is way better,
and of course even betterer is to write an I-D (and please do point
again at ones you've written, just to refresh folks' minds).

While I do have some ideas, I'd rather not skew the discussion by
throwing those out right now. I will also report back here after
the IESG discussion.

And just as a reminder, we've used this list mostly for very
initial discussions and seen all chunky items of work handled
elsewhere, be that in current WGs or by forming new WGs or
whatever. I think that's been a good mode of operation so far,
so we're not really asking here about how to change that, but
rather for discussion of which topics we can usefully try handle
in that same way over the coming year or two.

So, fire away...

Thanks,
S.

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



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11c3799afe531e05140b6158-- From nobody Sun Apr 19 07:54:09 2015 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 8BCAB1B2C7A for ; Sun, 19 Apr 2015 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGL5I0y6ExFS for ; Sun, 19 Apr 2015 07:54:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2111B2C77 for ; Sun, 19 Apr 2015 07:54:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lVDgt3NPyz74h for ; Sun, 19 Apr 2015 16:54:02 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=jOfEUgDK X-OPENPGPKEY: Message passed unmodified 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 6EWWbQtChmXf for ; Sun, 19 Apr 2015 16:54:00 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 19 Apr 2015 16:54:00 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 32478809F8 for ; Sun, 19 Apr 2015 10:53:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429455239; bh=baziP2FnSTHAwEamJSCCh5vEQIs+iXeisoUNMC9KaqE=; h=Date:From:To:Subject:In-Reply-To:References; b=jOfEUgDKiZm5cH7sgcW902a4cpEyi0gQIikv76MSZhkFhBeslXaGKWCds4NagSoBu Vax7LWnmPYmKsNsL06a0DD2muGH5lt+UzR5I+fxoQtnojNPLCqjul6zbitDB8Rp5Hd sL1jF+f7BhT2l9FqgAt06UrfLKmDvMWl0NiAL7WE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3JErwfM014998 for ; Sun, 19 Apr 2015 10:53:58 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 19 Apr 2015 10:53:58 -0400 (EDT) From: Paul Wouters To: perpass@ietf.org In-Reply-To: <20150419032610.1333.qmail@ary.lan> Message-ID: References: <20150419032610.1333.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 14:54:07 -0000 On Sat, 19 Apr 2015, John Levine wrote: >> -Key discovery in email has been kicked around a bunch, but no >> reasonable proposals yet. Doesn't seem that hard. > > There's a draft in DANE which I think is fatally flawed for reasons > that boil down to DNS lookups are utterly unlike mailbox lookups. > > I agree it's not that hard. Something like webfinger with the http > server found via SRV should work. And at the dane list it is also discussed why others think the current proposal(s) work well for real life mailboxes, and why out-of-band key discovery for email boxes is very problematic. For perpass people not on the dane list, the proposals for key discovery for verifying and encrypting email are: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 https://tools.ietf.org/html/draft-ietf-dane-smime-08 Paul From nobody Tue Apr 21 10:00:16 2015 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 E53AC1AD36C for ; Tue, 21 Apr 2015 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3VQCeE64ZYW for ; Tue, 21 Apr 2015 10:00:13 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FB81AD374 for ; Tue, 21 Apr 2015 09:59:48 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t3LGxl93005632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Apr 2015 18:59:48 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t3LGxltA005631 for perpass@ietf.org; Tue, 21 Apr 2015 18:59:47 +0200 Date: Tue, 21 Apr 2015 18:59:47 +0200 From: carlo von lynX To: perpass@ietf.org Message-ID: <20150421165947.GA3690@lo.psyced.org> References: <5530EEAB.5050601@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:00:16 -0000 I'm so glad to hear more and more voices talk about taking 'clean slate' into serious consideration. After five years talking to walls I feel like the walls are starting to shake... On Fri, Apr 17, 2015 at 12:01:58PM -0700, Mike Liebhold wrote: > [..] My impression after Snowden et. > is that the whole stack offers up a vast exploitable attack surface. > and that IETF ought to begin _serious_ consideration of completely > new secure architectures - e.g. a secure onion/tor routed peer > internet, meshnets, blockchains for cerificated authentication ., > etc. It's a little ironic that the military, IC and black hats > already have secure p2p internets, Isn't it time for the rest of us > to enjoy the same levels of privacy and security, and *resilience*? Whoops! This is the first time I hear that some parts of the Internet already *have* the sort of architecture some research folks have been working on for over a decade now? Do you have *any* pointers about this? On Sat, Apr 18, 2015 at 12:37:46PM -0400, Adam Caudill wrote: > Email is so horribly broken, I think the entire system needs to be > replaced, but > I think it's clear that we aren't at a point where that's going to happen. That, I firmly believe, is one of the greatest fallacies in the community. Faceboogle, Whatschat and Snapapp have already proven that users do not care about the looks of their messaging app as long as it reaches their peers and possibly does so in a neater way than old-fashioned formal e-mail. I met a girl of twenty who managed to get to that age with *FIVE* addresses in her e-mail address book. The only five institutions or people she couldn't convince to use something fancier. And this girl does care about privacy.. her group meets on Telegram and uses end-to-end crypto.. but what's the point in preferring e-mail if it is completely insecure? And of course the PGP hassle is completely inacceptable. So maybe, just maybe.. instead of waiting until the population has to a large extent dropped e-mail and gone proprietary, we should come up with something that actually works. Getting people to install an app or operating systems to ship with a new messaging standard is probably not the greatest hurdle. Trying to remain backwards compatible at the expense of UX, security and popularity is the big mistake here. Just let the systems co-exist and watch how users will slowly migrate away from e-mail as they migrated away from Myspace. To you that may sound like apples and oranges, but to them it's just like giving up on Myspace. > While I, and I think many of us, would like a solution that addresses the metadata > leaking and other major issues, the changes are too radical to work within > the current system. So, if we can get to the point that we are encrypting a > higher percentage, I think that's a goal worth pursuing. We aren't going to > achieve the perfect, certainly not now, and to achieve anything, I think we are going to > have to limit our definition of good. While I want to see email as we know > it replaced with something that provides strong modern crypto, forward secrecy, > minimal metadata leaks, and all messages encrypted by default - at this > point I'd be happy if we could get the number of emails using end to end crypto > to a non-trivial number. For now, that might be the best we can actually achieve. There is no "for now" - there is no reason to wait any longer for better things. Technologies like GNUnet and RINA are waiting to get debugged, improved and be deployed. A worldwide end-to-end encrypted and anonymizing communications system is a feasible goal and focusing on anything less will make us contempt that we at least achieved *something* ... while Snowden and the NSA itself said that the metadata is the real meat that is threatening our western societies. Letting a few people decide whether there is or isn't democracy is exactly what the separation of powers (aka checks & balances) was supposed to protect us from - but with the Internet we have created a monster that makes it impossible to detect the infringement of the secrecy of communication. And the metadata collection makes the freedom of assembly a joke - it wasn't intended as a means to know exactly who is dissenting with the government. Thinking that e-mail is such a huge investment that we cannot step back from it and replace it is one of the great mistakes in thinking that the IESG could focus on correcting. Another one is the popular belief in the federation of servers as a viable architecture. Federation has failed us several times. See http://about.psyc.eu/Federation for a write-up on that. > There's been some discussion on the endymail[1] list, but there hasn't > been any real progress - I don't believe anything actionable has come out > of it so far. > > [1] https://www.ietf.org/mail-archive/web/endymail/current/maillist.html I'm still waiting for replies to my proposal. I suggested to either use the GNU Name System (GNS) or a Distributed Social Graph strategy to address the problems of keys, discovery and SPAM protection seen in traditional mail systems. I'm afraid the biggest hurdle in starting this kind of serious discussion is that the technologies needed to make *distributed* communications systems with agnostic relays (think Tor) rather than metadata-scient servers are coming from the research community that has quietly worked on these topics for several decades and is now confronting the majority of Internet experts like you and me (luckily I started looking into this 5 years ago, so I've got a little headstart) with a whole new design that hardly has anything to do with everything you have been familiar with in the past decades. No more DNS/DNSSEC/DANE, no more X.509, no need for IPv6. So much of what was achieved will remain for secondary purposes but must be obsoleted for the main objective of making humans interact. Currently I'd say http://freehaven.net/anonbib/ is the new IETF. Scientific consensus and eventually running code is the new credo. At least if we want to focus on the needs of humans, not make the net a bit more responsive (QUIC) or the browser a bit more remote- controllable (WebRTC) - usually with a cloud server acting as the big brother. Wait, there's more. Since we don't expect that there is enough economic motivation for the great players of the Internet to throw money at this problem and focus on it - some folks and I have prepared a law proposal that would make secure and anonymous networking a precondition for selling computers or devices after a certain date. This would create the necessary incentive to focus all engineering intelligence on solving these issues ASAP. You may want to promote it (or suggest edits to it). It's here: http://youbroketheinternet.org/legislation/ So here's my three point plan for perpass: - Do some housekeeping concerning old thinking that has long been disproven but keeps bubbling up in the collective mentality of the Internet engineering community. - Promote thorough analysis and understanding of what some of us call "GNU Internet" technologies (lacking better terms). Create the mental foundation necessary to be able to participate in the process. - Start working on some layers and protocols involved, since a whole new stack is necessary for end-user apps to materialize. As it stands it's like TCP/IP happening again: a few visionary guys are brewing up the entire network stack and everybody else will start discussing it when it's already a reality going into people's households. -- E-mail is public! Talk to me in private using Tor. torify telnet loupsycedyglgamf.onion DON'T SEND ME irc://loupsycedyglgamf.onion:67/lynX PRIVATE EMAIL http://loupsycedyglgamf.onion/LynX/ OR FACEBOOGLE From nobody Tue Apr 21 13:24:10 2015 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 103691A8886 for ; Tue, 21 Apr 2015 13:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1mOPAzAeEga for ; Tue, 21 Apr 2015 13:24:07 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id F33EF1A8A03 for ; Tue, 21 Apr 2015 13:24:05 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t3LKO49K007133; Tue, 21 Apr 2015 13:24:04 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 19AC040103C1; Tue, 21 Apr 2015 13:24:05 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eu0mTikKCfU; Tue, 21 Apr 2015 13:24:04 -0700 (PDT) Received: from MLiebhold.local (unknown [209.213.222.2]) by zimbra.well.com (Postfix) with ESMTPSA id E8AB540103D1; Tue, 21 Apr 2015 13:24:03 -0700 (PDT) Message-ID: <5536B1E2.6070202@well.com> Date: Tue, 21 Apr 2015 13:24:02 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: carlo von lynX , perpass@ietf.org References: <5530EEAB.5050601@cs.tcd.ie> <20150421165947.GA3690@lo.psyced.org> In-Reply-To: <20150421165947.GA3690@lo.psyced.org> Content-Type: multipart/alternative; boundary="------------030903020807080109020801" Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:24:09 -0000 This is a multi-part message in MIME format. --------------030903020807080109020801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/21/15 9:59 AM, carlo von lynX wrote: > the first time I hear that some parts of the > Internet already*have* the sort of architecture some research > folks have been working on for over a decade now? Do you have > *any* pointers about this? e.g. - hidden services on TOR , and other onion networks https://www.torproject.org/docs/hidden-services.html.en - Military MANETs Mobile Ad Hoc Networks e.g. https://datatracker.ietf.org/doc/charter-ietf-manet/ - Zeta Cartel wireless network, http://www.wired.com/2012/11/zeta-radio/ - the blockchain...etc.. There's lots more --------------030903020807080109020801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/21/15 9:59 AM, carlo von lynX wrote:
the first time I hear that some parts of the
Internet already *have* the sort of architecture some research
folks have been working on for over a decade now? Do you have
*any* pointers about this?

e.g.
- hidden services on TOR , and other onion networks
https://www.torproject.org/docs/hidden-services.html.en

-  Military MANETs Mobile Ad Hoc Networks e.g.
 https://datatracker.ietf.org/doc/charter-ietf-manet/

- Zeta Cartel wireless network,
http://www.wired.com/2012/11/zeta-radio/

- the blockchain...etc..

There's lots more

--------------030903020807080109020801-- From nobody Wed Apr 22 06:58:43 2015 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 AC26A1A9130 for ; Wed, 22 Apr 2015 06:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 u8jV_evwBcY0 for ; Wed, 22 Apr 2015 06:58:40 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB7E1A9120 for ; Wed, 22 Apr 2015 06:58:32 -0700 (PDT) Received: by wgso17 with SMTP id o17so248072628wgs.1 for ; Wed, 22 Apr 2015 06:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gWgvHoFFwgrjz2MoUNE8LKQ0TnzpXKFmPtZibjzOAs4=; b=lRbGSNvcFmUUjXou6O3kHBjkSQppeH+DYMX7axocSji2dvot9yZPst9xN+p3odXQ7x GccqBUldcXFNE/fzK8zIQcIesSlnCXXYO0LMvsRA008AGRcKmGTj4/djz9wpj1R43MuB 54LiCsWyMPwRxnCc2lPJMH3CjBdlyYb2t/HYLYWfQ9aWDn9kbkoQbiGH60I7yQi9Zfui LLLI1oP9MSF87IraQ+p3hfi6IRd2B6HAGftk9J3aAf77mrYdHkIsRnX6ANbJDfCK4rhE 5LsgY7nT3gthTyhZWoX4YZriW1U4yK8uus0wGKBR3HoaaSUUHNy5/+cSGq9NuEkb389C +Odg== MIME-Version: 1.0 X-Received: by 10.180.99.42 with SMTP id en10mr6257667wib.83.1429711111263; Wed, 22 Apr 2015 06:58:31 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 22 Apr 2015 06:58:31 -0700 (PDT) In-Reply-To: References: <20150419032610.1333.qmail@ary.lan> Date: Wed, 22 Apr 2015 06:58:31 -0700 Message-ID: From: Watson Ladd To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:58:41 -0000 On Sun, Apr 19, 2015 at 7:53 AM, Paul Wouters wrote: > On Sat, 19 Apr 2015, John Levine wrote: > >>> -Key discovery in email has been kicked around a bunch, but no >>> reasonable proposals yet. Doesn't seem that hard. >> >> >> There's a draft in DANE which I think is fatally flawed for reasons >> that boil down to DNS lookups are utterly unlike mailbox lookups. >> >> I agree it's not that hard. Something like webfinger with the http >> server found via SRV should work. > > > And at the dane list it is also discussed why others think the current > proposal(s) work well for real life mailboxes, and why out-of-band > key discovery for email boxes is very problematic. There's a difference between actually solving a problem, and making a stab at a solution. Unless you are a mail provider, you don't know what's actually deployable. In fact, adding SMTP commands and extra headers containing keys is probably much less burdensome from an operational perspective: patching software vs. hooking things up in weird ways. Proposals need to answer the following questions 1: Who gets to say which key to use? 2: How is key rotation handled? 3: Is this going to be compatible with Google/Yahoo/Microsoft's existing way of doing things? 4: How hard it is to start using the new system? As far as I can tell, the DANE based solution doesn't answer much of this. Sincerely, Watson Ladd > > For perpass people not on the dane list, the proposals for key discovery > for verifying and encrypting email are: > > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 > > https://tools.ietf.org/html/draft-ietf-dane-smime-08 > > Paul > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Apr 23 06:31:17 2015 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 E0E5F1B3077 for ; Thu, 23 Apr 2015 06:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMT0_elAKHRi for ; Thu, 23 Apr 2015 06:31:14 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48D41B307F for ; Thu, 23 Apr 2015 06:31:05 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t3NDV9Lb003556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Apr 2015 15:31:09 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t3NDV9dq003555 for perpass@ietf.org; Thu, 23 Apr 2015 15:31:09 +0200 Date: Thu, 23 Apr 2015 15:31:09 +0200 From: carlo von lynX To: perpass@ietf.org Message-ID: <20150423133109.GA3190@lo.psyced.org> References: <5530EEAB.5050601@cs.tcd.ie> <20150421165947.GA3690@lo.psyced.org> <5536B1E2.6070202@well.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5536B1E2.6070202@well.com> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 13:31:16 -0000 On Tue, Apr 21, 2015 at 01:24:02PM -0700, Mike Liebhold wrote: > On 4/21/15 9:59 AM, carlo von lynX wrote: > >the first time I hear that some parts of the > >Internet already*have* the sort of architecture some research > >folks have been working on for over a decade now? Do you have > >*any* pointers about this? > > e.g. > - hidden services on TOR , and other onion networks > https://www.torproject.org/docs/hidden-services.html.en Ehm okay, like everybody else too.. Tor is a bit half way there: - by not providing bidirectional authentication it favors client/server architectures even when routing by public key. where it bidirectional, doing e2e apps would be more easy. - by artificially trying to provide real-time performance Tor is unnecessarily easier to de-anonymize by traffic shaping. A fix called "alpha mixing" is however in the planning since 2006. - various other minor issues with the DHT etc to be fixed... > - Military MANETs Mobile Ad Hoc Networks e.g. > https://datatracker.ietf.org/doc/charter-ietf-manet/ > > - Zeta Cartel wireless network, > http://www.wired.com/2012/11/zeta-radio/ heard of these, but didn't think they could be employed this way. will look into them. > - the blockchain...etc.. Bitmessage seems to perform better than I originally expected... because it does not use plain blockchain technology. Blockchain as such must theoretically run into scalability issues as popularity increases, according to my understanding of physics. -- E-mail is public! Talk to me in private using Tor. torify telnet loupsycedyglgamf.onion DON'T SEND ME irc://loupsycedyglgamf.onion:67/lynX PRIVATE EMAIL http://loupsycedyglgamf.onion/LynX/ OR FACEBOOGLE From nobody Thu Apr 23 12:22:10 2015 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 962AA1AD0A9 for ; Thu, 23 Apr 2015 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 fzwZ_8KUjpv6 for ; Thu, 23 Apr 2015 12:22:08 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E9F1AD35A for ; Thu, 23 Apr 2015 12:21:58 -0700 (PDT) Received: by labbd9 with SMTP id bd9so20035106lab.2 for ; Thu, 23 Apr 2015 12:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lNfEt0NWRY2MdLmI0b6LKmSG0gnp9ftEANZ5N7HJZoM=; b=e96G5p1Z6EPbyiRzd0SZnS1DxBYeGdxeZbUhz+J92UovnU5z0XfLTclUxqYToy2IEu F1tdnb3MqECJWwHfondQBeQcQ3t/sSwa41o1DEueLTSHmiDdKoWNR9FDJ4gMrcswX3Ll pzT8Dyd8KRr3p2mOV5WfRXifiW1drqakZAKOcF5s+Sv0M8HnN2LWx9N4yKDLPAJ3P1q9 j603ZHVNdnDfhguOCFa1i7qiBenn/1D8L4zJk6bnepNJ1d/gGXSbmfqad1/0n3BG52LN hUmUlqtdWdCR6UPMCZb0w9K7VhHsVZ+T5CtIMCqzfBjVAaQOpjgFvQE+Wke4mrZDbdKf nUQg== X-Gm-Message-State: ALoCoQlwAyj1en3KjlIZ9K0bXy57LOK/1xBkbHrSITlkiRmr9Xfwq1+u4FeIdKGbFsssESAu6yQ6 X-Received: by 10.152.22.168 with SMTP id e8mr634904laf.27.1429816917512; Thu, 23 Apr 2015 12:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.84.15 with HTTP; Thu, 23 Apr 2015 12:21:36 -0700 (PDT) In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> References: <5530EEAB.5050601@cs.tcd.ie> From: Joseph Lorenzo Hall Date: Thu, 23 Apr 2015 15:21:36 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: perpass Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:22:09 -0000 On Fri, Apr 17, 2015 at 7:29 AM, Stephen Farrell wrote: > Please discuss those here and/or send 'em to the IESG or to some > random AD or to me. But discussing 'em on this list is way better, > and of course even betterer is to write an I-D (and please do point > again at ones you've written, just to refresh folks' minds). Heya, We've authored and will be updating soon an I-D on technical methods used to accomplish censorship: https://tools.ietf.org/html/draft-hall-censorship-tech-00 I'm going to be updating that within the next week and will have an academic co-author. I'm looking to generate a series of documents like these that cover topics that IETF engineers might find valuable when doing protocol or implementation work if they'd like to avoid unanticipated and potentially problematic uses of their protocols. The next subject to tackle (and it may be better to break down further) in my mind is traffic analysis, which can be a bear of a topic (i.e., very hard). Since there is no natural WG for this work, but I'm hopeful it could be valuable work, I was hoping perpass would be a great place to have discussion about these kinds of cross-WG topics in pervasive monitoring (and maybe a few will make the cut and garner AD sponsorship... but that seems a ways off!). best, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Wed Apr 29 10:53:30 2015 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 BEA321ACDAF for ; Wed, 29 Apr 2015 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Zh2s2QclL9aI for ; Wed, 29 Apr 2015 10:53:27 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEBE1ACDA8 for ; Wed, 29 Apr 2015 10:53:27 -0700 (PDT) Received: from internal.xmail06.myhosting.com ([10.5.2.16] helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1YnWAn-00075E-Ok for perpass@ietf.org; Wed, 29 Apr 2015 13:53:26 -0400 Received: (qmail 5206 invoked from network); 29 Apr 2015 17:53:23 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.192.64]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Apr 2015 17:53:23 -0000 From: "Christian Huitema" To: "'Stephen Farrell'" , "'perpass'" References: <5530EEAB.5050601@cs.tcd.ie> In-Reply-To: <5530EEAB.5050601@cs.tcd.ie> Date: Wed, 29 Apr 2015 10:53:22 -0700 Message-ID: <008901d082a5$6372ff80$2a58fe80$@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: AQJyRSr0dbs+AVu97VN1H/RMwXFCwpwgvjpA Content-Language: en-us Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:53:28 -0000 > -----Original Message----- On Friday, April 17, 2015, at 4:30 AM, Stephen Farrell wrote: > ... > Please discuss those here and/or send 'em to the IESG or to some > random AD or to me. But discussing 'em on this list is way better, > and of course even betterer is to write an I-D (and please do point > again at ones you've written, just to refresh folks' minds). OK Stephen, since you asked... In general, I think of privacy mitigation in three steps. First, we have to deploy encryption, and make sure that it actually works. We have lots of activity on that. Second, we have to consider all the metadata that is not covered by encryption, such as header elements or management protocols. We should apply data minimization to mitigate that. We have some activity starting therewith the DHCP anonymity profile in DHC and the data minimization work in DNSOP. We need more of that, there are plenty protocols that leaks unencrypted information, we have to scrub them. Finally, we have to look at the "end-to-end" issues, such as all the tracking that is taking place by means of cookies, cached files, browser fingerprinting or e-mail analysis. I understand that the latter issue is a bit controversial. The "pervasive monitoring" work concentrates on a threat actor that can passively monitor a bunch of links, typically a state actor with very big budgets. But protecting against this passive monitoring is not sufficient. Suppose that an advertising system collects enough data to understand the type of chocolate that consumers prefer, their age, or the time they drive their car. Suppose that this advertising company receives a visit of the "men in black." They ask a simple question: please run this filter for us, we really need to identify the "youth morning driver chocolate liberation front." For the company, that is very much an "offer they cannot refuse." For the men in black, that's way more effective than having to install a bunch of taps everywhere and run a lot of data collection. And it doesn't matter that all the traffic from the members of the liberation front was encrypted... -- Christian Huitema From nobody Thu Apr 30 00:21:06 2015 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 E4EFB1ACEAD for ; Thu, 30 Apr 2015 00:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU2wERSQGoWU for ; Thu, 30 Apr 2015 00:21:03 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159951ACE9D for ; Thu, 30 Apr 2015 00:21:03 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C0EFA43A47 for ; Thu, 30 Apr 2015 09:21:01 +0200 (CEST) Message-ID: <5541D7DD.9010504@restena.lu> Date: Thu, 30 Apr 2015 09:21:01 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5530EEAB.5050601@cs.tcd.ie> <25042.1429279352@sandelman.ca> In-Reply-To: <25042.1429279352@sandelman.ca> OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eTA7XL5PdqVwvb92Pp8rihK56XE56PMSh" Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 07:21:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eTA7XL5PdqVwvb92Pp8rihK56XE56PMSh Content-Type: multipart/mixed; boundary="------------030107030201050504020704" This is a multi-part message in MIME format. --------------030107030201050504020704 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > The biggest issue that I see in the perpass space has been persistent m= arket > failures of some of our key technologies. Not entirely our problem, bu= t each > time I see an industry "consortia" write a specification behind closed = doors > that is more than a list of RFCs, I think we have failed. [..] > This is very much a case where there has been a significant gap between= what > we specify, and what there are resources to actually implement *AND* > deploy. I have one example where we have left spec-writing to third parties and thus seem to neglect the "deploy" part of the value chain to some extent, and one which leads to security and privacy problems. My main focus of work is secure enterprise wireless networks. The medium is of course IEEE's "problem", but the secure authentication part brings in EAP, which is an IETF spec. EAP is a really complex protocol and needs server *and* client side config to deliver its security properties. Two short examples: a) the end-user device /can/ configure an anonymous outer identity for authentication routing purposes (concealing the local part of the username); but that's extra config. If neglected, the end-device leaks the actual username of the person trying to authenticate across the AAA infrastructure. b) the end-user device /can/ be configured to verify the X.509 certificate of its EAP server before it sends the user credentials; but the user needs to install CAs and whatnot. If neglected, the end-user device will send passwords to random third parties (and we have some anecdotal evidence suggesting the rate of such "don't care" configs is >>50%). EAP asks much from a server operator and the end user trying to configure it. Assuming that everybody will just get it right is delusiona= l. A variety of (non-interoperable) third-party approaches to automated/better/more convenient EAP configuration has blossomed, creating a mess of config formats / sane defaults / insane defaults landscape. I've tried to bring work to the IETF to create a config file format for EAP; the basic idea being that if IETF created EAP, we should also create a means to communicate EAP *configuration*. I didn't find a spot-on working group to take this to and presented it to opsarea / opsawg instead. There was only a rather mild interest in the draft, it hasn't led to much review activity or a motion to adopt it as a WG draft at this point. I find that a bit disappointing. I'm considering to go AD shopping to publish this in the ISE stream for the lack of a better path to publication. But really... this is privacy (and security!) relevant work, it's about an IETF technology, it is about a technology which is in active use out there, and it obviously is a piece of work that needs standardisation because there are so many non-interoperable approaches. So... why does such an item gain so little traction? I don't know the answer; if anyone does... BTW, the current draft is here; as it happens, it expires today, and honestly I'm wondering if it's worth refreshing it: https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030107030201050504020704 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030107030201050504020704-- --eTA7XL5PdqVwvb92Pp8rihK56XE56PMSh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVQdfdAAoJEMDeajWKOdxmo/wP/0mWLG2y9Fgq5feoMydkykrV agSGzUsCby1N+xChPCDoXBufCpSI03Dx8tiQJ9zCidVM7+KjejSgQtQdrN6ADE/n nyd8Fak8+AH5pWgTa57lGHWnf/p3GLxQZ/9ug2qrmUfQ6Pj6gIKAMseIpiMzSXJD at95vQEFPnRtpHAc49pTj+JeBohbAdCRQwZM19jswbKFLwC7wqs6LfxI77uG/9Xv +/zzFk3oeh2NdQWocNvB8SjXqh06c6KneMZJoZAs4CYc8MT8C4v3CrH3xAE1wKbI IJinKelajKCAMFCq9ONkH3nWtLD0gKw/6Mib3peTX42yPZulZQmy1gV/gX4LxITd qEB0TNtUbn3VJq2H3+atqT3bQ+05/jww4ONp8osBAbq1ph8yEaZfjSRbyQWEiEpm /RxvEMi7MqGU3qnucu49VMCJF8OAQcC9w+L/ioR8j5bJM8BVT9yy/7847Ps5wzDN N8q5yqhczCcCTRnvqjOJ406bCpO5tqx5zrAFEjX9iLC3/L3fWPMMmtJilZOiLjvr Q0ftLSM13S8LwhBWbwLUrJruVLfkwnD3HJ5oPIo7+E2Bqd9Chn9aEqnmycRXbFVI keHgISxd/UYdhnns4PbDUzyrDVp454Ubpnxo7OJKQr/+K4YLGVmzyyPzFy/hU0X4 SxANovq7qmg7Q+HY9LVN =Id4R -----END PGP SIGNATURE----- --eTA7XL5PdqVwvb92Pp8rihK56XE56PMSh-- From nobody Thu Apr 30 06:52:22 2015 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 18BD51B2A87 for ; Thu, 30 Apr 2015 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnp9HWJKZ_Tg for ; Thu, 30 Apr 2015 06:52:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955F31B2A5F for ; Thu, 30 Apr 2015 06:52:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6D1B200A1; Thu, 30 Apr 2015 10:04:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5845C63B86; Thu, 30 Apr 2015 09:52:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 42DFD63784; Thu, 30 Apr 2015 09:52:17 -0400 (EDT) From: Michael Richardson To: Stefan Winter In-Reply-To: <5541D7DD.9010504@restena.lu> References: <5530EEAB.5050601@cs.tcd.ie> <25042.1429279352@sandelman.ca> <5541D7DD.9010504@restena.lu> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:52:21 -0000 --=-=-= Content-Type: text/plain Stefan Winter wrote: > I've tried to bring work to the IETF to create a config file format for > EAP; the basic idea being that if IETF created EAP, we should also > create a means to communicate EAP *configuration*. > I didn't find a spot-on working group to take this to and presented it > to opsarea / opsawg instead. > There was only a rather mild interest in the draft, it hasn't led to > much review activity or a motion to adopt it as a WG draft at this > point. I find that a bit disappointing. I'm considering to go AD > shopping to publish this in the ISE stream for the lack of a better path > to publication. I agree that we do a poor job here, and I think that we should make this kind of interaction smoother. I spent four years working on rfc4332 (OE for IPsec/IKE), and version 1 was always going to be on the ISE. > BTW, the current draft is here; as it happens, it expires today, and > honestly I'm wondering if it's worth refreshing it: > https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 I would say yes. I was going to ask if there were implementations, and you clearly have some... Would there be value to deploy this at IETF meeting networks? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUIzkYCLcPvd0N1lAQIcowgAnbFeli+QasgSgkOVR20r2vq6Wh4Hi1SW iUOB6NDH9+kqQWNSPayNEyL7DtME8bIWaWBfZ7Q2OZIx9cNge9eg4lgvM06KihkM y5qLVf/kKghppPqDXCXYXQgTvksC/0O25k2l4ZTxiJXv1GkyML7jJL34l4jaMM9J GcY9Z+nAxxzCHgNKjyydJ/ICczB1LlJIU8yIHj3YRi2b0RQg/6oTOjchaJUWJpHN nwqGbWzHmUGRdrH1zGraHTjRLNTqTNgZWjynD8Qeob0FySOT7O0D59/7kaYW7bc1 TJUGNBvaBkUzaGnXuXz9iS51sSLL4zGD2TPhDnHfHbwhmEFXbPfciQ== =SMog -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 30 07:59:00 2015 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 926BC1A6F29 for ; Thu, 30 Apr 2015 07:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTZIZPCMqjxQ for ; Thu, 30 Apr 2015 07:58:57 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3923B1A1BB8 for ; Thu, 30 Apr 2015 07:58:13 -0700 (PDT) Received: from [192.168.1.4] (135.sub-70-214-5.myvzw.com [70.214.5.135]) by toccata.fugue.com (Postfix) with ESMTPSA id 8822F2380423; Thu, 30 Apr 2015 10:58:12 -0400 (EDT) References: <5530EEAB.5050601@cs.tcd.ie> <25042.1429279352@sandelman.ca> <5541D7DD.9010504@restena.lu> <30883.1430401937@sandelman.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <30883.1430401937@sandelman.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <03F4B569-1339-4046-9141-2116486E93B7@fugue.com> X-Mailer: iPad Mail (12B410) From: Ted Lemon Date: Thu, 30 Apr 2015 10:58:11 -0400 To: Michael Richardson Archived-At: Cc: Stefan Winter , "perpass@ietf.org" Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:58:59 -0000 On Apr 30, 2015, at 9:52 AM, Michael Richardson wrot= e: >=20 > I would say yes. I was going to ask if there were implementations, and you= > clearly have some... Would there be value to deploy this at IETF meeting > networks? That would certainly be interesting. I definitely agree with Stefan's main p= oint here that 802.1x is too difficult. There is no common language or set o= f operational assumptions shared between different client implementations, s= o it's impossible to carry what one has learned about configuring it in one c= ontext to another. I would like to see work on this happen somewhere in the= IETF. One of the IT folks at my office yesterday was complaining about how hard it= is to configure, and also the lack of widespread 802.11w support in clients= and servers (although this particular issue is something we may not be able= to do anything about). This conversation happened because I was trying to g= et a chromebook on our office network for the first time and not only was th= e UI completely different than the apple UI, when it failed there was no way= to figure out from the error message why it had.=